I'm trying to RESTify an existing Web application, and have a stylistic question. Imagine that a Web application fronts for a database, where all of the records are available as resources. For example, you could search the database at http://www.example.org/search and the results would point at records, like http://www.example.org/records/theThing One can add to the database by doing a get (for the form) and then a POST to http://www.example.org/add Now, how should editing and deletion be done? One approach is to expose an edit resource, similar to the add one; http://www.example.org/edit To edit a specific resource, one could use a query string; http://www.example.org/edit?resource=theThing and use GET and POST to get the form and POST the edit. Another approach would be to use the resource's native URI, like http://www.example.org/records/theThing?mode=edit in a similar manner. This seems to be the approach taken by most WIKIs, interestingly. Is either approach preferable/horrible, or are they pretty much the same? The specific application is a gateway to an LDAP database. I haven't read Roy's full dissertation (still!), so apologies if I've asked a FAQ. Deletion is another interesting case; if each LDAP entry really is a resource, DELETE would be most appropriate, no? Unfortunately, methods other than GET and POST aren't available from HTML... Cheers, P.S.; Do queries identify a new resource? Their defined as a mechanism to pass data to the server. Common use (as outlined above) seems to indicate that people don't consider them separate, but in the URI world, they're not lumped into URI-References with fragments...
> I'm trying to RESTify an existing Web application, and have a
> stylistic question.
>
> Imagine that a Web application fronts for a database, where all of the
> records are available as resources.
>
> For example, you could search the database at
> http://www.example.org/search
> and the results would point at records, like
> http://www.example.org/records/theThing
I have a thought about that that I'll bring up in another thread
shortly.
> One can add to the database by doing a get (for the form) and then a
> POST to
> http://www.example.org/add
Why not POST to http://www.example.org/search? The good thing about
doing that is that an intermediary would know that /search has changed
state due to the POST, whereas if it went to /add, the state change
would be transparent and the intermediary wouldn't know. Also,
/search may not be the best name if you're posting to it. What about
this?
http://www.example.org/database
or, if the database is a list of employees;
http://www.example.org/employees
> Now, how should editing and deletion be done? One approach is to
> expose an edit resource, similar to the add one;
> http://www.example.org/edit
> To edit a specific resource, one could use a query string;
> http://www.example.org/edit?resource=theThing
> and use GET and POST to get the form and POST the edit.
>
> Another approach would be to use the resource's native URI, like
> http://www.example.org/records/theThing?mode=edit
> in a similar manner. This seems to be the approach taken by most
> WIKIs, interestingly.
>
> Is either approach preferable/horrible, or are they pretty much the
> same? The specific application is a gateway to an LDAP database. I
> haven't read Roy's full dissertation (still!), so apologies if I've
> asked a FAQ.
An "edit" should be done with a PUT interface, no? I know that this
is problematic given that browsers/HTML only support GET/POST, but if
you can afford it (development time, extra code to maintain, performance
hit with another layer), I'd solve that problem after exposing the PUT
interface, perhaps by having a separate Wiki-looking URI that accepts
POSTs and treats them as PUTs.
e.g.
http://www.example.org/employees?id=234343?pap=true
("pap" => "post-as-put")
> Deletion is another interesting case; if each LDAP entry really is a
> resource, DELETE would be most appropriate, no? Unfortunately, methods
> other than GET and POST aren't available from HTML...
Yah. I'd do much the same as for PUT; build the DELETE interface, then
kludge a POST interface on top.
> P.S.; Do queries identify a new resource?
Yes. Each unique URI identifies a new resource, modulo generic &
per-scheme equivalence rules.
> Their defined as a mechanism
> to pass data to the server. Common use (as outlined above) seems to
> indicate that people don't consider them separate, but in the URI
> world, they're not lumped into URI-References with fragments...
You can use them with URI refs;
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hier_part | opaque_part )
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
hier_part = ( net_path | abs_path ) [ "?" query ]
More on this in that other email I promised.
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
On Mon, Jan 07, 2002 at 10:03:17AM -0500, Mark Baker wrote:
> > One can add to the database by doing a get (for the form) and then a
> > POST to
> > http://www.example.org/add
>
> Why not POST to http://www.example.org/search? The good thing about
> doing that is that an intermediary would know that /search has changed
> state due to the POST, whereas if it went to /add, the state change
> would be transparent and the intermediary wouldn't know.
hmm. Individual searches are separate resources; i.e., they have
different query strings, so this wouldn't necessarily work, no? (It
wouldn't make sense to POST a query, obviously).
> Also, search may not be the best name if you're posting to it.
> /What about
> this?
>
> http://www.example.org/database
>
> or, if the database is a list of employees;
>
> http://www.example.org/employees
Yes. I knew that that was a problem, just didn't have a good
mechanism; perhaps it would be good to have a DN->resource mapping,
so that
http://www.example.org/addresses
maps to 'dc=example,dc=org' (if that's the DN being used for
addresses. Then, individual entries could be maped to
http://www.example.org/addresses/Bob%20Smith
or somesuch.
This might be a horrible abuse of LDAP, but hey, I'd
rather abuse it than the Web ;)
> An "edit" should be done with a PUT interface, no? I know that this
> is problematic given that browsers/HTML only support GET/POST, but if
> you can afford it (development time, extra code to maintain, performance
> hit with another layer), I'd solve that problem after exposing the PUT
> interface, perhaps by having a separate Wiki-looking URI that accepts
> POSTs and treats them as PUTs.
>
> e.g.
>
> http://www.example.org/employees?id=234343?pap=true
>
> ("pap" => "post-as-put")
Sure. Perhaps start with pap and then backport. I'm doing this with
python's BaseHTTPServer, so I can do anything fairly easily ;)
> You can use them with URI refs;
Yes. What I'm getting at is that the WIKI-like mechanisms such as
http://www.example.com/theThing
http://www.example.com/theThing?pap=true
are a complete kludge; from a resource standpoint, these might as
well be
http://www.example.com/theThing
http:/www.example.com/someOtherThing
because of opacity; the only person who knows that ?pap=true does
something special is the publisher.
P.S. it would be interesting to see an analysis of the RESTyness of
WIKIs.
--
Mark Nottingham
http://www.mnot.net/
> > Why not POST to http://www.example.org/search? The good thing about
> > doing that is that an intermediary would know that /search has changed
> > state due to the POST, whereas if it went to /add, the state change
> > would be transparent and the intermediary wouldn't know.
>
> hmm. Individual searches are separate resources; i.e., they have
> different query strings, so this wouldn't necessarily work, no? (It
> wouldn't make sense to POST a query, obviously).
Why not? Don't think of the resource as being a search, but think of
it as the result of a search.
"http://www.google.com/search?q=foo" is the set of all resources known
by Google to contain the word "foo". That it requires a search to
resolve this URI at google.com is immaterial really.
So there's no problem with POSTing to /search. That would be one way
for Google to allow people to register new unindexed resources, for
example. But as mentioned below, the name is confusing.
> > Also, search may not be the best name if you're posting to it.
> > /What about
> > this?
> >
> > http://www.example.org/database
> >
> > or, if the database is a list of employees;
> >
> > http://www.example.org/employees
>
> Yes. I knew that that was a problem, just didn't have a good
> mechanism; perhaps it would be good to have a DN->resource mapping,
> so that
>
> http://www.example.org/addresses
>
> maps to 'dc=example,dc=org' (if that's the DN being used for
> addresses. Then, individual entries could be maped to
>
> http://www.example.org/addresses/Bob%20Smith
>
> or somesuch.
>
> This might be a horrible abuse of LDAP, but hey, I'd
> rather abuse it than the Web ;)
Heh. But do you understand what I was saying here, after what I just
wrote above?
> > http://www.example.org/employees?id=234343?pap=true
> >
> > ("pap" => "post-as-put")
>
> Sure. Perhaps start with pap and then backport. I'm doing this with
> python's BaseHTTPServer, so I can do anything fairly easily ;)
Anything except implement a catchall do_* method (I'm writing a
proxy). 8-)
> > You can use them with URI refs;
>
> Yes. What I'm getting at is that the WIKI-like mechanisms such as
>
> http://www.example.com/theThing
> http://www.example.com/theThing?pap=true
>
> are a complete kludge; from a resource standpoint, these might as
> well be
>
> http://www.example.com/theThing
> http:/www.example.com/someOtherThing
>
> because of opacity; the only person who knows that ?pap=true does
> something special is the publisher.
Exactly right. An alternative is to tunnel PUT and DELETE through
POST with a hidden form field called "method". At least the URI
wouldn't change. I guess there's a number of ways to kludge it.
That would make for a good RESTwiki page.
> P.S. it would be interesting to see an analysis of the RESTyness of
> WIKIs.
This one has been up on the RESTwiki for a while. It's pretty
good, I think.
http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
On Mon, Jan 07, 2002 at 01:45:52PM -0500, Mark Baker wrote:
> > > Why not POST to http://www.example.org/search? The good thing about
> > > doing that is that an intermediary would know that /search has changed
> > > state due to the POST, whereas if it went to /add, the state change
> > > would be transparent and the intermediary wouldn't know.
> >
> > hmm. Individual searches are separate resources; i.e., they have
> > different query strings, so this wouldn't necessarily work, no? (It
> > wouldn't make sense to POST a query, obviously).
>
> Why not? Don't think of the resource as being a search, but think of
> it as the result of a search.
>
> "http://www.google.com/search?q=foo" is the set of all resources known
> by Google to contain the word "foo". That it requires a search to
> resolve this URI at google.com is immaterial really.
>
> So there's no problem with POSTing to /search. That would be one way
> for Google to allow people to register new unindexed resources, for
> example. But as mentioned below, the name is confusing.
Well, there's no problem POSTing an update to /search (or whatever),
but doing a query through POST doesn't seem very RESTy at all.
So, to review (and make sure I've got a cohesive interface),
http://www.example.org/addresses
Exposes the DB as a whole
GET: representation is the main interface (queries, etc.)
POST: add a new entry, returns a 303 to the created resource
http://www.example.org/addresses?repr=add
GET: representation is an add form
http://www.example.org/addresses?query_to_the_db
GET: representation is a listing of the query
http://www.example.org/addresses/thePerson
exposes a particular record
GET: representation is a person's record
POST: update the resource/record, returns a 303 to the resource
PUT: create the resource/record (multiple content-types
supported?), returns a status page (or a 303?)
DELETE: delete the resource/record, returns a status page
http://www.example.org/addresses/thePerson?repr=edit
GET: representation is an edit form
These duplicate functionality above:
http://www.example.org/addresses/thePerson?method=PUT
POST: tunnels to PUT, returns a status page
http://www.example.org/addresses/thePerson?method=DELETE
POST: tunnels to DELETE, returns a status page
I'm a *little* uncomfortable with the ?repr=add, but I can't say
exactly why.
> Exactly right. An alternative is to tunnel PUT and DELETE through
> POST with a hidden form field called "method". At least the URI
> wouldn't change. I guess there's a number of ways to kludge it.
> That would make for a good RESTwiki page.
That would be cool. I like the method= kludge...
> http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest
Ah, I'd seen that, but never investigated. Thanks.
--
Mark Nottingham
http://www.mnot.net/
> > So there's no problem with POSTing to /search. That would be one way > > for Google to allow people to register new unindexed resources, for > > example. But as mentioned below, the name is confusing. > > Well, there's no problem POSTing an update to /search (or whatever), > but doing a query through POST doesn't seem very RESTy at all. Right. I guess I wasn't clear, my apologies. > So, to review (and make sure I've got a cohesive interface), > > http://www.example.org/addresses > Exposes the DB as a whole > GET: representation is the main interface (queries, etc.) > POST: add a new entry, returns a 303 to the created resource Hmm, if you're creating a new resource it should be returned with a 201. You won't get an auto redirect, but the client will know the URI of the new resource. The body can also include a link if a browser is your client. > http://www.example.org/addresses?repr=add > GET: representation is an add form /addresses could serve that purposes, no need for the new URI. Content negotiation could be used to negotiate a representation capable of expressing a form. > http://www.example.org/addresses?query_to_the_db > GET: representation is a listing of the query Looks good. > http://www.example.org/addresses/thePerson > exposes a particular record > GET: representation is a person's record > POST: update the resource/record, returns a 303 to the resource > PUT: create the resource/record (multiple content-types > supported?), returns a status page (or a 303?) > DELETE: delete the resource/record, returns a status page Good. > http://www.example.org/addresses/thePerson?repr=edit > GET: representation is an edit form Again, could content negotiation not be used to retrieve an editable format? BTW, my other message I promised is turning into something that should probably be sent to uri@..., so stay tuned. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote: > > http://www.example.org/addresses > > Exposes the DB as a whole > > GET: representation is the main interface (queries, etc.) > > POST: add a new entry, returns a 303 to the created resource > > Hmm, if you're creating a new resource it should be returned with a > 201. You won't get an auto redirect, but the client will know the > URI of the new resource. The body can also include a link if a > browser is your client. Hmm. Seems good; will have to play. > > http://www.example.org/addresses?repr=add > > GET: representation is an add form > > /addresses could serve that purposes, no need for the new URI. > Content negotiation could be used to negotiate a representation > capable of expressing a form. [...] > > http://www.example.org/addresses/thePerson?repr=edit > > GET: representation is an edit form > > Again, could content negotiation not be used to retrieve an editable > format? What's the media type for an HTML form which is the editable representation of a resource again? ;) Also, how would I tell a browser to request it? > BTW, my other message I promised is turning into something that should > probably be sent to uri@..., so stay tuned. Cool! -- Mark Nottingham http://www.mnot.net/
On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote: > Content negotiation could be used to negotiate a representation > capable of expressing a form. I was hoping to allow requests to the record resource http://www.example.com/addresses/thePerson to negotiate the representation returned, so that the default would be to return an HTML page, but if linked from an <img> element, the image/jpeg in the jpegPhoto attribute would be returned. Sadly, it's not to be. Conneg support in browsers is horrible. Mozilla sends a static Accept header, no matter what the context, which enumerates all of the types it supports. I've logged a bug[1] for this (please vote for it if so inclined). IE seems to generate the Accept header based on the filename extension of the resource (EW!), and by default sends a header that includes a lot of image/ types, a */* (which is a CUAP[2]), but no HTML. Of course, conneg is still useful to expose, but lack of support in browsers means that another means of doing this -- probably with query strings (or maybe path parameters?) -- will have to be hacked. *sigh* [1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696 [2] http://www.w3.org/TR/cuap Hmm... Bugzilla would be an excellent candidate for RESTification... -- Mark Nottingham http://www.mnot.net/
On Mon, Jan 07, 2002 at 10:51:03PM -0800, Mark Nottingham wrote: > [1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696 Oops, that should be [1] http://bugzilla.mozilla.org/show_bug.cgi?id=118696 -- Mark Nottingham http://www.mnot.net/
Why do so many websites use home-spun HTML/cookie authentication (login/password) instead of HTTP authentication? I'm guessing it is all about user interface issues -- being able to put the login box where-ever you want it. What needs to be done to web infrastructure so that this bit of context moves from the HTML/cookie domain down into HTTP where it is supposed to live? Paul Prescod
> Why do so many websites use home-spun HTML/cookie authentication > (login/password) instead of HTTP authentication? I'm guessing it is all > about user interface issues -- being able to put the login box > where-ever you want it. Exactly right. This is a major issue, as it prevents many tasks from being automated. > What needs to be done to web infrastructure so that this bit of context > moves from the HTML/cookie domain down into HTTP where it is supposed to > live? I don't know that there's a quick fix. One thing I was thinking of was an HTML/XHTML extension that would allow more flexibility in the user interface of the authentication system. But it would take forever to roll that out. Other ideas; - conventions for cookie values. would also be difficult to rollout as HTTP libs that support cookies would all need fixing. - recognizing forms with two fields where one is a password input type, and somehow kludging that knowledge into the auth system. easier to rollout, but error prone and not sure how the kludge would work MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Thu, Jan 10, 2002 at 01:14:07PM -0500, Mark Baker wrote: > > Why do so many websites use home-spun HTML/cookie authentication > > (login/password) instead of HTTP authentication? I'm guessing it > > is all about user interface issues -- being able to put the login > > box where-ever you want it. > > Exactly right. This is a major issue, as it prevents many tasks > from being automated. I think the issue is more that publishers don't have much control over the authentication state on the browser; things like remembering the username between sessions, logging out, etc. weren't addressable until IE and later Mozilla introduced password management interfaces. They're still less capable than cookie handling, unfortunately. Also, it was drilled into eveyone's heads that Basic authentication isn't secure. Some people thought that magically using cookies would solve this, whilst the more savvy used encrypted or hashed values in cookies. There is Digest authentication, but it was plagued with specification and implementation problems, IIRC. > - conventions for cookie values. would also be difficult to rollout > as HTTP libs that support cookies would all need fixing. What kind of conventions? It strikes me that defining conventions for cookies is about as friendly as defining conventions for URIs like well-known locations... > - recognizing forms with two fields where one is a password input type, > and somehow kludging that knowledge into the auth system. easier to > rollout, but error prone and not sure how the kludge would work I believe this is what Mozilla and IE do now. Of course, the auth is still sent as a cookie. Cheers, -- Mark Nottingham http://www.mnot.net/
I've raised an issue [1] with the XForms WG regarding their lack of support for PUTing xml instance data. Supporting PUT would seem to be very helpful to RESTful applications... [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/thread.html#47 -- Mark Nottingham http://www.mnot.net/
I don't know much about XForms but this little bit worried me: "My personal take is that HTTP GET is broken beyond repair for I18N-safe form-data submission. This is part of the reason why it's deprecated in XForms. Sending around bits of XML is a much better way to go." And yes indeed: http://www.w3.org/TR/xforms/slice11.html#rpm-send "The HTTP "get" protocol is deprecated for use in form submission. Form authors should use "post" for greater compatibility." Insofar as XForms will most often be used to submit data to be stored, this isn't a crisis, but when XForms replace HTML forms in general, this is going to be a big problem. Paul Prescod
> I don't know much about XForms but this little bit worried me: > > "My personal take is that HTTP GET is broken beyond repair for I18N-safe > form-data submission. This is part of the reason why it's deprecated in > XForms. Sending around bits of XML is a much better way to go." > > And yes indeed: > > http://www.w3.org/TR/xforms/slice11.html#rpm-send > > "The HTTP "get" protocol is deprecated for use in form submission. Form > authors should use "post" for greater compatibility." > > Insofar as XForms will most often be used to submit data to be stored, > this isn't a crisis, but when XForms replace HTML forms in general, this > is going to be a big problem. > > Paul Prescod I'm not worried about this at all. GET forms and POST forms are completely different beasts. The latter is for submitting resource representations, while the former is an assertion that the specified resource is a logical container for other resources, and is indexed by some set of names encoded into a query term. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > I'm not worried about this at all. GET forms and POST forms are > completely different beasts. The latter is for submitting resource > representations, while the former is an assertion that the specified > resource is a logical container for other resources, and is indexed by > some set of names encoded into a query term. I don't follow you. A form is a user interface. Today forms are often used as user interfaces to GET and to POST (i.e. filling in an information request as opposed to submitting data). XForms is the replacement for HTML forms. Over time browsers will move to this more functional user interface and yet lose out on the ability to do form-based GET. I see that as a problem. Paul Prescod
> I don't follow you. A form is a user interface. Today forms are often > used as user interfaces to GET and to POST (i.e. filling in an > information request as opposed to submitting data). XForms is the > replacement for HTML forms. Over time browsers will move to this more > functional user interface and yet lose out on the ability to do > form-based GET. I see that as a problem. I agree that it would be a problem if this were the case. But in my time on the HTML WG, including while work on XForms was being done there, it was never presented as a replacement. It wouldn't hurt to double check though. Why don't you raise this on www-forms? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Please contribute comments on this article I am working on for xml.com.
==============
Second Generation Web Services
In the early days of the Internet, it was common for enlightened
businesses to connect to the Internet merely by using SMTP, NTTP and FTP
clients and servers to deliver messages, text files, executables and
source code. The Internet became a more fundamental tool when businesses
started to integrate their corporate information (both public and
private) into the emerging Web framework. The Internet became popular
when it shifted from a focus on transactional protocols to a focus on
data objects and the links between them.
The technologies that characterize the early Web framework were
HTML/GIF/JPEG, HTTP and URLs. This combination of standardized formats,
a single application protocol and a single universal namespace was
incredibly powerful. Using these technologies, corporations integrated
their diverse online publishing systems into something much more
compelling than any one of them could have built.
Once organizations converged on common formats, the HTTP protocol and a
single addressing scheme, the Web became more than a set of Web sites.
It became the world's most diverse and powerful information system.
Organizations built links between their own information and other
people's. Amazing third party applications also weaved the information
together. Examples include Google, Yahoo, Babelfish and Robin Cover's
XML citations.
First generation Web Services are like first generation Internet
connections. They are not integrated with each other and are not
designed so that third parties can easily integrate them in a uniform
way. I posit that the next generation will be more like the integrated
Web that arose for online publishing and human/computer interactions. In
fact, I believe that second generation web services will actually build
much more heavily on the architecture that made the Web work. Look for
the holy trinity: standardized formats (XML vocabularies), a
standardized application protocol and a single URI namespace.
This next generation of Web Services will likely bear the name "REST"
Web Services. REST is the underlying architectural model of the current
Web. It stands for REpresentational State Transfer. Roy Fielding of
eBuilt invented the name in his PhD dissertation.
http://www.ebuilt.com/fielding/pubs/dissertation/top.htm. Recently, Mark
Baker of PlanetFred has been a leading advocate of this architecture.
REST details why the Web has URIs, HTTP, HTML, JavaScript and many other
features. It has many aspects and I would not claim to understand it in
detail. I'm going to focus on the aspects that are most interesting to
XML users and developers.
The Current Generation
SOAP was originally intended to be a cross-Internet form of DCOM or
CORBA. The name of an early SOAP-like technology was "WebBroker" -
Web-based object broker. It made perfect sense to model an
inter-application protocol on DCOM, CORBA, RMI etc. because they were
the current models for solving inter-application interoperability
problems.
These RPC protocols achieved only limited success before they were
ported to the Web. Some believe that the problem was merely that
Microsoft and the OMG supporters could not get along. I disagree. There
is a deeper issue. RPC models are great for closed-world problems. A
closed world problem is one where you know all of the users, you can
share a data model with them, and you can all communicate directly as to
your needs. Evolution is comparatively easy in such an environment: you
just tell everybody that the RPC API is going to change on such and such
a date and perhaps you have some changeover period to avoid downtime.
When you want to integrate a new system you do so by building a
point-to-point integration.
On the other hand, when your user base is too large to communicate
coherently you need a different strategy. You need a pre-arranged
framework that allows for evolution on both the client and server sides.
You need to depend less on a shared, global understanding of the rights
and responsibilities of a participant. You need to put in hooks where
your users can innovate without contacting you. You need to leave in
explicit mechanisms for interoperating with systems that do not have the
same API. RPC protocols are traditionally poor at this kind of
evolution. Changing interfaces tends to be extremely difficult. I
believe that this is why no enterprise has ever successfully unified all
of their systems with an RPC protocol such as DCOM, CORBA or RMI.
Now we come to the crux of the problem: SOAP RPC is DCOM for the
Internet.
There are many problems that can be solved with an RPC methodology. But
I believe that the biggest, hairiest problems will require a model that
allows for independent evolution of clients, servers and intermediaries.
It is therefore important for us to study the only distributed
applications in history to ever scale to the size of the Internet.
The archetypical scalable application
There two most massively scalable, radically interoperable, distributed
applications in the world today and they are the Web and email. What
makes these two so scalable and interoperable feature? For starters,
they both depend on standardized, extensible message formats (HTML and
MIME). They both depend on standardized, extensible application
protocols (HTTP and SMTP). But I believe that the most important thing
is that each has a global addressing scheme.
In the real estate world there is a joke that there are three things
that make a property valuable: location, location and location. The same
is true in the world of XML web services. Properly implemented, XML web
services allow you assign addresses to data objects so that they may be
located for sharing or modification.
In particular, the web's central concept is a single unifying namespace
of URIs. URIs allow the dense web of links that make the Web worth
using. URIs identify resources. Resources are conceptual objects.
Representations of them are delivered across the web in HTTP messages.
These ideas are so simple and yet they are profoundly powerful and
demonstrably successful. URIs are extremely "loosely coupled". You can
pass a URI from one "system" to another using a piece of paper and OCR!
URIs are "late bound". They do not declare what can or should be done
with the information they reference. It is because they are so radically
"loose" and "late" that they scale to the level of the Web.
Unfortunately, most of us do not think of our web services in these
terms. Rather we think of them in terms of remote procedure calls
between endpoints that represent software components. This is CORBA/DCOM
thinking. Web thinking is organized around URIs for resources.
Claim: The next generation of web services will use individual data
objects as endpoints. Software component boundaries will be invisible
and irrelevant.
An Illustrative Example
UDDI is an example of a Web Service that could be made much, much more
robust as a second generation Web Service. I'm not discussing the
philosophical issues of UDDI's role in the web services world but the
very concrete issue of how to get information into and out of it. These
arguments will apply to most of the Web Services in existence, including
stock quote services, airplane reservations systems and so forth.
UDDI has a concept of a businessEntity representing a corporation.
Businesses are identified by UUIDs. The Web-centric way to do this would
have been to identify them by URIs. The simplest way to do this would be
to make a businessEntity an XML document addressable at a URI
like"http://www.uddi.org/businessEntity/ibm.com" or perhaps
"http://www.uddi.org/getbusinessEntity?ibm.com". The difference between
these two is subtle and does not have many technical implications so
let's not worry about it.
You can think of "http://www.uddi.org/businessEntity" as a directory
with files in it or a web service pulling data from a database. A
wonderful feature of the Web is that there is no way to tell which is
true just from looking at the URI. That is "loose coupling" in action!
Let's consider the implications of using HTTP-based URIs instead of
UUIDs for business entities:
* Anybody wanting to inspect that business entity would merely point
their (XML-aware!) browser at that URI and look at the businessEntity
record.
* Anybody wanting to reference the businessEntity (in another web
service or a document) could just use the URL.
* Anybody wanting to incorporate the referenced information into another
XML document could use an XLink, XPointer or XInclude.
* Anybody wanting a permanent copy of the record could use a command
line tool like "wget" or do a "Save As" from the browser.
* Any XSLT stylesheet could fetch the resource dynamically to combine it
with others in a transformation.
* Access to the businessEntity could be controlled using standard HTTP
authentication and access control mechanisms
* Metadata could be associated with the businessEntity using RDF
* Any client-side application (whether browser-based or not) could fetch
the data without special SOAP libraries.
* Two business entities could represent their merger by using a standard
HTTP redirect from one businessEntity to another.
* Editing and analysis tools like Excel, XmetaL, Word and EMACS could
import XML from the URL directly using HTTP. They could write back to it
using WebDAV.
* UUIDs or other forms of location-independent addresses could still be
assigned as an extra level of abstraction as demonstrated at purl.org.
The current UDDI "API" has a method called get_businessDetail. Under an
address-centric model, that method would become entirely redundant and
could thus be removed from the API. UDDI has several get_ methods that
operate on data objects such as tModels and business services. These
data objects could all be represented by logical XML documents and the
methods could be removed. Note how we have substantially simplified the
user's access to UDDI information.
Business entities are not the only things in UDDI that should be
identified by URI-addressable resources rather than SOAP APIs. In fact
all of the data in a UDDI database could be represented this way.
Summary: Resources (data objects) are like children. They need to have
names if they are to participate in society.
Extensibility
Now let's consider the extensibility characteristics of the REST model
versus the original SOAP RPC model. Let's say that your company has a
private UDDI registry and mine does also. You and I are business
partners. We agree to share our customer databases. The customer
databases have pointers into our UDDI registries for referring to
businessEntities.
If our registries have little or no overlap then it makes sense for you
to maintain yours and for me to maintain mine. Rather than replicating
between them (which has serious security and maintainability
implications) I would like to just add you to the access control lists
for some records and allow you to refer to them from your customer
database and I'll do the opposite from mine.
If the customer databases use UUIDs then they have no way of knowing
whether a particular UUID should be looked up in the local database, the
partner's database or even the public UDDI In The Sky. URIs are not just
globally unique but also typically embed enough information to allow
them to be de-referenced without further context. Using URIs instead of
UUIDs, new repositories can be integrated whenever we want. In fact, if
we use URIs, the customer database could refer just as easily to
businessEntity records sitting on somebody's hard disk as in a formal
UDDI registry. The database maintainer could choose whether to allow
that or not.
Because the businessEntity documents are XML, it is relatively easy to
add elements, attributes or other namespaces. This makes the document
format extensible. It is also easy to extend the protocol by adding
specialized HTTP headers or even new HTTP methods.
Performance
Performance of web services will be an important issue. Any resource
representation retrieved from a GET-based URI can be cached. It can be
cached in a cache server in front of the server, in an intermediate
provided by an ISP, at a corporate firewall or on the client computer.
Caching is built-in to HTTP. SOAP get_businessDetail messages are not
cached by any existing technology.
As an optimization, the URI "http://www.uddi.org/businessEntity/ibm.com"
might be represented as a raw text file on a hard disk of an operating
system optimized towards serving files over HTTP. There is not and will
likely never be any server that can invoke SOAP methods as quickly as a
fast HTTP server can serve files from disk.
Other methods
UDDI has other methods for working with businessEntities. One is
delete_business. HTTP already has a DELETE method. Therefore this method
would be redundant in the REST model. Instead of doing a UDDI
SOAP-RPC-specific delete you could do an HTTP delete. This would have
the benefit of being compatible with tools that know how to do HTTP
deletes like the Windows 2000 explorer and MacOS X finder. In theory,
businesses could delete portions of their own records (perhaps obsolete
branch plant addresses) by merely hitting the "delete" key.
Obviously authentication and access control is key. Microsoft should not
be able to delete their competitors (or at least should be forced to
delete them in the old fashioned way, by competing with them). HTTP
already has the authentication, authorization and encryption features
that UDDI's SOAP RPC protocol lacks. It already works.
UDDI has a save_business method. This is for uploading new businesses.
The HTTP equivalent is PUT or POST. A pleasant side effect of using HTTP
methods instead of a SOAP method is that you can do a POST from an HTML
form. So the web service can be used either from other programs or (with
a browser) by a human editor.
UDDI has a find_business method. This is no different in principle than
the search features built into every website in the world and search
engine sites in particular. That would be a form of GET. On the URL
line, the service would take a series of search parameters and return an
XML document representing the matching businessEntities (either by
reference, as URLs, or by value, as XML elements).
The Role of HTTP
You may notice a recurring theme. Everything that we want to do in this
Web Service is already supported in HTTP. The only things that we need
to innovate on are our URI structure and our XML schemas. Bingo! That
was the whole point of XML: to focus on data interchange instead of
software components!
Everything in UDDI can be represented in terms of HTTP operations on
resources. So HTTP isn't accidentally paired with URIs as one of the
central technologies of the Web. It is designed specifically as a major
part of the location-centric REST architecture.
Here's the radical idea: no matter what your problem, you can and should
think about it as a data resource manipulation problem rather than as an
API design problem. Think of your web server as this big information
repository: like a database. You are doing data manipulation operations
on it.
In UDDI I've chosen a web service that is ripe for an easy conversion to
REST philosophy but we can apply these principles to anything. What
about something like a purchase order submission? That seems more
transactional. Well purchase orders want to be named also! If you POST
or PUT a purchase order to a new URI then internal systems all over your
company can instantly refer to it no matter where they are. Using HTTP,
an arbitrary XSLT stylesheet or Perl script sitting on an employee's
desktop in the Beijing office can massage data from a purchase order
sitting on the accounting mainframe in Los Angeles. Accessing
HTTP-addressable resources is no more difficult than accessing files off
of the local file system, but it requires much less coordination than
standard file system sharing technologies.
What about a request for quote? RFQs want to be named! Once you give
them a name you can pass around the URL to your partners rather than the
text. Then your partners can build references to them using hyperlinks
from their documents and databases. Use access controls to keep out your
competitors. You can think about any business problem in this way.
Even web services with complicated work flows can be organized in a
URI-centric manner. Consider a system that creates airline reservations.
In a traditional HTML system there are a variety of pages representing
the different stages in the logical transaction. First you look up
appropriate flights. You get back a URI representing the set of
appropriate flights. Then you choose a light. You get back a URI
representing your choice. Then you decide to commit. You get back a web
page that returns reservation number. Ideally the URL for that page will
persist for a reasonable amount of time so that you can bookmark it.
An XML based web service could go through the exact same steps. Rather
than returning HTML forms at each step, the service would return XML
documents conforming to a standard airline industry vocabulary. Those
same XML documents could be used on a completely different airline
reservation site to drive exactly the same process.
Summary: Any business problem can be thought of as a data resource
manipulation problem and HTTP is a data resource manipulation protocol.
Metcalfe's Law Revisited
Metcalfe's law is that the value of a network is proportional to the
square of the number of people on the network, because each pair of
people can make a connection between them. One telephone is useless. One
billion phones cause a major telecommunications revolution - if they can
all access each other through a single global naming system.
Metcalfe's law also applies to data objects. Elements in UDDI can only
(with a few exceptions) refer to each other. They cannot refer to
objects elsewhere on the Web (for instance in other UDDI repositories).
Similarly, objects on the Web (for instance web pages) cannot refer to
the XML elements in the UDDI repository. A URL-centric solution would
unify these data domains as the phone number system unifies telephones.
Security
Making your data universally addressable is not equivalent to making it
universally available! It is easy to hide objects by merely never
publishing their URIs. It is also easy to apply security policies to
objects. In fact, REST simplifies security greatly.
Under the SOAP RPC model, the objects that you work with are implicit
and their names are hidden in method parameters. Therefore you need to
invent a new security strategy for each and every web service. UDDI is
completely unlike .NET My Service which will likely be completely unlike
Liberty and so forth. Under REST, you can apply the four basic
permissions to each data object: GET permission, PUT permission, DELETE
permission and POST permission. You might also want to allow or disallow
GET/PUT/DELETE and POST on sub-resources. This model is exactly like the
one used for today's file systems! It is proven and it works. I know of
no security model that works in a similarly generic manner for remote
procedure call models.
Maintenance
In fact, security is just one form of maintainability that is simplified
by REST. Any network administrator will tell you that every level of
networking causes its own headaches. Some days IP works but DNS doesn't
(DNS server down or DNS settings misconfigured). Some days IP/DNS works
but HTTP doesn't (firewall or proxy misconfigured). If you run a web
service protocol on top of HTTP it will add its own layer of
configuration and software headaches on top of the existing ones. It
cannot be more reliable than its foundational HTTP layer. It can only
add one more layer of unreliability.
Once you have your service working, it is possible to "test" REST web
services just by looking at them in a browser. It is possible to make
simple HTML forms to test POSTs. QA departments can easily pretend to be
multiple users by changing their HTTP credentials. Standard web tools
can monitor availability. In essence, testing REST services is often
easy if you already know how to test web sites. On the other hand, every
SOAP RPC service will have its own security model, its own addressing
model, an implicit data model and its own set of methods. Of these four
things, only the security model is even currently a candidate for
standardization. Testing such a system is much more challenging.
The Rest of the Story
This brief introduction can only whet your appetite to the theory and
practice of REST-based web services. In an upcoming article, I will:
* describe in more detail how any web service can be transformed into a
URI-centric one.
* show how the REST philosophy and the XML philosophy are highly
compatible.
* show an example of a successful, public, widely used web service that
uses this model today.
* discuss the role of SOAP in these sorts of web services.
* discuss reliability, coordination, transactions, encryption, firewalls
etc.
If you would like to discuss these issue in the meantime, please
consider contributing to the rest-wiki
(http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage) and the REST
mailing list (http://groups.yahoo.com/group/rest-discuss/).
=============
> > Of course, conneg is still useful to expose, but lack of support in > browsers means that another means of doing this -- probably with > query strings (or maybe path parameters?) -- will have to be hacked. > > *sigh* I've used the ?method= approach for a couple years (actually used do:method for collision avoidance) to tunnel methods. I've also used ? accept= to tunnel Accept headers. Why not use the LDAP dn in the URL? For example, I wrote a servlet a while back to do stuff like this: http://www.xmldatasource.com:7779/xds/ldap2xml/ http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/ uid=myxie/ http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/ uid=myxie/?do:accept=text/xml Mike
--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote: > > On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote: > > Content negotiation could be used to negotiate a representation > > capable of expressing a form. > > I was hoping to allow requests to the record resource > http://www.example.com/addresses/thePerson > to negotiate the representation returned, so that the default would > be to return an HTML page, but if linked from an <img> element, the > image/jpeg in the jpegPhoto attribute would be returned. > Even if you tunnel Accept header in the URL (which means you need to control the server or have a generic intermediary that un-tunnels them) you'll want to consider strongly using sub-resource for images and stuff. If the URI space you design can address LDAP attributes, then you'd have the problem solved maybe?
John Barton has replied [1] to my e-mail, saying that his interpretation of REST is that POST is more appropriate than PUT. Still being a REST novice (and still, dammit, not having read the entirety of Roy's dissertation), what say you, rest-discuss? Does PUT have a place in REST? My instinct is that there is; while POST has the benefit of separating the data and representations, there are times when it's beneficial to say "here's a representation; when people request this resource in the future, give it to them." Does having such a direct relationship violate REST? [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0078.html On Tue, Jan 15, 2002 at 01:33:41PM -0800, Mark Nottingham wrote: > > I've raised an issue [1] with the XForms WG regarding their lack of > support for PUTing xml instance data. Supporting PUT would seem to be > very helpful to RESTful applications... > > [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/thread.html#47 > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
> John Barton has replied [1] to my e-mail, saying that his > interpretation of REST is that POST is more appropriate than PUT. > > Still being a REST novice (and still, dammit, not having read the > entirety of Roy's dissertation), what say you, rest-discuss? Does PUT > have a place in REST? Of course! How else can you explicitly set state and have intermediaries know about it (so they can cache it)? You can't do that with POST. > My instinct is that there is; while POST has the benefit of > separating the data and representations, there are times when it's > beneficial to say "here's a representation; when people request this > resource in the future, give it to them." Does having such a direct > relationship violate REST? I don't understand what you or John are referring to when you refer to a difference between "data" and the "representation". REST says nothing of "data", nor should it because it's hidden (if I understand what is meant by "data" - basically, the state in some raw form). I also don't know what John means by "The appropriate pair for REST is GET/POST". Why "pair"? Why restrict one's self to two methods for coordination when three is needed? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > I don't understand what you or John are referring to when you refer > to a difference between "data" and the "representation". REST says > nothing of "data", nor should it because it's hidden (if I understand > what is meant by "data" - basically, the state in some raw form). Mark N. believes (and without looking it up, I would guess he's right) that the semantics of PUT are that an immediately following GET should return the same representation that was just PUT. Whereas POST has no such semantic. So when they say "data" they mean a representation that is appropriate for GETing. > I also don't know what John means by "The appropriate pair for REST > is GET/POST". Why "pair"? Why restrict one's self to two methods > for coordination when three is needed? You claim that three is needed (why not four) but the web more or less gets by with two today! Paul Prescod
Mark Baker wrote: > >... > > Of course! How else can you explicitly set state and have > intermediaries know about it (so they can cache it)? You can't do that > with POST. Is this intermediary argument realistic? Let's say I'm going through a big honking cache at AOL. I do a PUT. Now all AOL users in the world have an updated view of the world because our cache recorded the PUT. But everyone else in the universe is out of date. Why should AOL users get a priviledged view of the world? Paul Prescod
> Mark N. believes (and without looking it up, I would guess he's right) > that the semantics of PUT are that an immediately following GET should > return the same representation that was just PUT. Actually, that's not quite right. There's content negotiation to be considered. > Whereas POST has no > such semantic. So when they say "data" they mean a representation that > is appropriate for GETing. > > > I also don't know what John means by "The appropriate pair for REST > > is GET/POST". Why "pair"? Why restrict one's self to two methods > > for coordination when three is needed? > > You claim that three is needed (why not four) but the web more or less > gets by with two today! REST doesn't limit the number of methods. You might need 10 to coordinate something complicated. The point here being that there's a whole whack load of things that can't be *efficiently* coordinated with GET/POST. Just look at Wiki. It's doing PUT with POST, and so misses out on an important optimization (caching PUTs). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > Of course! How else can you explicitly set state and have > > intermediaries know about it (so they can cache it)? You can't do that > > with POST. > > Is this intermediary argument realistic? Let's say I'm going through a > big honking cache at AOL. I do a PUT. Now all AOL users in the world > have an updated view of the world because our cache recorded the PUT. > But everyone else in the universe is out of date. Why should AOL users > get a priviledged view of the world? It only takes one person at MSN to do a GET on that same resource, and for MSN to cache that response, to have the same effect. This is a really small advantage in a write-few/read-many environment. I wouldn't worry about it. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > It only takes one person at MSN to do a GET on that same resource, and > for MSN to cache that response, to have the same effect. Right. So and of course the same goes for the original originator network AOL. So why worry about the caching of PUTs? The cache can just wait for the next GET. > This is a really small advantage in a write-few/read-many environment. > I wouldn't worry about it. That's my point! If PUTs have a small advantage over POST then why should we REST-ies spend our valuable moral capital fighting with FORMs peoples etc. over PUT. Well, I'm mostly playing the devil's advocate because of course fighting for the Right Thing is its own reward. ;) Seriously though, I'd rather have strong arguments in favour of PUT than this one which seems quite weak to me. Paul Prescod
Mark Baker wrote: > >... > > REST doesn't limit the number of methods. You might need 10 to > coordinate something complicated. The point here being that there's > a whole whack load of things that can't be *efficiently* coordinated > with GET/POST. Just look at Wiki. It's doing PUT with POST, and so > misses out on an important optimization (caching PUTs). I don't think I've seen a strong case that this optimization is important. Would Wiki be noticably better if it used PUT instead of POST? Paul Prescod
> > This is a really small advantage in a write-few/read-many environment. > > I wouldn't worry about it. > > That's my point! If PUTs have a small advantage over POST then why > should we REST-ies spend our valuable moral capital fighting with FORMs > peoples etc. over PUT. There's *currently* a small advantage; caching. There may be a larger advantag > Well, I'm mostly playing the devil's advocate > because of course fighting for the Right Thing is its own reward. ;) > Seriously though, I'd rather have strong arguments in favour of PUT than > this one which seems quite weak to me. I'm not rabid about the need for PUT in XForms. It wouldn't be a replacement for having user agents supporting it as a "File->Save" type operation. I'd see it mostly used for creating new resources, where the content provider could specify the URI for the new resource. Developers shouldn't commonly use PUT with XForms to try and replace this missing functionality from user agents. But hopefully any user agent supporting XForms and PUT would go the next step and support PUT more generally like Amaya. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> I don't think I've seen a strong case that this optimization is > important. Would Wiki be noticably better if it used PUT instead of > POST? Oopsie with that last message. I'll continue my thought here. There's *currently* a small efficiency advantage in having PUT as its own method; caching. But safety is also an issue. Permitting the PUT method to go behind a firewall is a much safer thing to do than permitting POST, for example, because PUT behaviour is much more narrowly defined. I would expect that there's other good reasons too, but that's all that I can think of right now. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Wed, Jan 16, 2002 at 02:22:33PM -0500, Mark Baker wrote:
> > Mark N. believes (and without looking it up, I would guess he's right)
> > that the semantics of PUT are that an immediately following GET should
> > return the same representation that was just PUT.
>
> Actually, that's not quite right. There's content negotiation to be
> considered.
From 2616 (section 9.6, PUT)
The PUT method requests that the enclosed entity be stored under
the supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI.
[...]
This seems to imply that in the case of PUT, the Web *is* a
filesystem ("be stored under").
If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be
treated as stale. Responses to this method are not cacheable.
So this blows away the caching arguments; in that sense, it's
equivalent to POST.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway
to some other protocol, or a separate entity that accepts
annotations. In contrast, the URI in a PUT request identifies the
entity enclosed with the request -- the user agent knows what URI
is intended and the server MUST NOT attempt to apply the request to
some other resource. If the server desires that the request be
applied to a different URI, it MUST send a 301 (Moved Permanently)
response; the user agent MAY then make its own decision regarding
whether or not to redirect the request.
This *seems* to limit the effects of a PUT to the identified
resource, as well as support the 'filesystem' view. This also
theoretically makes the 'accept=...' hacks even hackier, because a
PUT would indeed affect the state of other resources (i.e., the
resource identified with the accept=... hack, vs. the one identified
w/o it). Which means tha tthe accept=... hack shouldn't be available
on PUTed requests; only POSTs (which can use a method=... hack).
HTTP/1.1 does not define how a PUT method affects the state of an
origin server.
I'd like to know what the intent of this is; it doesn't say state of
the *resource*, but state of the *origin server*.
Unless otherwise specified for a particular entity-header, the
entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT.
And this seems to cover conneg. I read this as saying "if it has a
'Content-Foo: bar' request header, negotiate subsequent GETs as if
it's Foo is bar." This view seems to be supported by:
The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases.
--
Mark Nottingham
http://www.mnot.net/
On Wed, Jan 16, 2002 at 11:33:14AM -0800, Paul Prescod wrote: > Seriously though, I'd rather have strong arguments in favour of PUT than > this one which seems quite weak to me. I agree. -- Mark Nottingham http://www.mnot.net/
On Wed, Jan 16, 2002 at 01:10:13PM -0800, Mark Nottingham wrote: > The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a > POST request identifies the resource that will handle the enclosed > entity. That resource might be a data-accepting process, a gateway > to some other protocol, or a separate entity that accepts > annotations. In contrast, the URI in a PUT request identifies the > entity enclosed with the request -- the user agent knows what URI > is intended and the server MUST NOT attempt to apply the request to > some other resource. If the server desires that the request be > applied to a different URI, it MUST send a 301 (Moved Permanently) > response; the user agent MAY then make its own decision regarding > whether or not to redirect the request. And this, BTW, is why (I think) PUT's semantics can't be replaced with POST-with-connneg. It's conceivable that a resource will accept POSTs of media type foo/bar, but also return representations of media type foo/bar upon GET. Therefore, it's necessary to have an operation that allows one to change the representations returned as opposed to submitting a representation for processing. This is admittedly far-fetched (I have difficulty coming up with an example), but IMHO that's mostly because of the limitations of browsers, not the concept of a resource. -- Mark Nottingham http://www.mnot.net/
> > Actually, that's not quite right. There's content negotiation to be
> > considered.
>
> >From 2616 (section 9.6, PUT)
>
> The PUT method requests that the enclosed entity be stored under
> the supplied Request-URI. If the Request-URI refers to an already
> existing resource, the enclosed entity SHOULD be considered as a
> modified version of the one residing on the origin server. If the
> Request-URI does not point to an existing resource, and that URI is
> capable of being defined as a new resource by the requesting user
> agent, the origin server can create the resource with that URI.
> [...]
>
> This seems to imply that in the case of PUT, the Web *is* a
> filesystem ("be stored under").
It's unclear. I'd agree with what's written iff the resource in
question was known to be a variant of some other resource. But I've
almost thought that invoking PUT on a known variant resource is bad
practice - why not just PUT to the non-variant (primary) resource?
Hmm, maybe because variants are most likely to be cacheable?
Anyway you look at a set of variant resources though, if you effect
a state change on one, the others should all change. From a cache
validity POV, the important thing is that the cache knows what
the variants are (which Content-Location would have told it, if it
was paying attention).
> If the request passes through a cache and the Request-URI identifies
> one or more currently cached entities, those entries SHOULD be
> treated as stale. Responses to this method are not cacheable.
>
> So this blows away the caching arguments; in that sense, it's
> equivalent to POST.
I don't think so. It says that the request invalidates whatever's
already in the cache, which is a given. It also says that the response
to the PUT is not cacheable, which is fine because side effects are
involved. It doesn't say that the request entity can't be used as
a cached request response, though I know that this isn't default
behaviour and that you'd have to futz with Cache-Control (though
I haven't looked into how you'd do this).
> The fundamental difference between the POST and PUT requests is
> reflected in the different meaning of the Request-URI. The URI in a
> POST request identifies the resource that will handle the enclosed
> entity. That resource might be a data-accepting process, a gateway
> to some other protocol, or a separate entity that accepts
> annotations. In contrast, the URI in a PUT request identifies the
> entity enclosed with the request -- the user agent knows what URI
> is intended and the server MUST NOT attempt to apply the request to
> some other resource. If the server desires that the request be
> applied to a different URI, it MUST send a 301 (Moved Permanently)
> response; the user agent MAY then make its own decision regarding
> whether or not to redirect the request.
>
> This *seems* to limit the effects of a PUT to the identified
> resource, as well as support the 'filesystem' view. This also
> theoretically makes the 'accept=...' hacks even hackier, because a
> PUT would indeed affect the state of other resources (i.e., the
> resource identified with the accept=... hack, vs. the one identified
> w/o it). Which means tha tthe accept=... hack shouldn't be available
> on PUTed requests; only POSTs (which can use a method=... hack).
I agree. I don't like that wording. Though what it says is mostly
true, it's a bit misleading because it chooses to avoid defining the
meaning of PUT independant of the Request-URI, which can be done.
If you consider the Request-URI always identifies the resource upon
which the method applies, then the meaning of PUT and POST can easily
be defined in those terms. i.e. PUT = replace or create the identified
resource, POST = submit/add to the identified resource.
> HTTP/1.1 does not define how a PUT method affects the state of an
> origin server.
>
> I'd like to know what the intent of this is; it doesn't say state of
> the *resource*, but state of the *origin server*.
Yah, me too.
> Unless otherwise specified for a particular entity-header, the
> entity-headers in the PUT request SHOULD be applied to the resource
> created or modified by the PUT.
>
> And this seems to cover conneg. I read this as saying "if it has a
> 'Content-Foo: bar' request header, negotiate subsequent GETs as if
> it's Foo is bar." This view seems to be supported by:
>
> The recipient of the entity MUST NOT ignore any Content-*
> (e.g. Content-Range) headers that it does not understand or implement
> and MUST return a 501 (Not Implemented) response in such cases.
Right. No problem there. That's where my Subject-is-Representation
header would come in handy too. No need to assume an entity header
starts with "Content-";
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpAndTheSemanticWeb
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
I have been fooling around with asynch services lately, and of course an important issue is HTTP. What I'm going to write here is a fairly rambling note to explore related issues. I am hoping that others will help tease apart the issues, which I have found interesting but easy to get lost in. Asynch mode matters a lot. We can't live without it. Asynch HTTP is a funny idea. There seem to be incompatibilities large and small. Without asynch HTTP, there is no asynch REST. That is not acceptable. Asynchronous infrastructure is nearly always too optimistic about the time frame -- a coherent thread of messages is assumed to be complete within the lifetime of a sending application. In reality the lifetimes of messages and processes are different things. Furthermore, asynch infrastructure is limited in scope and generality. Aside from email, asynch infrastructure is an anarchic bag of incompatible technologies like JMS/RMI, proprietary real time financial data protocols, the Gnutella protocol, SOAP 1.2, Jxta, etc ad infinitum. HTTP and email share a basket of technologies, mainly MIME but also the end to end principle and many similar semantics. It is straightforward to model SMTP in terms of HTTP, and not extremely hard to model HTTP in terms of SMTP. Given that the output of a series of SMTP commands is a MIME message, you can think of it as a marginally different animal. The biggest difference is that SMTP lacks syntactic support for the HTTP target URI header line, as well as having no semantic equivalent. POP3 does a clean job of diffentiating a message store from its contents. ...less so IMAP, which integrates the semantics of text messaging and store-and-forward. If the basic message of REST is that, per Jeff Bone, "the *existing* Web and its abstractions and mechanisms --- if used properly --- obviate the need for a large number of the things people seem dead-set on creating new mechanisms to do", the exact same argument applies to efforts to create a newly asynchronous HTTP, which existing email infrastructure obviates much of the need for. Asynchronous REST implies email for the same reasons that synchronous REST implies the web. HTTP proxy semantics and SMTP forwarder semantics clash. SMTP intermediaries and endpoints are basically symetrical, while HTTP intermediaries have a dedicated role and command set. ...my inclination is to work on mashing together HTTP and SMTP. Thoughts why this might be a blind alley? Is there any interest in shared hacking on such a project?
> HTTP proxy semantics and SMTP forwarder semantics clash. SMTP intermediaries > and endpoints are basically symetrical, while HTTP intermediaries have a > dedicated role and command set. > > ...my inclination is to work on mashing together HTTP and SMTP. Thoughts why > this might be a blind alley? Is there any interest in shared hacking on such a > project? Do you believe that email is asynchronous because it arrives without a request going out for it? If so, how is that any different from an HTTP message arriving without prompting (i.e. if you're the web server). For the record, I'm all for introducing asynchronous notifications into HTTP. I'll just refrain from suggesting how it should be done until I understand what you're asking, lest I confuse things by introducing a solution too early. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> Do you believe that email is asynchronous because it arrives without a > request going out for it? No. I believe that it is asynchronous -- much moreso than HTTP -- because it has broad support for the whole gamut of issues that come up with regard to asynchronicity. For example, it fixes the issue of message lifetimes being out of synch with process lifetimes; it supports dynamically determined routing paths; forwarders know to retry over some fairly long interval; via POP it has strong support for transient nodes; it has a reply-to header for activating callbacks; implementations already handle much longer message lifetimes by writing them to disk; it has POP3 to support the semantics of message stores; it has a broad deployed base of forwarders and temporary storage depots. > For the record, I'm all for introducing asynchronous notifications into > HTTP. I'll just refrain from suggesting how it should be done until I > understand what you're asking, lest I confuse things by introducing a > solution too early. Please do introduce and suggest.
> No. I believe that it is asynchronous -- much moreso than HTTP -- because it > has broad support for the whole gamut of issues that come up with regard to > asynchronicity. For example, it fixes the issue of message lifetimes being out > of synch with process lifetimes; it supports dynamically determined routing > paths; forwarders know to retry over some fairly long interval; via POP it has > strong support for transient nodes; it has a reply-to header for activating > callbacks; implementations already handle much longer message lifetimes by > writing them to disk; it has POP3 to support the semantics of message stores; it > has a broad deployed base of forwarders and temporary storage depots. To me, none of those are specifically asynchronous issues. They're mostly stateless issues. And HTTP satisfies each of them (ok, we need a reply-to header - see below). This is important because it explains why what I have below is so simple. > > For the record, I'm all for introducing asynchronous notifications into > > HTTP. I'll just refrain from suggesting how it should be done until I > > understand what you're asking, lest I confuse things by introducing a > > solution too early. > > Please do introduce and suggest. Let me start by saying that REST, like all architectures, works by placing restrictions on component interaction. The fundamental REST restriction is that interactions are limited to semantics that apply to things with identity, aka resources. So the question is (assuming we've already decided we need asynch 8-), when do things with identity need to send event notifications? The answer that KnowNow came up with is "When they change state". I haven't kept up with what they've been implementing, but I recall talking with Rohit about a "WATCH" method (Roy suggested the name). It works this way (I'm not saying KnowNow does this, only this is how it could work - there may be better ways too, but the request line won't change); WATCH http://www.yahoo.com HTTP/1.1 Reply-To: http://mysite.org/yahoo-watch This is a request to the resource to notify the Reply-To URI (via POST) when www.yahoo.com changes state. *What* the notification looks like is up for grabs, there are lots of possibilities and the request can be configured to ask for something specific (e.g. a delta encoding, just the URI, a full representation, etc..). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
So, I'm inclined to make the jpg a subresource (along with other attributes), but this leaves me with a bit of a headache; how do I identify an HTML-editable version of the resource? If I make it another subresource, e.g., .../thePerson/editform there's the (theoretical) possibility of a namespace clash. So, I can either define sub-sub-resources .../thePerson/attr/jpegPhoto .../thePerson/other/editform which is icky, or I can use a query arg or attribute; .../thePerson?repr=editform --or-- .../thePerson;editform In combination with the method and conneg hacks, then, I could have .../thePerson?repr=editform&method=PUT&accept=text/xml (not really applicable to this representation, but you get the idea) I think I like using a parameter best; is there any semantic difference worth noting (from a REST standpoint) between query args and parameters? Regarding putting the DN in the URI; I was concerned about typability, etc., until it occured to me earlier today that I could have a "typeable" interface optimised for people hand-typing URIs, jsut as there's a search interface optimised for HTML form submission; e.g., http://addresses.example.org/name/Mark+Nottingham or somesuch. On Wed, Jan 16, 2002 at 08:01:03AM -0000, mdierken wrote: > > > > > Of course, conneg is still useful to expose, but lack of support in > > browsers means that another means of doing this -- probably with > > query strings (or maybe path parameters?) -- will have to be hacked. > > > > *sigh* > > I've used the ?method= approach for a couple years (actually used > do:method for collision avoidance) to tunnel methods. I've also used ? > accept= to tunnel Accept headers. > > Why not use the LDAP dn in the URL? > For example, I wrote a servlet a while back to do stuff like this: > > http://www.xmldatasource.com:7779/xds/ldap2xml/ > > http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/ > uid=myxie/ > > http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/ > uid=myxie/?do:accept=text/xml > > Mike > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
> So the question is (assuming we've already decided we need asynch 8- ), > when do things with identity need to send event notifications? > > The answer that KnowNow came up with is "When they change state". I > haven't kept up with what they've been implementing, but I recall > talking with Rohit about a "WATCH" method (Roy suggested the name). > > It works this way (I'm not saying KnowNow does this, only this is > how it could work - there may be better ways too, but the request > line won't change); > > WATCH http://www.yahoo.com HTTP/1.1 > Reply-To: http://mysite.org/yahoo-watch > > This is a request to the resource to notify the Reply-To URI (via POST) > when www.yahoo.com changes state. *What* the notification looks like > is up for grabs, there are lots of possibilities and the request can > be configured to ask for something specific (e.g. a delta encoding, > just the URI, a full representation, etc..). > Yes - this is the basic idea. They use 'route' rather than 'watch'. There are other magic bits in there also (like a javascript client that receives via persisitent response, kn_expires, kn_response_format for content negotiation (they should've used 'accept', the weasels)). One trick that I'm not sure how to accomplish is the identification of what the event is 'about' when it is a multi-hop. Is there a 'topic' header or something? KN uses kn_routed_from to identify that latest URI the message has passed through. (and I don't want to hear about using an xml namespace for this... more weasels) KnowNow docs at: http://developer.knownow.com/devguide/docs/routers/knrouterapi.html Setting up a subscription: http://www.yahoo.com?do_method=route&kn_to=http://mysite.org/yahoo- watch They also use kn_id to identify an event - useful for supressing duplicates and correlating replies.
--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote: > > In combination with the method and conneg hacks, then, I could have > .../thePerson?repr=editform&method=PUT&accept=text/xml > (not really applicable to this representation, but you get the idea) Not sure if I understand method=PUT and accept together. PUT would have a content-type though. Identifying the editable representation is a bother. Once I tried uri?method=edit but didn't like that, so ditched it before anybody noticed. Tried uri?layout=editor - moving in the right direction. Kept that for a while. Don't know what to try next. Maybe uri?view=editor - 'view' is a wonderfully ambigous noun/verb. Mike
--- In rest-discuss@y..., "mdierken" <mdierken@y...> wrote: > --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote: > Identifying the editable representation is a bother. > Once I tried uri?method=edit but didn't like that, so ditched it > before anybody noticed. > Tried uri?layout=editor - moving in the right direction. Kept that > for a while. > > Don't know what to try next. Maybe uri?view=editor - 'view' is a > wonderfully ambigous noun/verb. > Another reason to use 'view' is when accessing a heirchical collection of information or a database-like thing it can be fun to talk about 'slices' or 'views' thorough a multi-dimensional space. Although it might not make as much sense when I wake up tomorrow...
Mark, Something like WATCH is definately part of the solution! But it is only part of the solution -- there is much new code to be written to make it work. For example, > WATCH http://www.yahoo.com HTTP/1.1 > Reply-To: http://mysite.org/yahoo-watch You are assuming that this call can be emitted synchronously. Before the new WATCH method can solve anything, it has to be received. What if the caller, the caller's proxy, or the recipient is temporarily offline? In the context of request/response, you only emit calls that make sense if they complete in the present. In the context of publish/subscribe you may emit calls that don't have any results until a fuzzy point in the future, so it may not matter if the call is emitted immediately. In the above example, the client should be able to cache the call until it goes online. Such a local cache would be just like a local outbox. That is: =========== User software has an application-defined need to send a subscription message. This might be an application subscribing to a stock ticker. The user software finds that the user is offline, hence the message can't be sent. It caches the message and initiates a polling loop against the remote resource provider. =========== Notice the similarity with a mail user agent attempting to publish a text message via email. The sending application should not do the polling, because there may be many such sending applications. Instead the sending application should submit the send to a system-wide outbound queue and leave the polling to a single daemon. =========== An application publishes a subscription message to a stock ticker. Because the endpoint is offline, the message is submitted to an outbound queue. A daemon minding the queue and polling to discover online mode eventually finds that the endpoint is online. However the ticker publisher is not online at that moment. The daemon submits the subscription event to a third party dropbox maintaned by the ticker publisher. =========== Again, these semantics are covered by mail infrastructure already but not by web infrastructure. Let's not get bogged down in this slightly wierd point that email is more RESTy than the web. The first point is that _sender_ asynchronicity means assuming that every single hop may be an emission that requires store-and-forward. KnowNow's architecture requires a special new server, the event router. What is an event router but a store-and-forward node? (uh, well, it's also a topic coordinator. That's too big a can of worms for this message.) - Lucas
> A daemon minding the queue and polling to discover online mode > eventually finds that the endpoint is online. > However the ticker publisher is not online at that moment. > The daemon submits the subscription event to a third party dropbox maintaned by > the ticker publisher. > =========== > Why not publish to that third party dropbox to begin with? A.M.
> However the ticker publisher is not online at that moment. > The daemon submits the subscription event to a third party dropbox maintaned by > the ticker publisher. Is it a subscription 'event' or a subscription 'request'? To me, an event is a notification that state changed - things will still work from the senders point of view if the receiver ignores the message. A request is a plea from the sender to make something happen and if it isn't possible, let the sender know. It interesting to note that a 'notify' method isn't needed. You can pretty much echo stuff that happens after the subscription to the subscribers. But what do you echo? The follow-on requests or the responses (considering purely HTTP)? Or both? Or do you only echo a request when a success response occurrs? Fun stuff.
Mark Baker wrote: > >... > > WATCH http://www.yahoo.com HTTP/1.1 > Reply-To: http://mysite.org/yahoo-watch > Is there any move to specify this somewhere on the Web? It's a little unfair for us to tell people that HTTP does everything you need and then say that we mean: "after adding an HTTP extension." Paul Prescod
> Is there any move to specify this somewhere on the Web? It's a little > unfair for us to tell people that HTTP does everything you need and then > say that we mean: "after adding an HTTP extension." Well, technically, you could do it without a new method. It just wouldn't look as pretty; GET http://www.yahoo.com response; HTTP/1.1 200 OK Properties: http://www.yahoo.com/properties next invocation; -- POST http://www.yahoo.com/properties;watch Content-Type: text/uri http://myhost.org/yahoo-watch -- response; HTTP/1.1 201 Created Location: http://www.yahoo.com/watch/2342343 this invocation unsubscribes you; DELETE http://www.yahoo.com/watch/2342343 and then you're unsubscribed. You'd still need to agree on what a "watch" property is though, so I guess that still counts as an extension. Never mind. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> Mark, > > Something like WATCH is definately part of the solution! But it is only part of > the solution -- there is much new code to be written to make it work. For > example, > > > WATCH http://www.yahoo.com HTTP/1.1 > > Reply-To: http://mysite.org/yahoo-watch > > You are assuming that this call can be emitted synchronously. Before the new > WATCH method can solve anything, it has to be received. True, but I don't say *who* has to receive it! > What if the caller, the > caller's proxy, or the recipient is temporarily offline? Then let the recipient have a proxy that queues up these requests. > In the context of > request/response, you only emit calls that make sense if they complete in the > present. In the context of publish/subscribe you may emit calls that don't have > any results until a fuzzy point in the future, so it may not matter if the call > is emitted immediately. Ok. > In the above example, the client should be able to cache the call until it goes > online. Such a local cache would be just like a local outbox. That is: > =========== > User software has an application-defined need to send a subscription message. > This might be an application subscribing to a stock ticker. The user software > finds that the user is offline, hence the message can't be sent. It caches the > message and initiates a polling loop against the remote resource provider. > =========== Right. See above. > Notice the similarity with a mail user agent attempting to publish a text > message via email. The sending application should not do the polling, because > there may be many such sending applications. Instead the sending application > should submit the send to a system-wide outbound queue and leave the polling to > a single daemon. > > =========== > An application publishes a subscription message to a stock ticker. Because the > endpoint is offline, the message is submitted to an outbound queue. A daemon > minding the queue and polling to discover online mode eventually finds that the > endpoint is online. However the ticker publisher is not online at that moment. > The daemon submits the subscription event to a third party dropbox maintaned by > the ticker publisher. > =========== > > Again, these semantics are covered by mail infrastructure already but not by web > infrastructure. You sure about that? > Let's not get bogged down in this slightly wierd point that email is more RESTy > than the web. The first point is that _sender_ asynchronicity means assuming > that every single hop may be an emission that requires store-and-forward. > KnowNow's architecture requires a special new server, the event router. What is > an event router but a store-and-forward node? (uh, well, it's also a topic > coordinator. That's too big a can of worms for this message.) Heh. It's just a web app, nothing more. Pipeline + statelessness = great (email) Pipeline + statelessness + generic semantics = awesome (Web) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I think we're getting a little bit confused re: what async means in this context. There are at least two orthogonal dimensions of interest: asynchronous communication of request and a possible future response stream, and asynchrony -wrt- connectivity at a given point in time, i.e., the idea that the sender and receiver must be able to communicate at a given instance, hence must both be online. The first is simply "callbacks" --- even pub / sub, watching, etc. is a higher-level metaphor over simple callbacks. Callbacks have no topological implications / require no new connector types and --- as Mark points out --- don't even require protocol extensions. The second is store-and-forward, where the sender and receiver need not necessarily have instantaneous connectivity. Store-and-forward requires a number of things: more complex intermediary services, a notion (at least minimal) of routing, etc. Just a point of clarification --- these are independent things. Another interesting semi-related thing to consider is the impact of communication *assymetry* --- the fact that sending and receiving roles are not the same as connection initiator and connection receiver, i.e. "client" and "server." $0.02 jb Mark Baker wrote: > > Mark, > > > > Something like WATCH is definately part of the solution! But it is only part of > > the solution -- there is much new code to be written to make it work. For > > example, > > > > > WATCH http://www.yahoo.com HTTP/1.1 > > > Reply-To: http://mysite.org/yahoo-watch > > > > You are assuming that this call can be emitted synchronously. Before the new > > WATCH method can solve anything, it has to be received. > > True, but I don't say *who* has to receive it! > > > What if the caller, the > > caller's proxy, or the recipient is temporarily offline? > > Then let the recipient have a proxy that queues up these requests. > > > In the context of > > request/response, you only emit calls that make sense if they complete in the > > present. In the context of publish/subscribe you may emit calls that don't have > > any results until a fuzzy point in the future, so it may not matter if the call > > is emitted immediately. > > Ok. > > > In the above example, the client should be able to cache the call until it goes > > online. Such a local cache would be just like a local outbox. That is: > > =========== > > User software has an application-defined need to send a subscription message. > > This might be an application subscribing to a stock ticker. The user software > > finds that the user is offline, hence the message can't be sent. It caches the > > message and initiates a polling loop against the remote resource provider. > > =========== > > Right. See above. > > > Notice the similarity with a mail user agent attempting to publish a text > > message via email. The sending application should not do the polling, because > > there may be many such sending applications. Instead the sending application > > should submit the send to a system-wide outbound queue and leave the polling to > > a single daemon. > > > > =========== > > An application publishes a subscription message to a stock ticker. Because the > > endpoint is offline, the message is submitted to an outbound queue. A daemon > > minding the queue and polling to discover online mode eventually finds that the > > endpoint is online. However the ticker publisher is not online at that moment. > > The daemon submits the subscription event to a third party dropbox maintaned by > > the ticker publisher. > > =========== > > > > Again, these semantics are covered by mail infrastructure already but not by web > > infrastructure. > > You sure about that? > > > Let's not get bogged down in this slightly wierd point that email is more RESTy > > than the web. The first point is that _sender_ asynchronicity means assuming > > that every single hop may be an emission that requires store-and-forward. > > KnowNow's architecture requires a special new server, the event router. What is > > an event router but a store-and-forward node? (uh, well, it's also a topic > > coordinator. That's too big a can of worms for this message.) > > Heh. It's just a web app, nothing more. > > Pipeline + statelessness = great (email) > Pipeline + statelessness + generic semantics = awesome (Web) > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote: > >... > > You'd still need to agree on what a "watch" property is though, > so I guess that still counts as an extension. Never mind. 8-) Anyhow, you get my point. Eventually the REST world needs to standardize this or agree that HTTP just doesn't handle the problem of asynch. It's one of the weakest points of REST rhetoric. But there are others. On that note, I've modified the REST wiki FAQ with a bunch of common FAQs. Here are the questions I changed or added. http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq ==== ** What do you mean when you say RPC? We mean that each developer defines their own methods and makes them available for remote invocation over the Internet. With this definition, REST can be said to use RPC, because it defines the methods for the developers so that they don't have to worry about them. Most applications that self-identify as using "RPC" do not adhere to the REST philosophy. In particular, they use a single URL to represent the end-point instead of using a multitude of URLs representing every interesting data object. Then they hide their data objects behind method calls and parameters, making them unavailable to applications built around the Web architecture. REST-based services give addresses to every useful data object and use the resources themselves as the targets for method calls (typically using HTTP methods). ** Are REST and RPCs incompatible? Except for the proviso in the previous FAQ item, and that REST provides for defining new methods (as long as they operate on resources), then the answer is yes. REST is incompatible with "end-point" RPC. Either you address data objects or you address "software components". REST does the former. End-point RPC does the later. You can try to contort RPC protocols into working on data object URIs but then you end up re-inventing a non-standard variant of HTTP. ** Is the concept of Web Services incompatible with REST? One answer is that there is no firm definition of WebServices. But REST seems to be compatible with most of the definitions floating around. It is not compatible with definitions that take SOAP-RPC as a starting point. (but then why would you define the problem space around an implementation technology?) Most applications that call themselves "web services" use an end-point RPC philosopy. ** What if I need to do a GET but my query is not something that can be fit into a URL? MarkBaker has addressed this and defended it in discussion. Someday somebody should write a more unified discussion of this design and its defence. But in the meantime, ask yourself how often this problem arises in real-world situations. GET is restricted to a single-URL line and that sort of enforces a good design principle that everything interesting on the web should be URL-addressable. If you want to make a system where interesting stuff is not URL-addressable then you need to justify that decision. Typically "contorting" your application around GET's limitations makes the application better by forcing it into the web architecture. ** How does HTTP handle reliable delivery? Good question...there's an answer but nobody has typed it in yet. PaulPrescod claims that the gist of it is that reliable delivery is more of a characteristic of software than of a protocol. After all, there is no way that some fancy transaction monitoring program like MQSeries can prevent someone from pulling a network cable out in the middle of a message. The best it can do is try to re-send the message. This implies that the protocol can help by having some kind of message-id. HTTP does need an extension for this. Any volunteers to write this up? ** How does HTTP handle asynchronous delivery? There is no standardized solution yet. You need an HTTP extension. The outlines of one were discussed on rest-discuss. Also, you should probably learn about Adam and Rohit's work on notify. ** How does HTTP handle transactions: multiple step commands that are rolled back together if any one fails? Good question...while you wait for an answer let's ask how SOAP, XML-RPC etc. handle transactions? The answer is mostly: "it is the client's responsibility". I think that's the REST answer also. The database concept of transactions does not scale well to the Web because clients will start transactions and then just forget about them. This doesn't just tie up server resources: it also has severe locking consequences. Essentially some other user could be locked out waiting for the transaction to complete. On the other hand, if the clients take full responsibility for reversing their own transactions then the server will not try to do any locking etc. ** Can REST really beat RPC when the whole software industry is pushing RPC-like solutions? If REST works and RPC doesn't then yes, REST can win. Some of us believe that. Notice how the course of SOAP started as pure RPC and has been moving further and further away from it? Perhaps that is early evidence of an industry shift. Also, how many RPC-based web services are really deployed and in-use on the Web? SOAP and XML-RPC have been around for years and yet there is no killer app! REST can point to the Web itself as proof that it works. If you want to see REST used with XML-RPC then I'd suggest you look at Meerkat, which is a massively scalable application, incorporating content from hundreds of sites. It does so by using plain old HTTP. Is there any equivalent SOAP or XML-RPC API that is widely implemented in an interoperable fashion? It seems the answer is: "not yet." ** What does a REST message look like? REST is just an architctural style. HTTP is the protocol that is most in tune with the style, and the one used by the largest REST application, the World Wide Web. URIs are the addressing mechanism for that application. REST can support any media type, but XML is expected to be the most popular transport for structured information. REST is already used today with HTML, XHTML, RSS and various proprietary XML vocabularies. Unlike SOAP and XML-RPC, REST does not really require a new message format. Just use HTTP and the most appropriate XML vocabulary! ** I need my app to work with non-HTTP protocols. Does REST still apply? First, are you sure you need your app to work with non-HTTP protocols, or is that just what you were told? Perhaps if you read the rest of this page you'll learn to use HTTP in ways that obviate the need for other protocols. Consider carefully how hard it is to deploy new protocols across firewalls. If HTTP can be used for instant messaging (Magi), content management (WebDAV) and P2P (see above) then what did you have in mind that is outside of its scope? Second, if you really do need non-HTTP (e.g. to talk to a village in Zambia with only UUCP access) then have you considered tunnelling HTTP over that protocol? HTTP is pretty simple...basically just a couple of headers and you are done! Paul Prescod
On Thu, 17 Jan 2002, Paul Prescod wrote: > [would you mind moving this to rest-discuss? There was near a FORK > rebellion last time] Ok. On both MIME-RPC and rest-discuss. > "S. Alexander Jacobson" wrote: > > > > On Wed, 16 Jan 2002, Paul Prescod wrote: > > > > > "S. Alexander Jacobson" wrote: > > > > > > > > Ok. So, if I want to send a message to an HTTP > > > > server and have it call back my HTTP server later, > > > > how do I specify that? > > > > I don't think you answered this one at all. > > Sorry. http://groups.yahoo.com/group/rest-discuss/message/38 Great. So the answer is the same as MIME-RPC. Add another mime header. As I said before, I think we are largely in agreement on most things. I think MIME-RPC formalizes much of the wire level stuff REST proponents advocate. The main difference between Reply-To as described in this message and Reply-To-URL as described in the MIME-RPC spec is that the later is suitable for use both in email and in HTTP while the former only works in HTTP. The main point of REST seems to be that things should exist in terms of URIs, but it seems to insist on only allowing HTTP uris. Why not allow HTTPS URIs or mailto uris? > > I completely agree. In MIME, that record format > > is called a "content-type". MIME even defines a > > procedure for getting organizations to agree on > > the name for that type. It is RFC 2048. With > > MIME-RPC, you would send e.g. > > > > --- > > content-type: application/x-employee > > > > OPAQUE DATA THAT IS INTERPRETED BY A MIME-RPC > > IMPLEMENTATION IN ACCORDANCE WITH THE SPEC FOR > > THIS FORMAT -- THE FORMAT MIGHT BE BINARY!!! > > --- > > Okay, but that's just *MIME*. MIME-RPC is adding no value here! If REST is just using the existing web, then I would ask the same question of REST. MIME-RPC simply formalizes common practice in using MIME for messaging to applications rather than people. The value it provides is simply a formalization of existing practice. I think REST provides a philosophy. MIME-RPC provides a wire format. > >... > > MIME-RPC encourages #2. The point is that for > > massive interoperability, applications need to be > > able to send each other messages that may include > > objects of various types packaged together. MIME > > is a well defined and well used mechanism for > > doing exactly that. > > Nobody disputes the value of MIME. For a while, even Microsoft was in > favor...before they invented "DIME". I'm asking about the value of > MIME-RPC. Adding RPC to MIME is not exciting to a REST-er since REST is > an alternative model to RPC! Please define your use of RPC. My use of RPC is simply that the recipient of the message is an application rather than a person. I think we are in agreement about most things. I am just trying to provide a short reference document for application developers. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > > Ok. On both MIME-RPC and rest-discuss. Okay. >... > The main point of REST seems to be that things > should exist in terms of URIs, but it seems to > insist on only allowing HTTP uris. Why not allow > HTTPS URIs or mailto uris? HTTPS is REST-compatible. The problem with mailto is I can't dereference it. I can only send information to it and the information goes into a black hole. That's against the REST philosophy. If email were designed according to REST then every email message would have a globally unique identifier and you would reply to a message by POSTing to the identifier (which you can't do with an SMTP unique identifer). >... > > I think REST provides a philosophy. MIME-RPC > provides a wire format. Right, REST is a philosophy. The wire format is already HTTP + MIME + XML. What does MIME-RPC add? >... > Please define your use of RPC. My use of RPC is > simply that the recipient of the message is an > application rather than a person. This may help: http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq Paul Prescod
> The problem with mailto is I can't dereference it. I can only send > information to it and the information goes into a black hole. That's > against the REST philosophy. If email were designed according to REST > then every email message would have a globally unique identifier and you > would reply to a message by POSTing to the identifier (which you can't > do with an SMTP unique identifer). Actually, that's not quite true. Consider telnetting to a mailto/SMTP HTTP proxy and entering; GET mailto:distobj@... The response could be an HTML email style form (ala Hotmail) with the To field filled in, a textarea where I type my message, and a submit button that sends the email. In fact, I assert that everything that has a URI, has at least one useful response to a GET. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
======= MIME-RPC example: POST /some/resource HTTP/1.1 Content-type: application/x-www-form-urlencoded 0=example.getStateName&1=10023 ======= REST example: GET /states/10023 HTTP/1.1 (the response is the same) ======= MIME-RPC example: POST /some/resource HTTP/1.1 Content-type: application/x-www-form-urlencoded 0=example.getTeam&state=New%20York&sport=Baseball HTTP/1.1 200 OK Content-type: multipart/mixed, boundary=B --B Yankees --B Mets --B ======= REST (with XML) equivalent: GET /teams?state=New%20York&sport=Baseball HTTP/1.1 HTTP/1.1 200 OK <teams xmlns="...someurl.com"> <team>Yankees</team> <team>Mets</team> </teams> ======= MIME-RPC: POST /some/resource HTTP/1.1 Content-type: application/x-www-form-urlencoded 0=example.addUser&fname=Igna%ACio&lname=Sanchez ======= REST version: POST /users HTTP/1.1 Content-type: text/plain Igna Sanchez ===== Main differences: * rather than "wasting" the HTTP URL slot with /some/resource, the resource is the thing you are acting upon * when you're doing something idempotent, use GET, not POST * use XML for structuring text rather than MIME. * more compact * easier to read * can use schema for validation Paul Prescod
> > The problem with mailto is I can't dereference it. I can only send > information to it and the information goes into a black hole. That's > against the REST philosophy. If email were designed according to REST > then every email message would have a globally unique identifier and you > would reply to a message by POSTing to the identifier (which you can't > do with an SMTP unique identifer). Can't I use POP3 to fetch mail given only mailto:asynch_messaging@... ?
> > What if the caller, the > > caller's proxy, or the recipient is temporarily offline? > > Then let the recipient have a proxy that queues up these requests. Hmm, you mean that every callback URL would be a queuing front end somewhere. That queing front end could be a CGI script which writes to a disk file... Of course, it's convenient to have that CGI shared by multiple transient endpoints so that every watch app doesn't require yet another install and datastore.... The datastore in the shared CGI is partitioned by endpoint... The endpoint signs in and picks up its messages... Yup, POP3. Are there substantial benefits from reconstructing all of SMTP and POP with HTTP, or can they be considered orthogonal and complementary? > > Again, these semantics are covered by mail infrastructure already > but not by web > > infrastructure. > > You sure about that? Yes. They can be emulated with HTTP, but haven't yet been.
On Thu, 17 Jan 2002, Paul Prescod wrote: > The problem with mailto is I can't dereference it. I can only send > information to it and the information goes into a black hole. That's > against the REST philosophy. If email were designed according to REST > then every email message would have a globally unique identifier and you > would reply to a message by POSTing to the identifier (which you can't > do with an SMTP unique identifer). You could always create an HTTP service that provides some data about any mailto uri, but I'm not sure why you would want to. In any case, RFC822 says that every mail message should have a globally unique identifier (message-id) and that replies should have "in-reply-to: message-id" in their headers. What is missing here? > > I think REST provides a philosophy. MIME-RPC > > provides a wire format. > > Right, REST is a philosophy. The wire format is already HTTP + MIME + > XML. What does MIME-RPC add? As I said before, in MIME-RPC, any MIME transport is the transport (HTTP, HTTPS, SMTP, IMAP, etc). The wire format is a MIME envelope wrapped around whatever makes the most sense for your application (e.g. GIF, JPEG, or Flash rather than SVG). The last one is important. XML does not easily allow delivery of multiple XML documents or other opaque data types like graphics or MSOffice files. MIME is designed to do just that. It appears to work very well for both email and the web. My question is What is REST? What does it add? There seems to be no definition only ostensive descriptions. Note: sending an XML document over HTTP is compliant with MIME-RPC. I just think that you frequently want to do more. I am actually beginning to think that MIME-RPC and REST are orthogonal. You can use MIME-RPC in REST-style or not. It is just that because MIME-RPC allows people to do things in non-REST style, some RESTers might object. > > Please define your use of RPC. My use of RPC is > > simply that the recipient of the message is an > > application rather than a person. > http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq Ok. I read this and think we are in agreement. MIME-RPC does not require use of method names. It really just presumes that people are sending data structures to one another. In the spec, method names and arguments are nothing more than elements of a struct. If application developers want to interpret that struct as a command, they are free to do so. If they want to interpret it as a message advising them of something, that is ok too. I think that MIME-RPC supports both REST and non-REST styles. I like REST style, I just don't think I always want to use it and I think that frequently people want a more easy to use abstraction of their code. MIME-RPC supports them either way. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Let me see if I have internalized the REST philosophy.... Lucas Gonze wrote: > >... > > Are there substantial benefits from reconstructing all of SMTP and POP with > HTTP, or can they be considered orthogonal and complementary? There are benefits to reconstructing stuff. Reason #1. It is bad to have useless silos of functionality. Why should SMTP have some features and REST other features unless there is some reason that the two features do not coexist naturally. For instance, there is HTTPS but as far as I know, there is no POPS. So I had to set up SSL-based POP "manually". And I can't depend on it being available in an application. If POP was HTTP then "POPS" would be avaialable everywhere. Reason #2. The web is organized around URI addresses. HTTP is the only protocol that is similarly organized. You could make a URI-centric SMTP or POP but it would be just as hard as adding async infrastructure to HTTP software but you'd be left with problem #1. Reason #3. We're computer scientists. Overgeneralizing is what we do. Of course SMTP and POP are not going away. But if we're building new asych apps then yes, I'm going to follow the party line and say that asynch HTTP are the way to go. And the sooner we clarify that the better. Could someone inform me what happened here: http://groups.yahoo.com/group/notification/ and here: http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/ Paul Prescod
> My question is What is REST? What does it add? It adds the methods so you don't have to. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Paul,
Your structuring your MIME-RPC examples to be
harder to read and biasing the discussion.
The MIME-RPC state name request looks like this:
POST /states HTTP/1.1
10023
It is not obvious that this is substantially
simpler than the REST
GET /states/10023 HTTP/1.1
I am also thinking about ammending the MIME-RPC
spec to note that, by convention HTTP
applications allow urlencoded bodies to be passed
in a querystring when the method is GET, so
MIME-RPC implementations should as well.
Then a MIME-RPC request could look like this:
GET /states?10023 HTTP/1.1
Do you think these differences are substantive?
(The reason I prefer to use name/value in my
applications is that it allows web browsers to
interact with your application directly. You pay
with some ugliness to support web browsers. Such
is life.)
You also said:
> (the response is the same)
Note true. The simple MIME-RPC response:
HTTP/1.1 200 OK
New York
In contrast, the REST would be:
HTTP/1.1 200 OK
Content-type: text/xml; charset=utf-8
<state xmlns="http://foo.com/bar/namespace">New York</state>
The MIME-RPC response is much simpler. The client
is not required to parse XML and resolve a
namespace just to get at the answer.
The same arguments apply to your other examples
so I won't expand on them here. Nothing in
MIME-RPC stops you from delivering an a text/xml
as a response rather than a multipart/mixed. I
think it depends on the application which makes
the most sense.
> * rather than "wasting" the HTTP URL slot with /some/resource, the
> resource is the thing you are acting upon
This is a poor argument. see above.
> * when you're doing something idempotent, use GET, not POST
I now realize that REST seems to want a new
protocol that isn't either HTTP/1.0 or HTTP/1.1.
Claim: idempotent requests should use GET
Reality: Many idempotent requests, e.g. SQL
database queries, can't be sent with GET, because
they are too large or entail too much structure.
Claim: REST supports asynchronous messaging
Reality: REST appears to require use of HTTP and
HTTP does not support asynchronous requests.
Claim: Applications should define new HTTP methods
Reality: This is very difficult to deploy for many
users and there is no standards process for
defining these methods (limiting interop).
Of course real life HTTP deployments may change
and maybe the HTTP spec will evolve, but, right
now, the REST you describe appears to be
incompatible with deployed infrastructure.
> * use XML for structuring text rather than MIME.
> * more compact
> * easier to read
Very debatable. In the states example, the
MIME-RPC response was easier to read and shorter.
In the baseball example, the multipart/mixed
actually had fewer characters than the text/xml
exampe. Readability is in the eye of the
beholder.
> * can use schema for validation
When that is relevant to your application,
MIME-RPC does not prevent you from using XML.
However, in the states and baseball examples, I
don't think the validation is so useful.
(Note: I a putting aside for the moment, my
general doubts about schema validation technology)
MIME-RPC gives you the flexibility to do what you
need to do. When you need to talk to web
browsers, it supports you. When you want RPC, it
supports you. When you want to do asynchronous
messaging, it supports you. When you want to do
REST, it suppports you as well.
I guess I just think that there are times when
REST is incompatible with your needs, but MIME-RPC
helps you.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
> There are benefits to reconstructing stuff. [snipped reasons] Yes, excellent reasons. I'd add one more important one; Reason #4; optimizations are for the general case > better. Could someone inform me what happened here: > > http://groups.yahoo.com/group/notification/ > > and here: > > http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/ I was following it, and attended the first BOF in Chicago. There was a large turnout, but no followup, and nobody driving it hard. It might have had something to do with how vague the first BOF was with respect to the scope of the work. About a year after that, Adam & Rohit formed KnowNow and actually implemented it. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > Note true. The simple MIME-RPC response: > > HTTP/1.1 200 OK > > New York > > In contrast, the REST would be: > > HTTP/1.1 200 OK > Content-type: text/xml; charset=utf-8 > > <state xmlns="http://foo.com/bar/namespace">New York</state> Wrong. Show me where in any of the HTTP spec it says that response bodies are any particular content-type or content-encoding?! REST applications may use XML, but there's certainly no requirement there. Even the use of the content-type header is a SHOULD, not a MUST. (In cases where it's not provided, clients MAY use heuristics to attempt to guess, and if the content-type remains unknown it SHOULD be treated as type "application/octet-stream." Cf. rfc2616, Section 7.2.1.) Bottom line, the body belongs to the particular application, not HTTP itself. And this is as it should be. > The client > is not required to parse XML and resolve a > namespace just to get at the answer. That's true for REST as well. > The same arguments apply to your other examples > so I won't expand on them here. Nothing in > MIME-RPC stops you from delivering an a text/xml > as a response rather than a multipart/mixed. I > think it depends on the application which makes > the most sense. Likewise for REST. > I now realize that REST seems to want a new > protocol that isn't either HTTP/1.0 or HTTP/1.1. No, it just asserts that the semantics of HTTP are already rather well-defined, and just wishes that people would understand (a) that fact, and (b) the generality afforded by the already-specified semantics. > Claim: idempotent requests should use GET > > Reality: Many idempotent requests, e.g. SQL > database queries, can't be sent with GET, because > they are too large or entail too much structure. This is troublesome, and it's been argued (by me, among others, before I really "got" REST) that GET should be extended to include this functionality. But that's really not the right answer --- doing so would require changes to the HTTP infrastructure, requiring that HTTP itself take on the task of understanding at some semantic level the object representations that it transfers. A reasonable position for REST to take is this: idempotent requests which are "too large" to be effectively URL encoded in a reasonable way probably imply that the resources of the application aren't modeled and exposed correctly. I.e., the only reason you need that much data in an idempotent operation would be if you were tunneling some other "protocol" (using the term loosely) with some other view of the world (i.e., relational model, SQL being tunneled) through HTTP. The REST position is therefore that you need to remodel your application to fit the HTTP model and thereby get all the goodness of HTTP, rather than using it as a "dumb" conduit to tunnel other protocols and map to other object models. *Fully expose your application as resources that conform to the generic semantics of HTTP.* > Claim: REST supports asynchronous messaging > > Reality: REST appears to require use of HTTP and > HTTP does not support asynchronous requests. This is (a) incorrect, as we've already stated, and (b) rather ludicrous anyway. Asynchrony as an application communication pattern doesn't require an asynchronous communication protocol --- if it did, it wouldn't be possible to build asynchronous applications with i.e. ONC RPC, CORBA, etc. But we do just that. Syncronous request-response protocols are sufficient for building asynchronous messaging on top of, and vice-versa --- both models are fully general. In HTTP, you would simply do asynchronous communication as callbacks: a request supplies, potentially in an URL-encoded fashion, the URI to which responses should be sent at a later date. Responses are then passed back via later HTTP methods invoked on the callback resource. We *do* need some conventional ways for doing this, but it should be noted that there are *many* kinds of asynchrony that are interesting to different applications. For some apps, simple one-shot callbacks are sufficient. For others such as pub-sub, "persistent" callbacks are needed. All of these and more styles of communication are trivially built atop the existing HTTP infrastructure with *no changes at all.* A little bit of care must however be exercised in order to ensure that you don't break the overall semanics of HTTP, i.e. caching, etc. And even though all of this is trivially possible *today,* some cases may be common enough that extensions to the set of HTTP methods might be reasonable optimizations. > Claim: Applications should define new HTTP methods > > Reality: This is very difficult to deploy for many > users and there is no standards process for > defining these methods (limiting interop). Reality: REST doesn't claim that applications should add to the HTTP method set. (BTW, that was my loudest and most passionate objection to REST before I "got it.") The REST claim is that almost anything you can think of doing can be trivially recast within the context of HTTP's general, powerful methods. (Atomic read+delete is an example of one possible missing method, but there aren't many of them.) Think about it this way: the limited HTTP method set is analogous to the limited file IO interface in UNIX. And just as those interfaces have proven *incredibly* flexible and powerful --- almost anything can be recast as file IO and stream operations, cf. Plan 9 --- so is the limited HTTP method set more flexible and powerful than it may appear at first glance. > > Very debatable. In the states example, the > MIME-RPC response was easier to read and shorter. > In the baseball example, the multipart/mixed > actually had fewer characters than the text/xml > exampe. Readability is in the eye of the > beholder. Again, REST is in no way married to XML. Neither is it antagonistic to XML. > I guess I just think that there are times when > REST is incompatible with your needs, Such as...? jb
Counter-reasons follow, but almost purely for the sake of debate: #1: It is bad to reinvent the wheel. #2: Reinventing the wheel is likely to fail, as there is little market niche available. #3: Why bother figuring out how to merge wheels and boxes when you can put them together and have a car? Is it possible to bolt HTTP and SMTP together in a way that minimizes integration work? #4: If optimizations are for the general case, email wins. It's much more general. #5: If a URI-centric SMTP makes no sense, that is evidence that SMTP and HTTP are orthogonal. Why "almost purely for the sake of debate"? Because it's too soon to be commenting on solutions. There is not yet: * a convincing case that asynch is needed * usecases * a requirements list * serious implementation proposals
http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/ Adam & Rohit started KnowNow - http://www.knownow.com Asynch messaging over HTTP. There is a Python library so you might be interested...
> > Then let the recipient have a proxy that queues up these requests. > > Hmm, you mean that every callback URL would be a queuing front end somewhere. I was thinking of queueing up outgoing subscriptions, but this could also be used. > That queing front end could be a CGI script which writes to a disk file... Of > course, it's convenient to have that CGI shared by multiple transient endpoints > so that every watch app doesn't require yet another install and datastore.... > The datastore in the shared CGI is partitioned by endpoint... The endpoint > signs in and picks up its messages... Yup, POP3. Sure, but showing that HTTP semantics trump those of POP3. > Are there substantial benefits from reconstructing all of SMTP and POP with > HTTP, or can they be considered orthogonal and complementary? See Paul's response. > > > Again, these semantics are covered by mail infrastructure already > > but not by web > > > infrastructure. > > > > You sure about that? > > Yes. They can be emulated with HTTP, but haven't yet been. I don't recall which ones we were talking about, but HTTP has a lot of goodies that you might have missed if you weren't looking for them. -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > > Paul, > > Your structuring your MIME-RPC examples to be > harder to read and biasing the discussion. I believe that I cut and pasted all of those MIME-RPC examples from your examples pages! > The MIME-RPC state name request looks like this: > > POST /states HTTP/1.1 > > 10023 Not according to this URL: http://www.mime-rpc.com/examples.html > It is not obvious that this is substantially > simpler than the REST > > GET /states/10023 HTTP/1.1 It may not be much more complicated. But it is less correct. If you are GET-ting information you should use GET. That's useful for caching and firewalls. > I am also thinking about ammending the MIME-RPC > spec to note that, by convention HTTP > applications allow urlencoded bodies to be passed > in a querystring when the method is GET, so > MIME-RPC implementations should as well. > > Then a MIME-RPC request could look like this: > > GET /states?10023 HTTP/1.1 > > Do you think these differences are substantive? No. Now you're catching on to REST. But if that request doesn't use the MIME-RPC header and doesn't use any MIME-RPC conventions then how is it MIME-RPC? It looks like HTTP to me! > (The reason I prefer to use name/value in my > applications is that it allows web browsers to > interact with your application directly. You pay > with some ugliness to support web browsers. Such > is life.) Understood. I've been arguing that XForms should allow the construction of any form of URL, even /states/10023. > You also said: > > (the response is the same) > > Note true. The simple MIME-RPC response: > > HTTP/1.1 200 OK > > New York > > In contrast, the REST would be: > > HTTP/1.1 200 OK > Content-type: text/xml; charset=utf-8 > > <state xmlns="http://foo.com/bar/namespace">New York</state> No. REST does not require XML. REST was invented before XML. I personally encourage the use of XML for *structured* data. >... > > * rather than "wasting" the HTTP URL slot with /some/resource, the > > resource is the thing you are acting upon > > This is a poor argument. see above. You don't seem to understand that this is the *core idea of REST*. It is also the core idea of the Web. You say that you are just formalizing existing web conventions but your examples don't use GET to mean GET. >... > Claim: idempotent requests should use GET > > Reality: Many idempotent requests, e.g. SQL > database queries, can't be sent with GET, because > they are too large or entail too much structure. Show me a SQL database query that is incompatible with Python's urllib.urlencode. Jeff Bone's answer is more nuanced. Why are you trying to do SQL over the Web. The Web has a different data model than a relational database. Use the web's data model. > Claim: REST supports asynchronous messaging > > Reality: REST appears to require use of HTTP and > HTTP does not support asynchronous requests. I'll leave that to Jeff Bone. > Claim: Applications should define new HTTP methods > > Reality: This is very difficult to deploy for many > users and there is no standards process for > defining these methods (limiting interop). This issue is more subtle. You can use REST with only the methods GET and POST. That's what most web sites do already. You can also define new methods if you really feel it important to do so (rare, but not unheard of). You can also do hacky workarounds. If MIME-RPC documented its syntax as a workaround for applications that don't properly support HTTP method extension then I would be more happy with it. One could build a generic translator that hid the hackiness from the underlying application. >... > Very debatable. In the states example, the > MIME-RPC response was easier to read and shorter. Not true, as I discussed above. > In the baseball example, the multipart/mixed > actually had fewer characters than the text/xml > exampe. Readability is in the eye of the > beholder. If you say so...the XML sure looked easier to read to me. Paul Prescod
Asynch Messaging wrote: > > ... > > Can't I use POP3 to fetch mail given only > mailto:asynch_messaging@... ? What in the URL tells you that POP3 is available? Also, is fetching mail the same as addressing a resource? It sounds like "RPC thinking". You have a single end-point and you send it messages. Web-thinking is that every resource (i.e. email message!) represents an endpoint and you send *them* HTTP messages. That's why I still don't think that "mailto:" is particularly REST-y. Arguably a better name is "mailbox:" and then you're addressing the mailbox but it is an incredibly course-grained object. You would hardly ever do a GET, DELETE or PUT. That means it is like a SOAP endpoint that you can only do POST on. So once again it is very RPC-like. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > In any case, RFC822 says that every mail message > should have a globally unique identifier > (message-id) and that replies should have > "in-reply-to: message-id" in their headers. How do I dereference those identifiers? If I can't put an identifier in a browser URL bar and expect to get some set of bytes back then I don't personally think it is really REST-y. But then REST is just a philosophy so there will be differences of opinion on that. I would say that message-id's should be HTTP URLs that dereference to the message contents and that ACLs should be used to say who can and cannot see it. Archives of messages (e.g. egroups) could add a header orig-message-url: http:// .... I'm just making this up as I go along. I'm not claiming to be a REST guru. >... > As I said before, in MIME-RPC, any MIME transport > is the transport (HTTP, HTTPS, SMTP, IMAP, etc). > The wire format is a MIME envelope wrapped > around whatever makes the most sense for your > application (e.g. GIF, JPEG, or Flash rather than > SVG). > > The last one is important. XML does not easily > allow delivery of multiple XML documents or other > opaque data types like graphics or MSOffice files. > MIME is designed to do just that. It is easy to set up an HREF from an XML document to a MIME. I don't know whether SOAP does it intelligently or not. In Python it would take me a couple of lines to get from an HREF to a MIME part so I don't know what MIME-RPC adds. >... > My question is What is REST? What does it add? > There seems to be no definition only ostensive > descriptions. REST is the architecture of the web. What does it add? The Web. If you use the Web in the way it was designed then you get applications that are easier to maintain, scales better and generally works better. In your MIME-RPC examples you use POST to do a getStateName. I know you're just copying the XML-RPC examples but the point is that if you rethought it in terms of the web's native architecture (and use GET) you'd get better caching, smaller messages, simpler messages and you'd find that all of the specs you need are *already in place* so there is no need for another spec. GET /states/41/name HTTP/1.1 It just works. There is no need for another spec. > I am actually beginning to think that MIME-RPC and > REST are orthogonal. You can use MIME-RPC in > REST-style or not. Yes, but when you use it in the REST-style I think it is just called "MIME". The RPC part falls away. The type marshaling is not necessary if you use externally defined custom XML vocabularies. The function naming part is not necessary because REST doesn't have function calls. There's nothing wrong with RPC if it meets your needs. And MIME-RPC seems a good way to do RPC if you are trying to avoid defining an XML vocabulary. But I haven't yet seen how a REST web application would take advantage of any of the MIME-RPC conventions. Paul Prescod
> Asynch Messaging wrote: > > > > ... > > > > Can't I use POP3 to fetch mail given only > > mailto:asynch_messaging@... ? > > What in the URL tells you that POP3 is available? Also, is fetching mail > the same as addressing a resource? It sounds like "RPC thinking". Ouch. > You > have a single end-point and you send it messages. Web-thinking is that > every resource (i.e. email message!) represents an endpoint and you send > *them* HTTP messages. That's why I still don't think that "mailto:" is > particularly REST-y. Arguably a better name is "mailbox:" and then > you're addressing the mailbox but it is an incredibly course-grained > object. That's what I was getting at. Since e-mail doesn't have a single protocol for all operations (SMTP to post, IMAP or POP to get), I thought maybe a user-agent could infer 'mailto' meant 'try imap or pop if doing a get'. The mailto uri spec might not provide identifiers for tasty sub-resources - like folders and messages within those folders - but we could pretend it did. Following the 'mailbox:' example, I'd love to see GET mailbox://hotmail.com/asynch_messaging/INBOX/ GET mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... DELETE mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... POST GET mailbox://hotmail.com/asynch_messaging/INBOX/ (this is where a MOVE might be handy) Hmm... I'm not asking for a new wire protocol, but a client library that had similar abilities as an HTTP client library, but used smtp/pop to do the resource manipulation. You know, maybe i'll write a servlet that proxies http requests over a set of resources that mailbox servers this way... > You would hardly ever do a GET, DELETE or PUT. Why not? > That means it is > like a SOAP endpoint that you can only do POST on. So once again it is > very RPC-like. > > Paul Prescod >
> > Following the 'mailbox:' example, I'd love to see > GET mailbox://hotmail.com/asynch_messaging/INBOX/ > GET > mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... > DELETE > mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... > POST GET mailbox://hotmail.com/asynch_messaging/INBOX/ > (this is where a MOVE might be handy) Typo - > Before > POST mailbox://hotmail.com/asynch_messaging/INBOX/ > After > POST mailbox://hotmail.com/asynch_messaging/INBOX/ It'd be interesting to also use HTTP to GET and POST content of Content-Type: message/http-request You could do asynchronous, client-initiated HTTP.
> > You > > have a single end-point and you send it messages. Web-thinking is that > > every resource (i.e. email message!) represents an endpoint and you send > > *them* HTTP messages. That's why I still don't think that "mailto:" is > > particularly REST-y. Arguably a better name is "mailbox:" and then > > you're addressing the mailbox but it is an incredibly course-grained > > object. > That's what I was getting at. Since e-mail doesn't have a single protocol > for all operations (SMTP to post, IMAP or POP to get), I thought maybe a > user-agent could infer 'mailto' meant 'try imap or pop if doing a get'. > The mailto uri spec might not provide identifiers for tasty sub-resources - > like folders and messages within those folders - but we could pretend it > did. > > Following the 'mailbox:' example, I'd love to see > GET mailbox://hotmail.com/asynch_messaging/INBOX/ > GET > mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... > DELETE > mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@... > POST GET mailbox://hotmail.com/asynch_messaging/INBOX/ > (this is where a MOVE might be handy) > > Hmm... I'm not asking for a new wire protocol, but a client library that had > similar abilities as an HTTP client library, but used smtp/pop to do the > resource manipulation. > > You know, maybe i'll write a servlet that proxies http requests over a set > of resources that mailbox servers this way... You're exactly right here. The mailto: URI *does* uniquely identify a mailbox, but that's not sufficient for resolution. "http://www.markbaker.ca/" is a URI that uniquely identifies me, but had the HTTP URI scheme not described how to use that string so that resolution could be automated, it wouldn't make it any less valuable as an identifer of me. The mailto URI scheme could have said something like a POP3 server should be running on the host corresponding to the domain portion of an email address (in practice, it would have to be lot more convoluted than that due to MX/A record differences, and other issues). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Ok, I have my smtp transport for asynch messaging running, next thing to do is the http layer. The purpose of this is to be a testbed for ideas about how asynch http would work. Also, this message is quite disorderly, since I'm focused on running code today rather than clear exposition. There is nothing special about SMTP -- UDP should be supported by the design just as well -- it just happens to be a convenient transport. I am thinking in Java today, so that's what the examples are. How to set up the layering between transport and HTTP? My instinct is to create a sort of simulated request/response, but with the asynch guts still exposed for those who want to see them. It is assumed that any asynch scheme must be backwards compatible with synch mode; I do this by considering synch to be a special case where there is always exactly one response. A client program in need of HTTP obtains a connection object that wrappers the asynch details. The client program retrieves and manipulates the connection object as always, except that it must actively indicate that an asynch connection is OK. The connection object is a derived subclass of HttpURLConnection. It is willing to do anything synchronous HTTP does, but it never lies about the asynch nature of things. An example of not lying is that working via a hacked proxy as Freenet does is not acceptable unless the client indicates that this is OK. When A calls conn.getContent() a message is emitted and a callback is stored. A _new_ response code is emitted to indicate _asynch_ communications: eg 900 "Emission pended" or 901 "Emission sent and accepted". The outer caller, the one that wants synchronicity does _not_ get a lie; no "200 OK" that doesn't come from the real destination. However, there may be proxy status codes that are suitable, in particular 407 and 408, I don't know. The outer caller may be dropped into a pending state (e.g. via wait()) in anticipation of a true HTTP response. When a response message is received it is mapped via a thread-id or request-id to a callback. A big question is what URI scheme to use? This is _not_ HTTP, because there is no domain name and because -- and worse! -- the dest address should be expressable as a URI. EG: "http:/(URI)/etc" is not legal. How to pack a URI in there? The protocol identifier HTTP is inappropriate, because it doesn't flag that the target host is a URI. An HTTP URL would be unparseable if the target host were a URI. EG, asynch-http://http://bloe.com/targetContent/ Is "/targetContent" ^ part of the http URI or part of the asynch-http URI? Practical comments would be appreciated, as I hope to have running code shortly.
Thinking about this further, there should be less of the async interface done at the binary/api level and more at the HTTP layer. I should implement something like the WATCH design that Mark suggested. ...then the only immediate questions are * how to model a compound URL that allows a full URI as the target destination? * what is the status code for an emission that has been scheduled but not necessarily performed? * need some analog for SMTP status codes, and probably those codes themselves if the transport happens to be SMTP.
Lucas Gonze wrote: > >... I've read your emails a couple of times and I don't understand the questions: > * how to model a compound URL that allows a full URI as the target destination? What are you trying to express with this URL? What resource is it the URL of? These are not koans. I don't understand what you're trying to do. > * what is the status code for an emission that has been scheduled but not > necessarily performed? This bit I understand. What's wrong with "Emission pended". > * need some analog for SMTP status codes, and probably those codes themselves if > the transport happens to be SMTP. Why do you need a transport? Obviously I don't understand enough of what you mean by asynch. I'll send another message about that. Sorry to drag you back from coding to explaining the problem you're trying to solve. ;) Paul Prescod
> > * how to model a compound URL that allows a full URI as the target > destination? > What are you trying to express with this URL? The target resource is available by some version of HTTP, but does not have domain name or IP address. IE, in a URL like: http://server_address/resource The server address may itself be a URI. In the strawman model, it's something like smtp:joe@.... What I am trying to accomplish is to allow servers to be addressed via any means that permits bytes to flow, under the assumption that HTTP can be more-or-less reconstructed as long as bytes can pass. Hm, I wonder if such a compound URL can be expressed using a sequence of calls: 1) POST http://localhost/stream (POST args are URI=smtp:joe@...) (drops the URI into saved state on localhost and returns a stream ID) 2) GET http://localhost/stream?ID=234234&resource=/index.html > > * what is the status code for an emission that has been scheduled but not > > necessarily performed? > > This bit I understand. What's wrong with "Emission pended". Yes, but there's no such thing in HTTP. > > * need some analog for SMTP status codes, and probably those codes > themselves if > > the transport happens to be SMTP. > > Why do you need a transport? > Obviously I don't understand enough of what > you mean by asynch. My working approach for the weekend is just to try to run HTTP over well known asynch infrastructure and see what, if any, problems are not solvable with existing HTTP infrastructure. I could have chosen UDP just as easily as SMTP. ...this project is a reality check on the fairly abstract conversations we've been having.
Lucas Gonze wrote: > > Thinking about this further, there should be less of the async interface done at > the binary/api level and more at the HTTP layer. I should implement something > like the WATCH design that Mark suggested. ...then the only immediate questions > are I think that what you call asynch HTTP is better called HTTP notifications. If one thinks about the minimal amount need to add "asynch" to HTTP it is a way for a client to tell the server where to send the response when it becomes available. You need a reply-to: header with an IP address and a port. The server returns "900: Sure, I'll get back to you when I can". When the server completes a (potentially long) computation, it makes a TCP connection to the port and returns a result. This would be good where the basic pattern is request-response but the computation may take very long (especially in a workflow-type situation) and the client doesn't want to keep a socket open for days or weeks on end. On the other hand, notifications is about reporting when a resource changes. The primary virtue of notifications is that they break the request-response pattern of HTTP. So it is *more than asynch behaviour* that is interesting in notifications. It is multi-response. In my "pure" asynch HTTP you could only emulate multi-response by making multiple requests. I think you are interested in notifications, not just asych HTTP. Paul Prescod
> I think that what you call asynch HTTP is better called HTTP notifications. Yes. > If one thinks about the minimal amount need to add > "asynch" to HTTP it is a way for a client to tell the server where to > send the response when it becomes available. You need a reply-to: header > with an IP address and a port. The server returns "900: Sure, I'll get > back to you when I can". No. Use Status 202 "Accepted". You are right that the initial request should use a Reply-To: header. The final 'response' that closes the request/response message exchange comes as a new request into the Reply-To address. That is probably a PUT to the uri in Reply-To as determined by the initiator of the exchange. That uri would identify a place to update the status of the initial outgoing message. The content would be type message/http-response - not sure if something like this is registered. > This would be good where the basic pattern is request-response but the > computation may take very long (especially in a workflow-type situation) Oooh. Workflow. Another holy grail. > and the client doesn't want to keep a socket open for days or weeks on > end. > > On the other hand, notifications is about reporting when a resource > changes. The primary virtue of notifications is that they break the > request-response pattern of HTTP. Not necessarily. A notification about a 'pending request' is about a resource if you model it as such. > So it is *more than asynch behaviour* > that is interesting in notifications. It is multi-response. In my "pure" > asynch HTTP you could only emulate multi-response by making multiple > requests. > > I think you are interested in notifications, not just asych HTTP. > All current HTTP needs for asynchronous request/response is : use request header of Reply-To, response status of 204 Accepted future request to Reply-To uri with content-type: message/http-response. It would be useful to define an HTTP message that indicates a notification about the status of a 'pending request' (my term - everybodies got one...). This 'request' would need to indicate what pending message (identified as a resource) it is 'about'. This could be used to let the requestor know that errors have occurred, but the processing hasn't given up. That's the difference between a notification and a response. This notification might have to indicate that it is only 'advisory' and not a 'close the transaction' type of response to an initial request. The HTTP method might be the best place - otherwise a custom content type. == Here's a try at what the message exchange would look like with this approach: == Submitting a purchase order == POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1 Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/ Content-Type: application/xml Content-Model: PurchaseOrder Authenticiation: Basic YNGQ7G= <po> <item>ChromedWidget</item> <quantity>27</quantity> <unit-of-measure>pounds</unit-of-measure> </po> == Acknowledgement of submission == HTTP/1.1 202 Accepted Location: http://www.widgets.com/customer59/po/abcdef/ == Message that updates status of purchase order === NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1 Content-Type: message/http-event Authenticiation: Basic Y7GHHA== HTTP/1.1 500 Internal Server Error Content-Type: text/plain We are experiencing technical difficulties. Please stand by. == Message that confirms purchase order === PUT http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1 Content-Type: message/http-response Authenticiation: Basic Y7GHHA== HTTP/1.1 200 Success Content-Type: application/xml Content-Model: PurchaseOrderAck <po-ack> <invoice>http://www.widgets.com/customer59/invoice/xyz123/</invoice> <comment>Thank you for doing business with WidgetsRUs!!!</comment> </po-ack>
Asynch Messaging wrote: > == Message that updates status of purchase order === > NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1 > Content-Type: message/http-event > Authenticiation: Basic Y7GHHA== > > HTTP/1.1 500 Internal Server Error > Content-Type: text/plain > > We are experiencing technical difficulties. Please stand by. I agree wholeheartedly that this general scheme is the right way to do async. I'm still lost as to why Lucas wants to drag SMTP into the mix. I have one question / suggested modification to the above: why do we even need a NOTIFY here, when the semantics of POST suffice? jb
> I agree wholeheartedly that this general scheme is the right way to do async. > I'm still lost as to why Lucas wants to drag SMTP into the mix. I have one > question / suggested modification to the above: why do we even need a NOTIFY > here, when the semantics of POST suffice? Right. Given that the caller provides the URI on the Reply-To, that can be made to mean that the caller expect the notification on a POST. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Asynch Messaging wrote: > >... > No. Use Status 202 "Accepted". You are probably right. > You are right that the initial request should use a Reply-To: header. > The final 'response' that closes the request/response message exchange comes > as a new request into the Reply-To address. One design is that the thing is totally bidirectional. The "client" becomes the "server" in an HTTP sense. Definitions: HTTP client: software that generates HTTP requests and consumes to HTTP responses. HTTP server: software that expects HTTP requests, interprets them as actions to be taken on resources and generates HTTP responses. Another design is to keep the protocol directed. The server contacts the client with a message that does NOT look like an HTTP request but rather like an HTTP response. The virtue of the former design is that it is easier to layer on the existing HTTP protocol because every message going across the wire is HTTP-as-we-know-it. The virtue of the latter design is that it is simpler. You don't have a request that is really a response. You have just a response. The only thing novel about it is that it is a new socket created by the server. > That is probably a PUT to the uri in Reply-To as determined by the initiator > of the exchange. If I were a firewall administrator, I'd rather deal with a system that allows an delayed response on a new socket than one that allows PUTs to desktop machines in the organization. There are costs in turning the client into a "full server". We should consider those carefully. It is more difficult to detect a response that is embedded in a request than to understand a simple request. > ... That uri would identify a place to update the status of the > initial outgoing message. The > content would be type message/http-response - not sure if something like > this is registered. So we're talking about an HTTP message embedded in an HTTP message, right? > > This would be good where the basic pattern is request-response but the > > computation may take very long (especially in a workflow-type situation) > Oooh. Workflow. Another holy grail. All I mean is that humans may be involved in processing an HTTP request. i.e. if Babelfish used real human translators. You submit your data today and get back a decent translation tomorrow. > > and the client doesn't want to keep a socket open for days or weeks on > > end. > > > > On the other hand, notifications is about reporting when a resource > > changes. The primary virtue of notifications is that they break the > > request-response pattern of HTTP. > Not necessarily. > A notification about a 'pending request' is about a resource if you model it > as such. If you make the HTTP client into an HTTP server then yes, it is easy to make multiple "responses". Paul Prescod
> Another design is to keep the protocol directed. The server contacts the > client with a message that does NOT look like an HTTP request but rather > like an HTTP response. > > The virtue of the former design is that it is easier to layer on the > existing HTTP protocol because every message going across the wire is > HTTP-as-we-know-it. > > The virtue of the latter design is that it is simpler. You don't have a > request that is really a response. You have just a response. The only > thing novel about it is that it is a new socket created by the server. I started coding up the latter this weekend and found that the former was both simpler and more powerful. Also, the former is time tested -- all those third party shopping carts use it to return from the transaction processor's site to the vendor's site. > > That is probably a PUT to the uri in Reply-To as determined by the initiator > > of the exchange. ... > There are costs in turning the client into a "full server". We should > consider those carefully. It is more difficult to detect a response that > is embedded in a request than to understand a simple request. The design issue is whether or not to make it possible to expose client state. If the callback is a response then requestor state is a black box. If the callback is a POST request, then the state of the original requester/client becomes exposed. My preference is that callbacks should be any legal request, because this allows easier switching between client/server roles. Using DAV as an example, it would be much easier to create a decentralized CVS cluster if PUT requests could be flooded through the cluster unaltered. > > ... That uri would identify a place to update the status of the > > initial outgoing message. The > > content would be type message/http-response - not sure if something like > > this is registered. > > So we're talking about an HTTP message embedded in an HTTP message, > right? I am not convinced that a new Reply-to header is any better an idea than a new WATCH method. The entire problem of pragating new standards goes away if all these features are modeled as a web app, and so far I haven't seen any features that can't be modeled that way. In that context an HTTP message embedded in an HTTP message is just another POST argument. Actually, I'd say that the REST design style strongly implies that doing it as a web app is the right approach. Given the choice between a new WATCH verb and Reply-to header versus a /watches URI and Reply-to argument, REST implies the second.
> > Asynch Messaging wrote: > > > == Message that updates status of purchase order === > > NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1 > > Content-Type: message/http-event > > Authenticiation: Basic Y7GHHA== > > > > HTTP/1.1 500 Internal Server Error > > Content-Type: text/plain > > > > We are experiencing technical difficulties. Please stand by. > > I agree wholeheartedly that this general scheme is the right way to do async. > I'm still lost as to why Lucas wants to drag SMTP into the mix. I have one > question / suggested modification to the above: why do we even need a NOTIFY > here, when the semantics of POST suffice? > > jb If POST is used, then there might be an unknown number of POSTs - you may get several 'errors' and one 'success'. It would be nice to be able to identify which are ignorable/advisory. I was looking for a way to indicate the status and indicate that processing will continue. The 202 Accepted status doesn't leave much room for indicating whether the processing is in a transient error situation (database is down for nightly backup, etc). I almost want to say NOTIFY is idempotent and POST isn't - but I don't know what that all means anyway. The message-in-a-message can be avoided if the response status can be tunneled in a request header like Status:
An additional thing to think about - regarding message-in-a-message. If a response can come in a request, then a request can come in a response. Which can be very useful for servers behind a firewall. The client (the 'protected' server) initiates a GET on a collection of pending messages, which may stream down multiple messages in response. If these messages have content-type: message/http-request then the it can be parsed as such and handed to some sort of HTTP dispatching software - like Apache. The response from something like Apache would go up as a new HTTP request with content-type: message/http-response. The collection of pending messages can be a third party provider of 'mailbox' functionality. With tricky software you could be backwards compatible by having the intermediary hold open the connections for older clients until a message/http-response arrives (or times out), do the correlation and literally pipe the response back to the older client.
Asynch Messaging wrote: > If POST is used, then there might be an unknown number of POSTs - you may > get several 'errors' and one 'success'. > It would be nice to be able to identify which are ignorable/advisory. I was > looking for a way to indicate the status and indicate that processing will > continue. The 202 Accepted status doesn't leave much room for indicating > whether the processing is in a transient error situation (database is down > for nightly backup, etc). > > I almost want to say NOTIFY is idempotent and POST isn't - but I don't know > what that all means anyway. > The message-in-a-message can be avoided if the response status can be > tunneled in a request header like Status: What you're describing is almost exactly the proper interpretation of the semantic differences between POST and PUT. Think of it this way: the callback resource models the current state of the request as it evolves over time. POSTing to that resource in effect modifies the state of that resource as the transaction (using term loosely, don't get hung up here) progresses, while the final PUT effectively sets the final state of that resource. The application could then, presumably, delete the resource in question. A rather sloppy but perhaps illustrative way to think of it: POST is like echo "something" >> foo PUT is like echo "something final" > foo $0.02, jb
> > An additional thing to think about - regarding message-in-a-message. > If a response can come in a request, then a request can come in a response. > Which can be very useful for servers behind a firewall. I don't like that approach at all. Encapsulation is always a dicey proposition, because it can all too easily become tunneling. A lot of work would have to be done to ensure it didn't, and I don't see the value add in doing that. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > >... > > I agree wholeheartedly that this general scheme is the right way to do async. > I'm still lost as to why Lucas wants to drag SMTP into the mix. Let me try to channel Lucas. SMTP software handles queuing, retries, status notifications, ... Paul Prescod
Paul Prescod wrote: > Jeff Bone wrote: > > > >... > > > > I agree wholeheartedly that this general scheme is the right way to do async. > > I'm still lost as to why Lucas wants to drag SMTP into the mix. > > Let me try to channel Lucas. > > SMTP software handles queuing, retries, status notifications, ... Understood, but... it's not clear that reusing SMTP is the right way to add this kind of thing to HTTP. Either HTTP's synchronous calls are fundamental and asynchronous communication is built atop this with full visibility to the underlying synchronous mechansim, or the asynchronous mechanism is fundamental and we map HTTP onto it while preserving visibility for the asynchronous mechanism. IMO they can't effectively be on par, one has to be more essential; and the task of layering asynchrony on top of HTTP seems easier and more productive to me than trying to force-fit synchronous HTTP semantics on top of SMTP. Lucas seems to have arrived at mostly the same conclusion...? jb
> A rather sloppy but perhaps illustrative way to think of it: > POST is like echo "something" >> foo > PUT is like echo "something final" > foo I do want to indicate the difference between 'something' and 'something final'. Perhap both should use PUT with some sort of visible 'status' somewhere - in header or body. The problem I see is preventing intermediate notifications arriving out of sequence to not change the status. One thought would be to make both the 'intermediate status' and the 'response' both URI addressable. The initial request would specify two locations rather than one and the responder would use PUT for both. The idempotency of PUT allows for repeated messages in case something got dropped - increasing reliability. == == Submitting a purchase order == POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1 Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/ Status-To: http://www.smallbiz.com/accounting/po/12345/status/ Content-Type: application/xml Content-Model: PurchaseOrder Authenticiation: Basic YNGQ7G= <po> <item>ChromedWidget</item> <quantity>27</quantity> <unit-of-measure>pounds</unit-of-measure> </po> == Acknowledgement of submission == HTTP/1.1 202 Accepted Location: http://www.widgets.com/customer59/po/abcdef/ == Message that updates status of purchase order === PUT http://www.smallbiz.com/accounting/po/12345/status/ HTTP/1.1 Content-Type: message/http-event Authenticiation: Basic Y7GHHA== HTTP/1.1 500 Internal Server Error Content-Type: text/plain We are experiencing technical difficulties. Please stand by. == Message that confirms purchase order === PUT http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1 Content-Type: message/http-response Authenticiation: Basic Y7GHHA== HTTP/1.1 200 Success Content-Type: application/xml Content-Model: PurchaseOrderAck <po-ack> <invoice>http://www.widgets.com/customer59/invoice/xyz123/</invoice> <comment>Thank you for doing business with WidgetsRUs!!!</comment> </po-ack>
----- Original Message ----- From: "Mark Baker" <distobj@...> > > > > An additional thing to think about - regarding message-in-a-message. > > If a response can come in a request, then a request can come in a response. > > Which can be very useful for servers behind a firewall. > > I don't like that approach at all. Encapsulation is always a dicey > proposition, because it can all too easily become tunneling. A lot of > work would have to be done to ensure it didn't, and I don't see the > value add in doing that. > Party pooper. It was meant as a 'tunnel' approach - but I don't what can of worms that opens up. I was trying to find some way for client initiated exchanges to have requests flow from server to client. This helps enable peer to peer between two firewalled nodes - with the assistance of a middleman. For software behind a firewall, how would you suggest we maintain RESTfullness if we attempt client initiated messaging? Especially if you want to maintain existing programming models.
> == Submitting a purchase order == > POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1 > Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/ > Status-To: http://www.smallbiz.com/accounting/po/12345/status/ Make that Notify-To: - it sounds better and doesn't assume the meaning of values PUT to it.
> > I don't like that approach at all. Encapsulation is always a dicey > > proposition, because it can all too easily become tunneling. A lot of > > work would have to be done to ensure it didn't, and I don't see the > > value add in doing that. > > > > Party pooper. > It was meant as a 'tunnel' approach - but I don't what can of worms that > opens up. See http://www.i-cap.org 8-) Basically, it breaks HTTP's end-to-end model. To not break it would require treating the encapsulated message as transparent rather than opaque, and doing stuff like stripping the Connection header on the first hop (etc.., etc.., etc..) > I was trying to find some way for client initiated exchanges to have > requests flow from server to client. This helps enable peer to peer between > two firewalled nodes - with the assistance of a middleman. Well, with WATCH, you're doing that, but I guess you mean that you want them coming back on the same connection. > For software behind a firewall, how would you suggest we maintain > RESTfullness if we attempt client initiated messaging? > Especially if you want to maintain existing programming models. Use GET and a persistent connection rather than WATCH. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Asynch Messaging wrote: > > A rather sloppy but perhaps illustrative way to think of it: > > > POST is like echo "something" >> foo > > PUT is like echo "something final" > foo > > I do want to indicate the difference between 'something' and 'something > final'. Argh, no. The difference isn't in "something" or "something final" --- it's in >> vs. >, aka POST vs. PUT. Let me restate the sloppy example in a clearer fashion: POST is like echo "something" >> foo PUT is like echo "something" > foo Repeated POSTS of the same content are not necessarily idempotent; repeated PUTs are. The semantic differences are in the methods, with no additional need for status codes embedded in the message, different resources, etc. The semantics of POST are that the state of the resource (i.e., progress of the transaction) is updated, while PUT implies that the state of the resource is replaced. It's appropriate to view *replacement* of the resource state as the finalization of the transaction. > One thought would be to make both the 'intermediate status' and the > 'response' both URI addressable. Why not simply have content POSTED to the "progress-of-the-transaction" resource indicate intermediate changes of state, while the first content successfully PUT to the resource indicates the completion of the interaction? I may be missing something really obvious, but I still don't think you need anything new, here. I think POST and PUT to the same resource are sufficient. jb
Asynch Messaging wrote: > For software behind a firewall, how would you suggest we maintain > RESTfullness if we attempt client initiated messaging? Note that asymmetry of connectivity is an orthogonal issue to any of various kinds of synchrony --- though they share partial solutions. > Especially if you want to maintain existing programming models. The one REST is most interested in maintaining is called "the Web." ;-) jb
> > Let me try to channel Lucas. > > > > SMTP software handles queuing, retries, status notifications, ... Paul is 100% more articulate about this than I am, but otherwise that's a good channeling. jb said: > Understood, but... it's not clear that reusing SMTP is the right way > to add this > kind of thing to HTTP. Either HTTP's synchronous calls are fundamental and > asynchronous communication is built atop this with full visibility to the > underlying synchronous mechansim, or the asynchronous mechanism is > fundamental and > we map HTTP onto it while preserving visibility for the asynchronous > mechanism. > IMO they can't effectively be on par, one has to be more essential; > and the task > of layering asynchrony on top of HTTP seems easier and more > productive to me than > trying to force-fit synchronous HTTP semantics on top of SMTP. Lucas > seems to have > arrived at mostly the same conclusion...? My feeling is that HTTP's synchronous calls are fundamental and asynch should be built atop this with full visibility. I wouldn't attempt to merge HTTP semantics into SMTP -- already tried it, didn't work. What I don't know is how good an idea it is to build general purpose "asynch/notifications/store-and-forward HTTP" as a web app, but that's the current plan. If there are people interested in collaborating on design or implementation, I would welcome you. See http://gonze.com/asynch-http/aREST_frame.htm for the current state of the design. I definately have not yet gotten the HTTP calls correct, and blame Visio export for the heinous HTML.
Jeff Bone wrote: > >... > > Understood, but... it's not clear that reusing SMTP is the right way to add this > kind of thing to HTTP. Remember, I'm just channelling and not claiming to have thought this all through: Maybe SMTP software is useful as a *software transport* for queued, routed, HTTP messages with retry-behaviour. The end-points may not know that SMTP is being used as an intermediary. Paul Prescod
per MB: > Basically, [tunnelling] breaks HTTP's end-to-end > model. To not break it would require treating the encapsulated > message as transparent rather than opaque, and doing stuff like > stripping the Connection header on the first hop (etc.., etc.., > etc..) Is this the reason that SMTP tunneling would break the end to end model: there's no practical way to fully emulate HTTP 1.1 using SMTP, therefore an SMTP transport would have to monkey with the protocol. Yes? I agree that any solution which has to do stuff like strip the Connection header is not doable. Also, any solution which isn't completely straight up with the client about what's going on is unacceptable -- that's why a Freenet-style hacked proxy can't work. One possible solution is that tunnelled HTTP must be HTTP 1.0 or even 0.9.
I'm going to give anybody who wants to comment on the REST article one more evening. I'll submit tomorrow. I appreciate the encouragement from those who read it but didn't find time for detailed comments. I know about the vast gulf between intentions and possibility. Paul Prescod
Lucas Gonze wrote: > >....comments welcome... > I'm guessing that the reason that in the first example there is a "callback time" is just to show that the result is not instantaneous. What does "note: URL encoded body" mean? Do you mean that you're running the URL encoding algorithm over the XML? Or that the XML is an approximation of something that really uses ampersands and semicolons? The stocks example is not clear on how the service decides when to send notifications. I think something more compelling would be to send a notification when the stock passes a floor or ceiling. Is there a way to put some prose on each example describing the application? At the bottom of the first page of "Store and Forward" you've got the Responder responding to the Requester. I don't think they've got a connection to each other, so I think that's a typo. It should be responding to the Email Service thingee. That's about where I get lost in that whole example. Why do we need store and forward for this application? Here's where I would use store and forward. My laptop is going to be off the network so I ask a web service to contact me via a store and forward web service instead of directly. But you have the requester (e.g. my laptop) contacting the responder through a store and forward service. As a graphical thing, is it possible to have the thing closest to the requester (end-user) always on the left hand side and the thing closest to the real service always on the right? And maybe it would be cool if you could add a "time passes" bubble to differentiate the asynch parts from the sync parts. A fundamental part of this is the mail->HTTP gateway. The important thing is that the mail software does the queuing, retry etc. But if the HTTP target of the message is offline is there a way for the "Email service" to let the MTA know that it has failed to deliver? I guess I don't know whether the "email service" is a separate process working through mail protocols or a milter or a thing pointed to from the .forward or ... Whatever it is, it needs to be able to translate HTTP failures into mail delivery failures. Paul Prescod
> -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Monday, January 21, 2002 8:04 PM > To: Lucas Gonze; Rest-Discuss > Subject: Re: [rest-discuss] drafting an asynch http > > > Lucas Gonze wrote: > > > >....comments welcome... > > > > I'm guessing that the reason that in the first example there is a > "callback time" is just to show that the result is not instantaneous. Yup. Added note to that effect. > What does "note: URL encoded body" mean? Do you mean that you're running > the URL encoding algorithm over the XML? Or that the XML is an > approximation of something that really uses ampersands and semicolons? Not important -- removed that note. > The stocks example is not clear on how the service decides when to send > notifications. I think something more compelling would be to send a > notification when the stock passes a floor or ceiling. Added "floor" param. > Is there a way to put some prose on each example describing the > application? Done. > > At the bottom of the first page of "Store and Forward" you've got the > Responder responding to the Requester. I don't think they've got a > connection to each other, so I think that's a typo. It should be > responding to the Email Service thingee. Correct. Fixed. > That's about where I get lost > in that whole example. Why do we need store and forward for this > application? Here's where I would use store and forward. My laptop is > going to be off the network so I ask a web service to contact me via a > store and forward web service instead of directly. Need to pick a better app. Will do. > But you have the requester (e.g. my laptop) contacting the responder > through a store and forward service. > > As a graphical thing, is it possible to have the thing closest to the > requester (end-user) always on the left hand side and the thing closest > to the real service always on the right? Todo. > > And maybe it would be cool if you could add a "time passes" bubble to > differentiate the asynch parts from the sync parts. :) > > A fundamental part of this is the mail->HTTP gateway. The important > thing is that the mail software does the queuing, retry etc. But if the > HTTP target of the message is offline is there a way for the "Email > service" to let the MTA know that it has failed to deliver? I guess I > don't know whether the "email service" is a separate process working > through mail protocols or a milter or a thing pointed to from the > .forward or ... Whatever it is, it needs to be able to translate HTTP > failures into mail delivery failures. These are good points. I stopped short of that level of detail in order to hit the main points first. The thing that I am most concerned about is getting the REST modeling right.
> > > I was trying to find some way for client initiated exchanges to have > > requests flow from server to client. This helps enable peer to peer between > > two firewalled nodes - with the assistance of a middleman. > > Well, with WATCH, you're doing that, but I guess you mean that you want > them coming back on the same connection. Yes - a persistent response (ala KnowNow) would do that. > > > For software behind a firewall, how would you suggest we maintain > > RESTfullness if we attempt client initiated messaging? > > Especially if you want to maintain existing programming models. > > Use GET and a persistent connection rather than WATCH. > Yes - but what would the response stream look like, if I wanted to pretend there were requests coming down the pipe? Especially if I wanted to service many resources via this single connection. I'm suggesting that putting one or more message/http-request entities in the response is the way to do that. I'm not so concerned with being extremely RESTful, at least at this level.
> > > I was trying to find some way for client initiated exchanges to have > > requests flow from server to client. This helps enable peer to peer between > > two firewalled nodes - with the assistance of a middleman. > > Well, with WATCH, you're doing that, but I guess you mean that you want > them coming back on the same connection. Yes - with WATCH, the requests come in as requests on a new connection, so the stream formats are exactly the same as existing message exchanges on the Web. But if you cannot listen for requests - firewalled - then what?
> > Argh, no. The difference isn't in "something" or "something final" --- it's in > >> vs. >, aka POST vs. PUT. Let me restate the sloppy example in a clearer > fashion: > > POST is like echo "something" >> foo > PUT is like echo "something" > foo > Oh. > Repeated POSTS of the same content are not necessarily idempotent; repeated > PUTs are. The semantic differences are in the methods, with no additional need > for status codes embedded in the message, different resources, etc. The > semantics of POST are that the state of the resource (i.e., progress of the > transaction) is updated, while PUT implies that the state of the resource is > replaced. It's appropriate to view *replacement* of the resource state as the > finalization of the transaction. > Well, as long as we have a common understanding that there are multiple messages and one of them is the 'finalization' of the transaction. > > One thought would be to make both the 'intermediate status' and the > > 'response' both URI addressable. > > Why not simply have content POSTED to the "progress-of-the-transaction" resource > indicate intermediate changes of state, while the first content successfully PUT > to the resource indicates the completion of the interaction? I may be missing > something really obvious, but I still don't think you need anything new, here. > I think POST and PUT to the same resource are sufficient. I suppose POST for the intermediate events and PUT for the final reply is fine.
> > > Especially if you want to maintain existing programming models. > > The one REST is most interested in maintaining is called "the Web." ;-) > I was thinking of API model rather than architectural model. As in provide the ASP Request and Response objects or the Servlet Request and Response objects to client-side programmers when they are behind a firewall and the other side is also behind a firewall. It'd be cool to write script to handle these & also let that script interact with the desktop UI (something I call Appster). (And if anybody is willing to fund that kind of peer to peer application engine, let me know.)
Asynch Messaging wrote: > > > > > Especially if you want to maintain existing programming models. > > > > The one REST is most interested in maintaining is called "the Web." ;-) > > > I was thinking of API model rather than architectural model. Now we're getting somewhere! :-) One of the basic ideas AFAICT behind REST is that the architectural model *implies* a certain style of application modeling, one with generic interfaces. Trying to map a typical API model directly onto generic interfaces is a losing proposition on lots of dimensions. jb
> > Use GET and a persistent connection rather than WATCH. > > > Yes - but what would the response stream look like, if I wanted to pretend > there were requests coming down the pipe? They wouldn't be requests, but it would be reasonable to assume that the response body to the GET would be the same as the request body on an incoming POST from a WATCH invocation ... with the minor difference that the GET would have to be streamed, perhaps with each chunk being an individual notification. > Especially if I wanted to service many resources via this single connection. Persistent connections can be used for multiple resources. > I'm suggesting that putting one or more message/http-request entities in the > response is the way to do that. I'm not so concerned with being extremely > RESTful, at least at this level. Well, if you have to, but I haven't seen the need yet. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > > > > > > Especially if you want to maintain existing programming models. > > > > > > The one REST is most interested in maintaining is called "the Web." ;-) > > > > > I was thinking of API model rather than architectural model. > > Now we're getting somewhere! :-) > > One of the basic ideas AFAICT behind REST is that the architectural model > *implies* a certain style of application modeling, one with generic interfaces. > Trying to map a typical API model directly onto generic interfaces is a losing > proposition on lots of dimensions. > Yes, I know that. I am trying to enable programmers to use this system, and one way is to provide this via existing APIs. Those APIs are not 'problem domain models' (information models) - which should be cast into generic RESTish interfaces - but just the existing technology coding APIs. I would literally like to take the client-initiated messaging via HTTP stuff & pipe it through Apache - you get things like DAV, JSP, etc. - or even IIS for ASP capabilities (if you don't have a mod_asp or whatever).
> > > Use GET and a persistent connection rather than WATCH. > > > > > Yes - but what would the response stream look like, if I wanted to pretend > > there were requests coming down the pipe? > > They wouldn't be requests, but it would be reasonable to assume that > the response body to the GET would be the same as the request body > on an incoming POST from a WATCH invocation ... with the minor > difference that the GET would have to be streamed, perhaps with > each chunk being an individual notification. And I think that the response body being the same as the request body should be indicated by a Content-Type header - hence the message/http-request stuff.. A response looks like a request, but without the first line - the method and resource. And with good enough access to the lower levels of HTTP, using chunked encoding with each discrete message within the response might work. I haven't followed this out to look at encoding issues or at multi-hop (proxies) issues. But it sounds fun anyway.
> > They wouldn't be requests, but it would be reasonable to assume that > > the response body to the GET would be the same as the request body > > on an incoming POST from a WATCH invocation ... with the minor > > difference that the GET would have to be streamed, perhaps with > > each chunk being an individual notification. > And I think that the response body being the same as the request body should > be indicated by a Content-Type header - hence the message/http-request > stuff.. A response looks like a request, but without the first line - the > method and resource. No no, because what I'm talking about doesn't have the request line, just the headers (unencapsulated) and body. So content-type would be like application/xml, or whatever. Not message/http. > And with good enough access to the lower levels of HTTP, using chunked > encoding with each discrete message within the response might work. > > I haven't followed this out to look at encoding issues or at multi-hop > (proxies) issues. But it sounds fun anyway. We have at PF. Lots of fun. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I'd like opinions on how the client indicates to the server that it is asking for notifications. I think I've seen the following options discussed here: 1. through a new method WATCH /blah/blah 2. through the existence of a new header in a POST Reply-to: http://.... 3. through a form parameter in a POST &reply-to=http://.... 4. through a POST of a content type Content-type: application/www-notification-request 5. The application could merely "know" that when a POST is made to a particular URI that the request is for a notification. I guess I prefer 2, the reply-to header. Lucas, why do your examples use 3? I would rather leave the POST body completely in the domain of the application because what if the application wants to pass XML or graphics as the body? Paul Prescod
----- Original Message ----- From: "Mark Baker" <distobj@...> > > > They wouldn't be requests, but it would be reasonable to assume that > > > the response body to the GET would be the same as the request body > > > on an incoming POST from a WATCH invocation ... with the minor > > > difference that the GET would have to be streamed, perhaps with > > > each chunk being an individual notification. > > And I think that the response body being the same as the request body should > > be indicated by a Content-Type header - hence the message/http-request > > stuff.. A response looks like a request, but without the first line - the > > method and resource. > > No no, because what I'm talking about doesn't have the request line, just > the headers (unencapsulated) and body. So content-type would be like > application/xml, or whatever. Not message/http. > I'm not sure that would do what I want - but I can definitely see that it would be useful. For what I am trying to do - and there may be better ways of doing it - it seems that I need a request line (the URI and method). If a server managing a collection of resources cannot receive inbound requests, yet can fetch arbitrary data, how would receiving headers and body help service request upon that collection of resources? Maybe its a different problem. What does your (response) body actually look like? Are you doing client initiated retrieval of requests? Color me confused.
> I'd like opinions on how the client indicates to the server that it is > asking for notifications. I think I've seen the following options > discussed here: > > 1. through a new method > > WATCH /blah/blah > > 2. through the existence of a new header in a POST > > Reply-to: http://.... > > 3. through a form parameter in a POST > > &reply-to=http://.... > > 4. through a POST of a content type > > Content-type: application/www-notification-request > > 5. The application could merely "know" that when a POST is made to a > particular URI that the request is for a notification. > > I guess I prefer 2, the reply-to header. Lucas, why do your examples use > 3? I would rather leave the POST body completely in the domain of the > application because what if the application wants to pass XML or > graphics as the body? Right. #3 is a crude form of RPC, equivalent to #4 (and #5 if you think about it). But #2, with that header, isn't sufficient either. I assume that you were trying to use my WATCH-as-PUT example where only an extension header was required? If so, the header there works quite differently than just "Reply-To". I also prefer the new method. A practical reason is that the meaning is more obvious, especially to most firewalls that permit blocking based on methods. None I know of can follow a hypertext transaction to understand what you're really doing with GET, follow-header, PUT/POST, etc.. Though there's no reason that they can't, they don't. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> I'm not sure that would do what I want - but I can definitely see that it > would be useful. > For what I am trying to do - and there may be better ways of doing it - it > seems that I need a request line (the URI and method). > If a server managing a collection of resources cannot receive inbound > requests, yet can fetch arbitrary data, how would receiving headers and body > help service request upon that collection of resources? Maybe its a > different problem. What does your (response) body actually look like? Are > you doing client initiated retrieval of requests? > Color me confused. Ah, I see now. You'd have to tunnel in this case. This is at a lower layer. So feel free to do that, so long as at your highest layer, HTTP's end to end semantics are preserved. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I like using a header, except when headers are not available, as in a browser. In that case I'd 'tunnel' them into query terms ?reply-to=http://... But you are not asking for the client to receive notifications, you are asking the server to post to a location. If you want the client itself to receive notifications, you should use GET and an indication of the time range - i.e. the 'future' (but indicating some number/age of messages in the past is also useful). The server could return a list of message references - which would interestingly look a lot like a file listing - or it could return the messages themselves. You'd probably want to use an Accept header to indicate which representation you want. ----- Original Message ----- From: "Paul Prescod" <paul@...> > I'd like opinions on how the client indicates to the server that it is > asking for notifications. I think I've seen the following options > discussed here: > > 1. through a new method > > WATCH /blah/blah > > 2. through the existence of a new header in a POST > > Reply-to: http://.... > > 3. through a form parameter in a POST > > &reply-to=http://.... > > 4. through a POST of a content type > > Content-type: application/www-notification-request > > 5. The application could merely "know" that when a POST is made to a > particular URI that the request is for a notification. > > I guess I prefer 2, the reply-to header. Lucas, why do your examples use > 3? I would rather leave the POST body completely in the domain of the > application because what if the application wants to pass XML or > graphics as the body? > > Paul Prescod >
Mark Baker wrote: > I also prefer the new method. A practical reason is that the meaning is > more obvious, especially to most firewalls that permit blocking based > on methods. Ah, but here's where you and I diverge, Mark. While you see enabling firewalls as a positive, I see it as an unnecessary and undesirable hinderance to adoption of new technology. I.e., are notification applications so semantically different that we need to differentiate them for the purposes of firewall filtering *beyond* existing method filtering and the already significant issue of connection asymmetry? jb
> Mark Baker wrote: > > > I also prefer the new method. A practical reason is that the meaning is > > more obvious, especially to most firewalls that permit blocking based > > on methods. > > Ah, but here's where you and I diverge, Mark. While you see enabling > firewalls as a positive, I see it as an unnecessary and undesirable hinderance > to adoption of new technology. I.e., are notification applications so > semantically different that we need to differentiate them for the purposes of > firewall filtering *beyond* existing method filtering and the already > significant issue of connection asymmetry? It's not just firewalls. To any intermediary, the effort in determining what's going on is going to be greater for the extension header than for the extension method, at least during the initial transaction where the intermediary learns what the Watcher URI is. In an environment with very long lived subscriptions where that initial cost gets amortized, it's less of an issue. But in the absence of that info, and knowing that the method I need to use for subscription is POST (not PUT as with WebDAV LOCK), and so the chances of reusing deployed optimizations is nil, I'd go for the new method. But it's not a huge deal, I could live with either approach. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > Mark Baker wrote: > > > I also prefer the new method. A practical reason is that the meaning is > > more obvious, especially to most firewalls that permit blocking based > > on methods. Here're what I hope are a few *really, really* good arguments against introducing a WATCH method for subscription. (1) It doesn't make sense for all resources to support subscriptions; the naive behavior --- send me the entire new state anytime the resource changes --- doesn't make sense for all resources, particularly ones that change with high frequency. More sophisticated cases --- such as "send me only the changed state" --- probably cannot be defined generically for all (or even many) application domains and modeled resources. (2) Supporting subscriptions for a substantial portion of resources hosted by a particular domain has costs which may not be justified for a given service / application. (3) Recognizing (1) and preventing (2) would require a kind of fine-grained, per-resource configuration to allow or disallow WATCH behavior. Sure, global DENY could be overridden by local ALLOW, but do you *really* want to burden the server administrator with defining what is probably more accurately an application configuration issue? Is the cost of moving that configuration duty out into local config space e.g. Apache htaccess files really worthwhile? (4) Adding new methods to HTTP requires changes to many different server implementations, firewall implementations, etc. This has a very high cost in terms of delaying the propagation and limiting the reach of the new functionality in question. (5) It's not clear at all that a new method is required in order to preserve the end-to-end semantics of HTTP. For example, you could simply model the list of subscriptions to a given resource as a sub-URL of the resource, i.e. POST /some/resource/subscriptions?reply-to=http://foo.com/notices/1 POST /other/resource/subscriptions?reply-to=http://foo.com/notices/2 In this case, the subscription list for /interesting/resource is itself a resource on which GET, POST, and PUT all make sense without modification. The relationship between this subscription list and the resource it refers to is conventional rather than programatic, but it makes sense in a RESTful modeling sense. (At least, so it seems to me.) This is *no longer* an RPC because you aren't overloading POST semantics on the original resource of interest, but rather further reifying the notion of subscription in the domain of things to which URI refer. Subscription / notification is really a rather application-specific thing. It's not clear to me that a generic subscription / notification mechanism justifies polluting the method space rather than just coming up with some generic conventions, nor is it clear that adding such a method will spur universal development and interoperability of async HTTP applications. IMO, it's a losing proposition all the way around, compared to other alternatives. jb
Mark Baker wrote: > It's not just firewalls. To any intermediary, the effort in determining > what's going on is going to be greater for the extension header than for > the extension method, at least during the initial transaction where the > intermediary learns what the Watcher URI is. No doubt. > In an environment with > very long lived subscriptions where that initial cost gets amortized, > it's less of an issue. But in the absence of that info, and knowing > that the method I need to use for subscription is POST (not PUT as with > WebDAV LOCK), and so the chances of reusing deployed optimizations is > nil, I'd go for the new method. > > But it's not a huge deal, I could live with either approach. Coolness. IMO, no matter what else happens, you'll see non-HTTP methods first and most broadly, simply due to adoption friction. jb
Beyond asynch, the other buzzword that HTTP seems to miss is "reliability". One part of reliability is disk-backed queuing in case of crashes. I think that's a software issue, not a protocol issue. Another part of reliable messaging as it is normally implemented is queuing. I think that this is probably an orthogonal issue to actual reliability. The main part is once and only once delivery. This only matters for non-idempotent methods (primarily POST). As far as I know, the only protocol issue (as opposed to software issue) is some form of ID that ensures that the same thing (e.g. purchase order) is not POSTed twice. Should there be a convention for doing it so that it need not be always done at the application level? There must be a reason that HTTP doesn't have this already. Paul Prescod
Here is one application-agnostic way that you might implement "only once" delivery in HTTP: ---> RPOST /purchase_orders HTTP/1.1 <--- 201 Created Location: /reliable_delivery_target_1432 Expires: Thu, 01 Dec 2094 16:00:00 GMT "A one-time delivery location has been set up. Please PUT the information there. Only the first PUT will be respected. Subsequent PUTs will be rejected." ---> PUT /reliable_delivery_target_1432 <-- 200 OK "Thank you for this purchase order...it will be processed as if you had POSTed it normally." This would be semantically equivalent to a single POST and response. A reliable delivery target would timeout after some time. It could be DELETEd if it wasn't going to be used for some reason. The first PUT would launch whatever processing the POST would have (in fact with mod_reliable, it would look to your application as if it WERE a POST). I thought that this method-based approach was more REST-y than an "only-once" ID because it reifies the ID so that the server does not need "implicit state" tracking which IDs have come through before. It takes an extra hop to let the server choose the ID but then both the client and the server have the same view of the time-window for the PUT. Paul Prescod
Paul said: > > 3. through a form parameter in a POST > > > > &reply-to=http://.... ... > > I guess I prefer 2, the reply-to header. Lucas, why do your examples use > > 3? I would rather leave the POST body completely in the domain of the > > application because what if the application wants to pass XML or > > graphics as the body? > And Mark said: > Right. #3 is a crude form of RPC, equivalent to #4 (and #5 if you think > about it). Them's fightin words in these parts, Baker. ;) I used #3 with full knowledge of the other alternatives because this approach models asych comms as a _web app_. If it's a web app then the arguments belong in the domain of the app, which is the POST body. > But #2, with that header, isn't sufficient either. I assume that you > were trying to use my WATCH-as-PUT example where only an extension > header was required? Yes. > If so, the header there works quite differently > than just "Reply-To". Explain? > I also prefer the new method. A practical reason is that the meaning is > more obvious, especially to most firewalls that permit blocking based > on methods. None I know of can follow a hypertext transaction to > understand what you're really doing with GET, follow-header, PUT/POST, > etc.. Though there's no reason that they can't, they don't. This is the best reason not to do it as a web app -- that it requires a fairly complex combination of elements. The counter argument is that REST says that we get less overall complexity by inventing new nouns and reusing existing verbs than by inventing new verbs. Per firewalls, I leave it to them to keep up. I am on the side of firewall transgressors in this. - Lucas
I have been considering this requirement as a feature of store-and-forward. In a S-F model, once the message is emitted there is software to make every effort to get it delivered, including queueing, retries, expiration, failure notification, etc. Note that SMTP infrastructure already covers all of this, and that the SMTP/HTTP binding I proposed should support it as well. > Beyond asynch, the other buzzword that HTTP seems to miss is > "reliability". One part of reliability is disk-backed queuing in case of > crashes. I think that's a software issue, not a protocol issue. > > Another part of reliable messaging as it is normally implemented is > queuing. I think that this is probably an orthogonal issue to actual > reliability. > > The main part is once and only once delivery. This only matters for > non-idempotent methods (primarily POST). As far as I know, the only > protocol issue (as opposed to software issue) is some form of ID that > ensures that the same thing (e.g. purchase order) is not POSTed twice. > Should there be a convention for doing it so that it need not be always > done at the application level? There must be a reason that HTTP doesn't > have this already. > > Paul Prescod
> The main part is once and only once delivery. This only matters for > non-idempotent methods (primarily POST). As far as I know, the only > protocol issue (as opposed to software issue) is some form of ID that > ensures that the same thing (e.g. purchase order) is not POSTed twice. > Should there be a convention for doing it so that it need not be always > done at the application level? There must be a reason that HTTP doesn't > have this already. Yup, there is. If you use that header, you want to be able to know that that the other end of the pipe understands it. Because most will just ignore it and not tell you they are doing so (per RFC 2616). Enter the need for a mandatory extension mechanism, such as in RFC 2774 (M-*) or in SOAP (though with SOAP headers). See the example at the end of this; http://lists.w3.org/Archives/Public/ietf-discuss/2001Dec/0008.html MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> And Mark said: > > Right. #3 is a crude form of RPC, equivalent to #4 (and #5 if you think > > about it). > > Them's fightin words in these parts, Baker. ;) > > I used #3 with full knowledge of the other alternatives because this approach > models asych comms as a _web app_. If it's a web app then the arguments belong > in the domain of the app, which is the POST body. Ah, ok, I follow now. You want to do this from a browser, so you're stuck with application/x-www-form-urlencoded. Got it. Ideally, you'd just post the URI (as text/uri), or some XML description of the characteristics of the watch you're doing, to the container that houses the list of current watchers. But because you're doing it from a browser, you're stuck needing a name for the URI. But I suggest that "Reply-To" is unnecessary, in case, as I did, somebody thought that the name was required in order to trigger a watch. It isn't, all that's required is the URI, so you could just have had; "uri=http://..." > > If so, the header there works quite differently > > than just "Reply-To". > > Explain? Just like I said here; http://groups.yahoo.com/group/rest-discuss/message/47 The active header is "Properties" (from DAV), plus the extension is really the "watch" modifier of it that says we're looking at the watch property. > > I also prefer the new method. A practical reason is that the meaning is > > more obvious, especially to most firewalls that permit blocking based > > on methods. None I know of can follow a hypertext transaction to > > understand what you're really doing with GET, follow-header, PUT/POST, > > etc.. Though there's no reason that they can't, they don't. > > This is the best reason not to do it as a web app -- that it requires a fairly > complex combination of elements. The counter argument is that REST says that we > get less overall complexity by inventing new nouns and reusing existing verbs > than by inventing new verbs. No, REST doesn't say that. It's only recommendation wrt creating new methods is that you understand that you're forgoing the use of existing and possible future optimizations created around existing methods. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I have posted an update to the strawman, with suggestions incorporated, better explanatory text, etc. http://gonze.com/asynch-http/aREST_frame.htm
Mark Baker wrote: > >... > > If you use that header, you want to be able to know that that the other > end of the pipe understands it. Right, I figured this out later and invented "RPOST". > ... Because most will just ignore it and > not tell you they are doing so (per RFC 2616). Enter the need for a > mandatory extension mechanism, such as in RFC 2774 (M-*) or in SOAP > (though with SOAP headers). "An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server." Paul Prescod
Lucas Gonze wrote: > > I have posted an update to the strawman, with suggestions incorporated, better > explanatory text, etc. > > http://gonze.com/asynch-http/aREST_frame.htm Looking good! Question: isn't the implementation of the StoreAndForwardWebService irrelevant to the outside? It's a black box. You use SMTP not really as a "protocol" but as an API for a particular piece of software you have that happens to do the queuing and retry that you want. I say "API" instead of "protocol" because the SMTP bit is only used within the web service and is never exposed to either the requester nor the responder. Maybe the implementation bit should be on a separate slide to make this clear. (do we intend to publicize this URI?) When you say this is a "web app" you mean what the industry calls web service. It is a web-based service that exposes some functionality: storing and forwarding. Paul Prescod
Lucas Gonze wrote: > > I have been considering this requirement as a feature of store-and-forward. ] What if I need reliability AND syncronicity? I think reliability should be orthogonal to store and forward. > ... In > a S-F model, once the message is emitted there is software to make every effort > to get it delivered, including queueing, retries, expiration, failure > notification, etc. Note that SMTP infrastructure already covers all of this, > and that the SMTP/HTTP binding I proposed should support it as well. That isn't what I mean by reliability though. If I email you a purchase order for a million dollars of work, are we guaranteed that it will arrive once and only once? I don't think so. If the last packet of your SMTP response does not arrive then I don't know whether you got it or not. The only safe thing is to send it again. But then I might have purchased two million dollars worth of work. Paul Prescod
Mark Baker wrote: > > ... > > The active header is "Properties" (from DAV), plus the extension is > really the "watch" modifier of it that says we're looking at the > watch property. Isn't http://www.yahoo.com/properties;watch a violation of the opaque URI policy? You're generating a URI on the client side by pasting together strings using some convention! Paul Prescod
> Looking good! :) > > Question: isn't the implementation of the StoreAndForwardWebService > irrelevant to the outside? It's a black box. You use SMTP not really as > a "protocol" but as an API for a particular piece of software you have > that happens to do the queuing and retry that you want. I say "API" > instead of "protocol" because the SMTP bit is only used within the web > service and is never exposed to either the requester nor the responder. > > Maybe the implementation bit should be on a separate slide to make this > clear. (do we intend to publicize this URI?) Good points. I think that what's useful about the StoreAndForwardWebService implementation is just proof of concept. The slides should be clear about this. I already have to publicize the URL to the o'reilly etech conf committee, since I am proposing a talk on the subject, so maybe we should also add it to the REST Wiki and do any other marketing that seems appropriate. > When you say this is a "web app" you mean what the industry calls web > service. It is a web-based service that exposes some functionality: > storing and forwarding. Amen. I have incorporated that into the slides.
> Isn't http://www.yahoo.com/properties;watch a violation of the opaque > URI policy? You're generating a URI on the client side by pasting > together strings using some convention! Maybe, but not necessarily. I'm still figuring out the opacity characteristics of ";" (though I think I've got "/" and ";" figured out). 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> (though I think I've got "/" and ";" figured > out). 8-) Er, make that "?". MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
You should make notification subscriptions into addressable resources so that they may be DELETEd by the client. Paul Prescod
Jeff, I buy your arguments from tactical practicality but not long-term purity. I absolutely think it would be cool if my browser had a button that said: "WATCH this URL." It would authenticate me (just as for PUT) and then watch it. Therefore I'd propose that we view it as a convention layered on top of existing methods in the short term with a transition to a WATCH method in the long (perhaps very long) term. Jeff Bone wrote: > >... > > (1) It doesn't make sense for all resources to support subscriptions; the naive > behavior --- send me the entire new state anytime the resource changes --- doesn't > make sense for all resources, particularly ones that change with high frequency. > More sophisticated cases --- such as "send me only the changed state" --- probably > cannot be defined generically for all (or even many) application domains and > modeled resources. Hmmm. It seems like sometimes you want a notification that a change has happened, sometimes you want a notification that embeds the changed object and sometimes you want a diff. I think that the first case applies pretty efficiently and generally to all objects everywhere. Maybe we should only ever send URLs, not representations, in notifications. The client can easily do a GET if it wants the data, and some kind of "GET the difference" if it knows how to do that. > (2) Supporting subscriptions for a substantial portion of resources hosted by a > particular domain has costs which may not be justified for a given service / > application. The same goes for supporting PUT! That's why most web sites don't support PUT! > (3) Recognizing (1) and preventing (2) would require a kind of fine-grained, > per-resource configuration to allow or disallow WATCH behavior. Doesn't seem much different than PUT to me. > (4) Adding new methods to HTTP requires changes to many different server > implementations, firewall implementations, etc. This has a very high cost in > terms of delaying the propagation and limiting the reach of the new functionality > in question. Granted. > (5) It's not clear at all that a new method is required in order to preserve the > end-to-end semantics of HTTP. For example, you could simply model the list of > subscriptions to a given resource as a sub-URL of the resource, i.e. I like the idea of reifying subscriptions but see it as complementary to a new HTTP method. The method would return the subscription URI in its Location: header. > POST /some/resource/subscriptions?reply-to=http://foo.com/notices/1 > POST /other/resource/subscriptions?reply-to=http://foo.com/notices/2 It's arguable whether the client should have to create a separate end-point if they want separate subscriptions. Might not it make sense to have dozens of service with an endpoint of mailto:email@...?
DSN/MDN, Delivery Status Notification/Message Delivery Notification, is a good model for acks, though it should be wrapped via the specification of the web app. I would expose a success/failure notification in the web interface and leave the internals (SMTP or otherwise) to the implementation. Our design would need an ack specification, and DSN/MDN is a good place to start, but the interface should probably not be canonical DSN/MDN. ...need to read that specification, which I haven't done, and see how generic it is. > That isn't what I mean by reliability though. If I email you a purchase > order for a million dollars of work, are we guaranteed that it will > arrive once and only once? I don't think so. If the last packet of your > SMTP response does not arrive then I don't know whether you got it or > not. The only safe thing is to send it again. But then I might have > purchased two million dollars worth of work. > > Paul Prescod >
> From: Paul Prescod [mailto:paul@...] > > You should make notification subscriptions into addressable resources so > that they may be DELETEd by the client. In "notifications" slide, removed body argument notificationTarget and changed target URI from POST /notifications/ HTTP/1.1 to POST /notifications/stocks/symbols/APLX HTTP/1.1 Note that a DELETE would depend on session state. Don't know if this clashes with DELETE semantics.
Paul Prescod wrote: > Therefore I'd propose that we view it as a convention layered on top of > existing methods in the short term with a transition to a WATCH method > in the long (perhaps very long) term. I'm not *entirely* antagonistic to this kind of a both / and approach, assuming that we can guarantee that the semantics of the two mechanisms are consistent and that any service that supports WATCH is also required to support the other mechanism as well. (I think this is important from an adoption perspective.) Having said that, let me (gently) play devil's advocate on a couple of these... > Hmmm. It seems like sometimes you want a notification that a change has > happened, sometimes you want a notification that embeds the changed > object and sometimes you want a diff. I think that the first case > applies pretty efficiently and generally to all objects everywhere. > > Maybe we should only ever send URLs, not representations, in > notifications. The client can easily do a GET if it wants the data, and > some kind of "GET the difference" if it knows how to do that. I think that the kind of notification desired is a very application (i.e., resource) specific thing. There are really three distinct parts to a subscription: an expression of interest in notifications of state change on some resource by some other component, an event notification of state change per-se, and potentially the representation of the changed state. In the latter case, what you're really doing is specifying what representation of the resource you want sent to you when state changes; it's entirely consistent (AFAICT) with HTTP / URI to specify this in a query string, e.g. POST /some/rsrc/subs?reply-to=http://foo.com/notices/1;repr=delta But there's a deeper issue: what does a state change on a given resource mean, exactly? It's not clear that this is generically meaningful for all resources. If a web page, for example, contains a counter that changes every time a GET happens on it, should that then trigger a bunch of notifications? IMO, the issue of what's "in" a notification, how to represent it, and when to trigger it are all dependent on the application / resource in question. Each app --- indeed each resource --- should be free to define these things however they like. > > (2) Supporting subscriptions for a substantial portion of resources hosted by a > > particular domain has costs which may not be justified for a given service / > > application. > > The same goes for supporting PUT! That's why most web sites don't > support PUT! Yup. Think about that. > > (3) Recognizing (1) and preventing (2) would require a kind of fine-grained, > > per-resource configuration to allow or disallow WATCH behavior. > > Doesn't seem much different than PUT to me. Absolutely correct. IMO, it's not that PUT wouldn't be appropriate in many cases; it's that it's operationally too hard to use for many app developers in many contexts. Several issues combine to make PUT less exploited than it could otherwise be. The application developer / operator is often not the Web server administrator, and when the app developer / operator has to get the Web server administrator to perform application-specific configurations it (a) often doesn't happen, (b) often takes a long time, and (c) is rather fragile over time. These kinds of friction and others lead application developers to abandon certain available features and, indeed, push them towards tunnelling things *through* HTTP in inappropriate ways, failing to leverage the resource model and namespace, etc. (This is a generic problem with the way IT is internally organized in many places; ther's also a tug-of-war between apps / ops and admin. It results in balkanization and duplication, such as in the entirely distinct user management mechanisms for e.g. databases and networks as a whole.) Anyway, recognizing that this problem exists, it seems silly to build something and hope it's generally used when there's this kind of built-in adoption friction. > I like the idea of reifying subscriptions but see it as complementary to > a new HTTP method. If this is strongly true, then I'm (somewhat uneasily) okay with a new method; if the spec for a new method *requires* that subscriptions be reified in a general way --- thus ensuring parity of method and non-method based, um, methods --- then we're good. I doubt very seriously that this is acceptable to the general HTTP audience, though --- the protocol space shouldn't mold the resource model. > It's arguable whether the client should have to create a separate > end-point if they want separate subscriptions. Might not it make sense > to have dozens of service with an endpoint of mailto:email@...? We agree on the value of reifying subscriptions on the server end of things; similar benefits and arguments obtain for reifying subscriptions on the client end of things. If you *don't* reify subscriptions on the client end of things, then generally speaking the client needs to do much more work to determine what particular subscription a particular event notification refers to. This probably means embedding data about the sender in either the headers or the body of the notification, and that's somewhere I think we all agree we don't want to go. Resources, not endpoints. :-) jb
Lucas Gonze wrote: > > > From: Paul Prescod [mailto:paul@...] > > > > You should make notification subscriptions into addressable resources so > > that they may be DELETEd by the client. > > In "notifications" slide, removed body argument notificationTarget and changed > target URI from > POST /notifications/ HTTP/1.1 > to > POST /notifications/stocks/symbols/APLX HTTP/1.1 Well I was thinking about asking for that too, but it wasn't what I meant. I meant that in the RESPONSE, there should be a Location header: Location: http://www.thismachine.com/stocks/symbols/APLX/notifications/1 You could DELETE that later if you wanted to cancel notification. You could PUT to it if you wanted to change the notification trigger rules and expiry time. You could GET it to remind yourself of the notification trigger rules and expiry time. You could fiddle ACLs on it to allow other people to fiddle with your notifications. In other words, it should be a first-class resource. Paul Prescod
Lucas Gonze wrote: > Note that a DELETE would depend on session state. Don't know if this clashes > with DELETE semantics. This is clever, but it does clash. From rfc2616 sec 9.7: "The DELETE method requests that the origin server delete the resource identified by the Request-URI." If the URI in question represents the object being subscribed to rather than the subscription itself, then the meaning of the DELETE is now ambiguous and probably not easily disabiguated. My suggestion: if the resource of interest is /resource then its server-side subscriptions are represented under a collection /resource/subs and each shows up as /resource/subs/<someid> * Getting a subscription is a process of doing a POST to /resource/subs. * Getting the list of subs ifor resource s a GET on /resource/subs. * The state of a sub can be changed by an appropriate POST to /resource/subs/<someid>. * A sub can be cancelled via a DELETE on /resource/subs/<someid> Authentication of any / all of these operations is an orthogonal issue, handled in any of the usual ways. jb
> > Note that a DELETE would depend on session state. Don't know if > this clashes > > with DELETE semantics. > > This is clever, but it does clash. !$!#@$. > My suggestion: if the resource of interest is > > /resource > > then its server-side subscriptions are represented under a collection > > /resource/subs Agreed with a caveat: If the target is /subs/resource[/someid] instead of /resource/subs[/someid] then the implementation can grab all subevents of /subs. This enables implementations to plug into existing apps more cleanly, because they can just be mounted under a unique root. The root(s) could be anywhere on a server, but would own the entire namespace under that root. > * Getting a subscription is a process of doing a POST to /resource/subs. > * Getting the list of subs ifor resource s a GET on /resource/subs. > * The state of a sub can be changed by an appropriate POST to > /resource/subs/<someid>. > * A sub can be cancelled via a DELETE on /resource/subs/<someid> > > Authentication of any / all of these operations is an orthogonal > issue, handled in > any of the usual ways. Appended Location: header with /[some-id] to all 202 responses. Appended the /[some-id] tag to all relevant requests. Added the following interaction between requester and responder to notifications slide: DELETE http://responder-host/notifications/stocks/symbols/APLX/ID/[some-id] HTTP/1.1 Todo eventually: * illustrate getting list of subs, changing state of a sub. * more text to say why things are the way they are. - Lucas
Jeff Bone wrote: > > Paul Prescod wrote: > > > Therefore I'd propose that we view it as a convention layered on top of > > existing methods in the short term with a transition to a WATCH method > > in the long (perhaps very long) term. > > I'm not *entirely* antagonistic to this kind of a both / and approach, assuming that we > can guarantee that the semantics of the two mechanisms are consistent and that any > service that supports WATCH is also required to support the other mechanism as well. (I > think this is important from an adoption perspective.) Fair enough. > ... > > I think that the kind of notification desired is a very application (i.e., resource) > specific thing. There are really three distinct parts to a subscription: an expression > of interest in notifications of state change on some resource by some other component, > an event notification of state change per-se, and potentially the representation of the > changed state. In the latter case, what you're really doing is specifying what > representation of the resource you want sent to you when state changes; it's entirely > consistent (AFAICT) with HTTP / URI to specify this in a query string, e.g. > > POST /some/rsrc/subs?reply-to=http://foo.com/notices/1;repr=delta Why not a header like "Accepts"? > But there's a deeper issue: what does a state change on a given resource mean, > exactly? It's not clear that this is generically meaningful for all resources. If a > web page, for example, contains a counter that changes every time a GET happens on it, > should that then trigger a bunch of notifications? This is already fuzzy because of caching. Obviously we don't treat every counter bump as a state change and the HTTP spec. has leeway to allow that. So the problem isn't specific to subscriptions. > ... IMO, the issue of what's "in" a > notification, how to represent it, and when to trigger it are all dependent on the > application / resource in question. Each app --- indeed each resource --- should be > free to define these things however they like. I agree. We can only standardize the parts that are really general. But I think that it is possible to define a base behaviour that is widely applicable and optimizable. In particular: * notifications are sent whenever the resource thing changes in a "meaningful" sense * the notification's representation is specified in a header, else it is just a URL * a notification's lifespan is expressed in a header, else it is server defined > > > (2) Supporting subscriptions for a substantial portion of resources hosted by a > > > particular domain has costs which may not be justified for a given service / > > > application. > > > > The same goes for supporting PUT! That's why most web sites don't > > support PUT! > > Yup. Think about that. I'm content to have WATCH be like PUT, something that we would like to be widespread some day, but probably not for a while. >... > Anyway, recognizing that this problem exists, it seems silly to build something and hope > it's generally used when there's this kind of built-in adoption friction. Absolutely agree that WATCH must be like PUT: something you could use but that you could do without if you're stuck with stupid admins or coders who want to only learn two methods. > ... > If this is strongly true, then I'm (somewhat uneasily) okay with a new method; if the > spec for a new method *requires* that subscriptions be reified in a general way --- thus > ensuring parity of method and non-method based, um, methods --- then we're good. I > doubt very seriously that this is acceptable to the general HTTP audience, though --- > the protocol space shouldn't mold the resource model. Either way the protocol space is molding the resource model. Whether it is a header or a method, it is "protocol". And anyway, doesn't PUT mold the resource space? You PUT something you get a new resource. Yu DELETE something you remove a resource. WATCH creates a new notification resource. Another option is for the Server to return a "Subscription-URI:" header to a GET or HEAD. Then the client knows that it can POST to the subscription-URI to get a subscription for this resource. --> GET /index.html <--- 200 OK Subscription-URI: /index.html?subscriptions ---> POST /index.html?subscriptions This maintains the virtue of allowing *any resource* to declare that it is watchable without out-of-band arrangement. That's what I'm trying to preserve. I don't want a bunch of conventions that client and server have to agree to use through email. For simple cases I want it to "just work". >... > We agree on the value of reifying subscriptions on the server end of things; similar > benefits and arguments obtain for reifying subscriptions on the client end of things. > If you *don't* reify subscriptions on the client end of things, then generally speaking > the client needs to do much more work to determine what particular subscription a > particular event notification refers to. I agree that you will often want this. But maybe the changed URI is all you care about. That's all I cared about from netmind. Paul Prescod
Jeff Bone wrote: > > Lucas Gonze wrote: > > > Note that a DELETE would depend on session state. Don't know if this clashes > > with DELETE semantics. > > This is clever, but it does clash. From rfc2616 sec 9.7: "The DELETE method > requests that the origin server delete the resource identified by the > Request-URI." If the URI in question represents the object being subscribed to > rather than the subscription itself, then the meaning of the DELETE is now > ambiguous and probably not easily disabiguated. This is a straw man! I asked Lucas to reify the subscription as its own resource. THAT was what I said could be DELETEd. > My suggestion: if the resource of interest is > > /resource > > then its server-side subscriptions are represented under a collection > > /resource/subs I think that specifying URI structures is bad mojo. HTTP doesn't do that anywhere else. Opaque URIs and all of that. I'm learning this stuff by osmosis. Consider roy's suggestion here: http://www.xent.com/pipermail/fork/2001-September/004712.html "What I would have done (and this was proposed at an early DAV meeting) is define a single resource metadata field for HTTP responses that gave a URI prefix for operations on properties of that resource. E.g., Properties: "http://example.com/this_resource;props" and then simply define that namespace in the same way as old server-side image maps were defined. You could then do GET http://example.com/this_resource;props?lock HTTP/1.1" I don't want to build on WebDAV but I like the basic idea that the server says where a resource's properties go. I think we could use the same mechanism for subscriptions. Subscriptions: http://example.com/this_resource/subs You POST to that to get a new sub. > * Getting a subscription is a process of doing a POST to /resource/subs. Agree. Just think that the server should choose the subs location. > * Getting the list of subs ifor resource s a GET on /resource/subs. Agree with same caveat. > * The state of a sub can be changed by an appropriate POST to > /resource/subs/<someid>. POST or PUT??? Changing the state of a resource is done with PUT. > * A sub can be cancelled via a DELETE on /resource/subs/<someid> Agree. > Authentication of any / all of these operations is an orthogonal issue, handled in > any of the usual ways. Agree. Paul Prescod
> > * The state of a sub can be changed by an appropriate POST to
> > /resource/subs/<someid>.
>
> POST or PUT??? Changing the state of a resource is done with PUT.
9.5 POST The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
- Annotation of existing resources;
9.6 PUT The PUT method requests that the enclosed entity be stored under the
supplied Request-URI.
Again, it's src >> dest versus src > dest.
Given that a sub can be a fairly complex object, including parameters like
deltas vs. whole objects, permissions, etc, it seems to me that most state
changes will affect only a subset of parameters. If we were to use PUT it
should be like:
PUT /subs/resource/permissions/a+w
- Lucas
Lucas, More comments about your slides: Asynch Response: - how will status be returned in the final reply? I'm suggesting using a content-type of message/http-response which would have all the headers of a response. If parsing is an issue, then this could be change to a simple 'canonical xml representation of http' (which is something i've been wanting to do for a while) or some other format indicating status of the response to the initial client request.
> ----- Original Message ----- > From: Lucas Gonze > I have posted an update to the strawman, with suggestions incorporated, better > explanatory text, etc. > http://gonze.com/asynch-http/aREST_frame.htm In the 'notifications' slide, a POST is used to establish a subscription. What do people think of using a GET with one or more asynch responses? The GET without asynch response returns the price/info of the stock symbol. The GET with asynch response(s) returns "202 Accepted" with a Location header identifying the unique subscription, and the stock data is later posted to the ReplyTo uri specified in the initial request. Also, regarding notification, is it useful/required/whatever to know if an asynch response is an 'intermediate' reponse or a 'final' response? For example, if subscribed to stock quotes, periodic notifications that the 'value fetcher' has some transient errors might be useful. These would be indicated in a status code in the asynch response. Or is subscription fundamentally different than intermediate responses to an asynchronous operation?
Ok. I just got back from traveling and reading all of this email. I am going to try to put together answers to Paul and Jeff in one email. Here is what I think REST says: Only use HTTP. Only use HTTP methods (expose objects as URLs). Only use GET to make idempotent requests Use XML to represent structured data when necessary. My claims: HTTP GET does not allow requests that you want MIME-RPC allows delivery of those requests (HTTP does not prohibit specific POST from being idempotent) HTTP does not support asynchrony MIME-RPC does support asynchrony XML is a bad way to represent some structured data and a good way to represent others. Regarding GET and idempotency, Paul says you should just urlencode everything. He ignores the reality that real life HTTP servers and itermediaries will frequently cut off excessively long HTTP query strings. But that is really beside the point. Jeff's more substantive answer is: > The REST position is therefore that you need > to remodel your application to fit the HTTP model and thereby get all the > goodness of HTTP, rather than using it as a "dumb" conduit to tunnel other > protocols and map to other object models. *Fully expose your application as > resources that conform to the generic semantics of HTTP.* This is handwaving away the problem. You have to deal with application semantics as is. Suppose I want to implement TerroristOrNot.com. You send it a par of pictures of someone (front and side) and it replies whether or not that person is a terrorist. The pictures may be in GIF, JPEG, or PNG format. Using MIME-RPC over HTTP, you would POST either a list (multipart/mixed), or a struct (multipart/form-data) to some URL (e.g. terroristornot.com/verify). You cannot sanely do this with GET, therefore I think you cannot sanely do this with REST. Note to Paul: packaging the request as an XML document is also exceedingly ugly (though I now understand that XML is not part of REST). > > Claim: REST supports asynchronous messaging > > > > Reality: REST appears to require use of HTTP and > > HTTP does not support asynchronous requests. > > This is (a) incorrect, as we've already stated, and (b) rather ludicrous > anyway. Asynchrony as an application communication pattern doesn't require > an asynchronous communication protocol --- if it did, it wouldn't be possible > to build asynchronous applications with i.e. ONC RPC, CORBA, etc. But we do > just that. Syncronous request-response protocols are sufficient for building > asynchronous messaging on top of, and vice-versa --- both models are fully > general. Ok, I'll be more precise. HTTP is not a PROTOCOL for asynchronous messaging. To do asynchronous messaging with another party you need a protocol. Therefore, REST, as it stands does not support asynchrony! Note, that you can bulid asynchronous applications on top of HTTP is irrelevant because the asynchrony will only be between parties agreeing on some implicit new protocol. I can't believe this point is even in dispute, esp. in light of the recent discussion on REST-discuss on this very issue! With MIME-RPC, I proposed enhancing RFC822 slightly to achieve asynchorny. Specifically. initiators send a message-id (as in RFC822) and a reply-to-url (like reply-to, except it takes any URL -- so replies can be any uri scheme, like mailto:, http:, https:, imap:, ftp:, file:, etc.). These headers may be sent over any MIME transport (including HTTP or SMTP). Lucas Gonze has proposed a different enhancement to HTTP that attempts to achieve the similar goals (http://gonze.com/asynch-http/aREST_frame.htm). I think the biggest difference between the two proposals is the direct support for other uri schemes. I also think that Lucas's proposal covers many orthogonal messaging issues that are better handled with separate specs. I am actually in the process of drafting some of those right now, but I think they are add-ons to a much more basic asynchronous messaging spec. I will try to respond to Lucas post shortly, but here is my list of add-on services: * Reliable Delivery/Return-receipt/Expiration * Polling Delivery (sender has no return address) * Seriality (messages must be handled in order) * Atomicity (all-or-none of message group handled) * Consistency (any fault means none--see atomicity) * Isolation (no visible side effects until commit) * Durability * Prepare (useful for two phase commit) The main point is that these are add-ons. For basic stuff, I think you don't need anything more sophisticated than email. Remember: worse-is-better/simpler-is-better. > Reality: REST doesn't claim that applications should add to the HTTP method > set. (BTW, that was my loudest and most passionate objection to REST before > I "got it.") The REST claim is that almost anything you can think of doing > can be trivially recast within the context of HTTP's general, powerful > methods. (Atomic read+delete is an example of one possible missing method, > but there aren't many of them.) I like this idea A LOT. I just don't think it is always possible to do so. I also think that often programmers just want a way to expose their existing APIs over the web. MIME-RPC provides that as well. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Asynch Messaging wrote: > >...' > > In the 'notifications' slide, a POST is used to establish a subscription. > What do people think of using a GET with one or more asynch responses? And we differentiate a request for a normal GET form an asynch GET just by the Reply-to header? What's the advantage? It feels vaguely like method abuse to me but I can't put my finger on the detail in the time I have available. > Also, regarding notification, is it useful/required/whatever to know if an > asynch response is an 'intermediate' reponse or a 'final' response? For > example, if subscribed to stock quotes, periodic notifications that the > 'value fetcher' has some transient errors might be useful. These would be > indicated in a status code in the asynch response. Or is subscription > fundamentally different than intermediate responses to an asynchronous > operation? I think that our current idea is that you are asking when the thing changes, perhaps with some filter so that you only get notifications when it changes in a more significant sense (e.g. above some price boundary). If you want to follow a long-running process like a purchase order floating through a company getting digital signatures, then I think you would subscribe to a URI that represents its status. /purchase-orders/po234212/status Make sense? Paul Prescod
> This maintains the virtue of allowing *any resource* to declare that it > is watchable without out-of-band arrangement. That's what I'm trying to > preserve. I don't want a bunch of conventions that client and server > have to agree to use through email. For simple cases I want it to "just > work". Absolutely. Me thinks Jeff is straying from the opacity "axiom". FWIW, we at PF struggled with this some time ago, but what we have now is *lean*, I mean completely kick ass. It's a shame we're not even releasing free binaries (nevermind source). It does everything you're talking about here, but so much more. BTW, as I said to Jeff off-list, we won't be issuing any patents around this type of stuff - that would be silly, for all the usual reasons. But that means there's a lot of stuff I can't talk about until we're ready to talk about it. 8-( MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> Lucas Gonze has proposed a different enhancement > to HTTP that attempts to achieve the similar > goals > (http://gonze.com/asynch-http/aREST_frame.htm). > > I think the biggest difference between the two > proposals is the direct support for other uri > schemes. Sorry, that's a misreading. The other URI schemes are only meant to show that such things as store-and-forward and UDP transmission can and should be implemented as web apps. > > I also think that Lucas's proposal covers many > orthogonal messaging issues that are better > handled with separate specs. In some respects, yes. For example the email binding is completely orthogonal. But it's supposed to be, and is just there to illustrate (and understand) how such a thing would work. In other respects, no. The third solution wouldn't be possible without the second. That is not orthogonality. - Lucas
On Fri, 18 Jan 2002, Paul Prescod wrote: > "S. Alexander Jacobson" wrote: > > > >... > > > > In any case, RFC822 says that every mail message > > should have a globally unique identifier > > (message-id) and that replies should have > > "in-reply-to: message-id" in their headers. > > How do I dereference those identifiers? If I can't put an identifier in > a browser URL bar and expect to get some set of bytes back then I don't > personally think it is really REST-y. But then REST is just a philosophy > so there will be differences of opinion on that. I would say that > message-id's should be HTTP URLs that dereference to the message > contents and that ACLs should be used to say who can and cannot see it. > Archives of messages (e.g. egroups) could add a header RFC2111 says that message IDs are just presumed to be in some accessible message store. And it is up to the local implementation to deal with resolving it. That being said, I like the idea of making message-ids resolvable via HTTP and may add that as a "Should" to the MIME-RPC spec. > > The last one is important. XML does not easily > > allow delivery of multiple XML documents or other > > opaque data types like graphics or MSOffice files. > > MIME is designed to do just that. > > It is easy to set up an HREF from an XML document to a MIME. I don't > know whether SOAP does it intelligently or not. In Python it would take > me a couple of lines to get from an HREF to a MIME part so I don't know > what MIME-RPC adds. But then you are not interpreting the XML document correctly. What happens when an XML schema conflicts with an the MIME-type of an href'ed resource. > There's nothing wrong with RPC if it meets your needs. And MIME-RPC > seems a good way to do RPC if you are trying to avoid defining an XML > vocabulary. But I haven't yet seen how a REST web application would take > advantage of any of the MIME-RPC conventions. Ok. So part of what I am saying is that REST only works for a fairly limited application domain. However, in the context of REST, I am also saying that one may want: * to communicate asynchronously * to package primitive types with other types * to interoperate better with web browsers * to avoid using XML but have unambiguous semantics -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
My preference is to not return responses in requests. First, it requires code with a whole new kind of meaning to be written. Second, it overloads existing semantics without a strict definition of the replacement. Third, it creates a need for callbacks within the caller application without defining an interface to them. My favorite reason to do it is that it restricts access in a nice smart-contracts sort of way. > Asynch Response: > - how will status be returned in the final reply? > I'm suggesting using a content-type of message/http-response which would > have all the headers of a response. If parsing is an issue, then this could > be change to a simple 'canonical xml representation of http' (which is > something i've been wanting to do for a while) or some other format > indicating status of the response to the initial client request.
Mark Baker wrote: > Absolutely. Me thinks Jeff is straying from the opacity "axiom". IMO, the opacity axiom doesn't mean that URI can't have semantics in a particular application domain, it just means that (a) the infrastructure can't assume anything about those semantics, and (b) they should be confined to the query string. Any problem? jb
> > > Asynch Response: > > - how will status be returned in the final reply? So, how /will/ status be returned in the replies (regardless whether you consider them responses or requests).
In the response body. This is a good thing because status notifications will have to deal with things that aren't HTTP. delivery notifications/ failures/ successes; application errors with WATCH semantics (e.g. "resource was here when you asked but is now gone"). > From: S. Mike Dierken [mailto:mdierken@...] > > > - how will status be returned in the final reply? > So, how /will/ status be returned in the replies (regardless whether you > consider them responses or requests). > >
> Mark Baker wrote: > > > Absolutely. Me thinks Jeff is straying from the opacity "axiom". > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a > particular application domain, It means just that. As soon as you assign any meaning to a URI, then only those privy to that meaning are in on your little secrets (like appending "/subs" means "subscribers to the URI before /subs"). Interoperability means sacrificing private convention for public specification. So you make the URI-to-URI relationship explicit with a statement, such as is done with an HTTP header or an RDF statement, etc.. > it just means that (a) the infrastructure > can't assume anything about those semantics, and (b) they should be confined > to the query string. It means that too, though even the query string has limits - it's not fully transparent. For example, you shouldn't have to know some secret query parameter a priori in order to accomplish something. It's on my todo list to write up my opacity investigation, btw. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Lucas Gonze" <lucas@...> > > > From: S. Mike Dierken [mailto:mdierken@...] > > > > - how will status be returned in the final reply? > > So, how /will/ status be returned in the replies (regardless whether you > > consider them responses or requests). > > > > In the response body. > > This is a good thing because status notifications will have to deal with things > that aren't HTTP. delivery notifications/ failures/ successes; application > errors with WATCH semantics (e.g. "resource was here when you asked but is now > gone"). And the 'resource is now gone' status will be represented as a "404 Not Found" value in some way? Also, does that error status indicate whether it is temporary or permanent?
> And the 'resource is now gone' status will be represented as a "404 Not > Found" value in some way? > Also, does that error status indicate whether it is temporary or permanent? Sounds like a job for 410 (Gone). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> And the 'resource is now gone' status will be represented as a "404 Not > Found" value in some way? > Also, does that error status indicate whether it is temporary or permanent? Well, it's an application-level error, not an HTTP error. There's no HTTP analog for "was here but is now gone", and I wouldn't attempt to use 404 for it. Some yet-to-be-invented status scoped within the application specification like "927 Resource Temporarily Unavailable" seems more appropriate. Just as a general point about where I'm coming from here -- I believe that this functionality, whatever it is called, belongs at the application level.
Maybe another way of saying what Lucas is saying is that a notification is an HTTP *request*, not a response. By definition there can't really be an HTTP-level problem yet. Mozilla doesn't contact Apache and say: "something's really screwed up over here." I think we do need to be able to differentiate between state changes and deletions. Maybe a header? But a deletion isn't really an error. It's just a deletion. If there are notification-related errors that we need to report then there could be a header for them. In general, existing HTTP status codes will not be appropriate. Paul Prescod
> > Maybe another way of saying what Lucas is saying is that a notification > is an HTTP *request*, not a response. By definition there can't really > be an HTTP-level problem yet. Mozilla doesn't contact Apache and say: > "something's really screwed up over here." Your channelling is uncanny! ;) > I think we do need to be able to differentiate between state changes and > deletions. Maybe a header? But a deletion isn't really an error. It's > just a deletion. > > If there are notification-related errors that we need to report then > there could be a header for them. In general, existing HTTP status codes > will not be appropriate. I believe that this is wierd to think about because *whose* state is involved is not, in the case of callbacks to report provider-side errors, the server. So, rather than reporting server side status, I propose that callbacks to report status affect the state of a status resource. PUT /callbacks/stocks/APLX/status HTTP/1.1 410 GONE
> Another option is for the Server to return a "Subscription-URI:" header > to a GET or HEAD. Then the client knows that it can POST to the > subscription-URI to get a subscription for this resource. ... > This maintains the virtue of allowing *any resource* to declare that it > is watchable without out-of-band arrangement. That's what I'm trying to > preserve. I don't want a bunch of conventions that client and server > have to agree to use through email. For simple cases I want it to "just > work". I agree that avoiding out of band arrangements is a primary goal, but I believe that WSDL already meets this need. In addition, this is metadata about an application, not protocol-level functionality, so supporting it via special HTTP headers etc violates opacity. Proposed solution: have a single out-of-band communication to specify how to find the WSDL description. For example: "The service provider MAY choose to have a file named watch_services.wsdl at <some well known location>". At least one incantation will have to be involved, because the service description bootstraps the entire interaction. - Lucas
> Maybe another way of saying what Lucas is saying is that a notification > is an HTTP *request*, not a response. By definition there can't really > be an HTTP-level problem yet. Mozilla doesn't contact Apache and say: > "something's really screwed up over here." A notification is a message that describes a request/response pair - the event that occurred. The event may have completed successfully, or it may have had an error, or it may have been denied due to permissions. All these are useful and interesting to convey. Not all subscribers are interested in all events, and a filtering ability would be a plus - filtering on request/response headers (including response status). > > I think we do need to be able to differentiate between state changes and > deletions. Maybe a header? But a deletion isn't really an error. It's > just a deletion. If you echo (for the most part) the HTTP request that caused the change, then you'll have knowledge of the operation (type of state change - create, read, update, delete, add or remove) that ocurred. And if you echo (for the most part) the response then you'll have knowledge of whether that operation succeeded or not. For example if you DELETE resource, all the watchers also see a DELETE - not necessarily as requests for them to delete, but notifications of an event that occurred. And if someone tries to do a DELETE and is that is denied due to permissions, the watchers will see the response status code "403 Forbidden" (if you want to get that fine grained, or some criteria specifies to forward that stuff). Handy to be alerted about attempted security violations. Model your application as an information model and notifications directly become state change events that describe the resource, the operation and result status. Provide filtering based on all three and you have a very powerful, composable event system. WHERE uri="/mike/buddylist" and method="put" and status="success" WHERE uri="/mike/buddylist" and method="put" and status="denied" WHERE uri="/mike/buddylist" and method="get" and status="denied" > > If there are notification-related errors that we need to report then > there could be a header for them. In general, existing HTTP status codes > will not be appropriate. I disagree that existing status codes will not be appropriate. Any response to a client request should be echoed - in whole or in part - to the watchers (filtering and transformation aside). This keeps the burden on the server to a minimum.
Lucas Gonze wrote: > > ... > > I agree that avoiding out of band arrangements is a primary goal, but I believe > that WSDL already meets this need. Please let's not bring WSDL in! For one thing it works at a totally different logical level. For another thing its future is controlled by big companies and surrounded by hordes of patents. > ... In addition, this is metadata about an > application, not protocol-level functionality, so supporting it via special HTTP > headers etc violates opacity. I tihnk we should think of what we are doing as an extension to the protocol, not an application. A particular stock site is an application. The protocol should allow notifications on any kind of site (whether it be a stock site or otherwise). > Proposed solution: have a single out-of-band communication to specify how to > find the WSDL description. For example: > "The service provider MAY choose to have a file named watch_services.wsdl at > <some well known location>". If you're going to punt in this way, we might as well make it a binary file format because the WSDL will hide all of the details from the user anyway. > At least one incantation will have to be involved, because the service > description bootstraps the entire interaction. I don't need a service description to hook up a web browser to an HTTP web service like Google. I don't need a service description to hook up a WebDAV client like Office 2000 to a WebDAV server like Apache+mod_dav. A big part of standardization is figuring out what is common (e.g. the idea of notifications) and what is application-specific (e.g. notifications when a price goes beyond a limit). But you seem not to want to relegate anything to the common category. It's all application! Paul Prescod
"S. Mike Dierken" wrote: > >... > A notification is a message that describes a request/response pair - the > event that occurred. I guess that's where we disagree fundamentally. A notification is a message that something has changed. Nothing more, nothing less. In general, there is no request/response pair. When a message comes through an EDI backchannel that a stock price (or temperature) has changed, that is reflected in a series of notifications being sent. There is no request/response pair to echo. If this particular application thought that the details of the EDI message were important, then I guess that information could be sent in the BODY of the response. Similarly, if you feel strongly that request/response pairs should be sent to your clients then you could do that in a particular application. But I claim that the only responsibility of the underlying engine is to report that the resource has been changed or deleted. But in my mind, the logical model is just: "That resource you asked about changed or disappeared." What caused the change is, in general, not the business of the watchers and will more often than not be through non-HTTP means anyhow. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com> Sent: Tuesday, January 22, 2002 3:50 PM Subject: Re: [rest-discuss] response in request > "S. Mike Dierken" wrote: > > > >... > > A notification is a message that describes a request/response pair - the > > event that occurred. > > I guess that's where we disagree fundamentally. A notification is a > message that something has changed. Nothing more, nothing less. In > general, there is no request/response pair. When a message comes through > an EDI backchannel that a stock price (or temperature) has changed, that > is reflected in a series of notifications being sent. There is no > request/response pair to echo. When a message comes through saying that a temperature changed - that message is already a notification. When a message causes the temperature to change - that is a request, which might spawn notifications. The thing that originates the notification - what kinds of things would it want to say? It would say what resource was affected, how it was affected, possibly who affected it, etc. What structure and format of names/values would it use? > > If this particular application thought that the details of the EDI > message were important, then I guess that information could be sent in > the BODY of the response. Similarly, if you feel strongly that > request/response pairs should be sent to your clients then you could do > that in a particular application. But I claim that the only > responsibility of the underlying engine is to report that the resource > has been changed or deleted. I underlying engine should only report that the resource has been changed or deleted - I agree. But how does it say 'changed' or 'deleted'? I am saying since the resource is reflected as a URI - otherwise you couldn't subscribe to it - the notification should be cast in terms of URI modification operations, i.e. HTTP concepts. > But in my mind, the logical model is just: "That resource you asked > about changed or disappeared." What caused the change is, in general, > not the business of the watchers and will more often than not be through > non-HTTP means anyhow. I'm not talking about what caused the change, but the types of operations that the resources experience - such as create, read, update, delete and add/remove for collections. These resource manipulation operations are available via HTTP and communicating the fact that a resource changed should try to re-use those same concepts. I suppose you could define a new set of operations with the meaning 'this resource operation occurred' that are distince from 'perform this resource operation', but my position is that you don't have to have a distinct set, you just need to distinguish between 'request' and 'notify'.
"S. Mike Dierken" wrote: > >... > > When a message comes through saying that a temperature changed - that > message is already a notification. Okay, but maybe it is on a serial line from a thermometer. It isn't HTTP. > When a message causes the temperature to change - that is a request, which > might spawn notifications. It isn't necessarily an HTTP request. > The thing that originates the notification - what kinds of things would it > want to say? If it's a thermometer it won't say much. "Temperature changed. Temperature changed. Temperature changed." But then the HTTP system has to propogate this out through HTTP notificatoins. > It would say what resource was affected, how it was affected, possibly who > affected it, etc. Only the first is mandatory. You can figure out how it was affected (i.e. up or down and how many degrees) by doing a GET. It is probably not useful to report the GPS location of the termometer! > What structure and format of names/values would it use? I think that the only thing that must be standardized are the things that will be useful for most applications. So I would say that it needs to be able to report the location that changed. That's an HTTP header. Arguably it should also be able to deliver a representation of the change or the resource in a standarized way. If so, that's the HTTP body. Otherwise you invent your own body formats, maybe your own headers and you're off to the races. >... > I underlying engine should only report that the resource has been changed or > deleted - I agree. > But how does it say 'changed' or 'deleted'? I am saying since the resource > is reflected as a URI - otherwise you couldn't subscribe to it - the > notification should be cast in terms of URI modification operations, i.e. > HTTP concepts. How about: HTTP-event: POST HTTP-event: PUT HTTP-event: DELETE So a full notification might look like: POST /your.event.sync Target-URI: http://www.the.thing.you.were.watching HTTP-event: PUT (some proprietary body, or the resource itself if you asked for that) Paul Prescod
> > If it's a thermometer it won't say much. "Temperature changed. > Temperature changed. Temperature changed." If the gateway doesn't know the value of the temperature from the sensor, either it gets it right then in order to forward that as part of the notification, or the notification doesn't say the 'temperature' change, it says the 'status of thermometer' changed - the resource that changed isn't one that holds the value for 'temperature', which would imply two URIs. This is getting too complicated. Do you have any HTTP event systems to play with? Doing it with real working code is much much more educational. If you don't, go and grab KnowNow's event router and bang out some javascript listeners. If you are into Java servlets, check out http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it running somewhere public next week. mike
"S. Mike Dierken" wrote: > >... > If the gateway doesn't know the value of the temperature from the sensor, > either it gets it right then in order to forward that as part of the > notification, or the notification doesn't say the 'temperature' change, it > says the 'status of thermometer' changed - the resource that changed isn't > one that holds the value for 'temperature', which would imply two URIs. I am completely not following you. 1. Somehow a physical thermometer changes a byte in RAM or on disk and informs a piece of software that it has done so. 2. There is Web gateway software that exposes this byte as a resource: * http://www.weather.com/90210/temperature : "5" 3. The Web gateway software tells anyone who has registered to watch that URL that it has been changed. 4. If they want the new value, they can GET it. Or they could have registered that they want inline values earlier. The notification probably looks like this: POST www.mymicroserver.com/mysubscriptions/23123 Target-URI: http://www.weather.com/90210/temperature HTTP-method: PUT (maybe message body here, maybe not) 5. There is another URI. It *represents* the subscription. If the client just wants to let the subscription peter out, it can ignore that URI. If it wants to actively manage it then it needs to work with the subscription URI. > This is getting too complicated. > Do you have any HTTP event systems to play with? Doing it with real working > code is much much more educational. > > If you don't, go and grab KnowNow's event router and bang out some > javascript listeners. I can't see any connection point between what we've been talking about and what they have implemented. They have a "do_method" thingee that seems basically RPC-ish. The payload is a header? They have explicit event routing? It seems to be inherently peer-to-peer whereas HTTP's underlying model is client/server. Overall, it seems much more complicated than what I was thinking of. Most important, I can't figure out how to do what I want to do which is ask to be notified when a web resource changes its value. As far as I can tell, the "gateway" would have to publish to the "topic". Merely changing a resource is not sufficient to trigger a message. But maybe I misunderstand that part. > If you are into Java servlets, check out > http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it > running somewhere public next week. I'm not really sure that we should use a message queuing paradigm as a starting point. I think that an HTTP API for JMS would turn quite different than a notifications mechanism for the Web. Paul Prescod
On Tue, 22 Jan 2002, Jeff Bone wrote: > Subscription / notification is really a rather application-specific thing. It's > not clear to me that a generic subscription / notification mechanism justifies > polluting the method space rather than just coming up with some generic > conventions, nor is it clear that adding such a method will spur universal > development and interoperability of async HTTP applications. IMO, it's a losing > proposition all the way around, compared to other alternatives. Its hard to believe, but I find myself in raging agreement with Jeff here. A big reason why is the degree of control applications need over the meaning of change and the potential volume of data being transmitted. For example, an application subscribing to the current value of the S&P 500 index might not want to recieve an update on every trade of every stock in the S&P 500, but rather might prefer an update every minute during the trading day (and none when trading is not happening). Alternatively, suppose an application subscribes to a document enumerating the current value of every stock traded on the exchange. Repeatedly sending the URL of this page is much less useful than just sending the content of each trade. In theory one might define a generic notion of sparse (time based) notification, but I am not at all confident that it would cover all required application semantics. Moreover even if one could, I don't think you could then avoid having to specify the meaning of delta. As an aside, doesn't Chunk encoding also cover some of the application domain. i.e. open a connection to some URL and get streamed deltas as long as the connection is open. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> >... > > If the gateway doesn't know the value of the temperature from the sensor, > > either it gets it right then in order to forward that as part of the > > notification, or the notification doesn't say the 'temperature' change, it > > says the 'status of thermometer' changed - the resource that changed isn't > > one that holds the value for 'temperature', which would imply two URIs. > > I am completely not following you. Okay - my message was convoluted & wrong. What you say below is goodness. The identification of the resource that changed and the operation that occurred is what I like. I would also like status - in order to learn about attempted changes that didn't happen. > > 1. Somehow a physical thermometer changes a byte in RAM or on disk and > informs a piece of software that it has done so. > > 2. There is Web gateway software that exposes this byte as a resource: > > * http://www.weather.com/90210/temperature : "5" > > 3. The Web gateway software tells anyone who has registered to watch > that URL that it has been changed. > > 4. If they want the new value, they can GET it. Or they could have > registered that they want inline values earlier. The notification > probably looks like this: > > POST www.mymicroserver.com/mysubscriptions/23123 > Target-URI: http://www.weather.com/90210/temperature > HTTP-method: PUT > > (maybe message body here, maybe not) > > 5. There is another URI. It *represents* the subscription. If the > client just wants to let the subscription peter out, it can ignore that > URI. If it wants to actively manage it then it needs to work with the > subscription URI. > > > This is getting too complicated. > > Do you have any HTTP event systems to play with? Doing it with real working > > code is much much more educational. > > > > If you don't, go and grab KnowNow's event router and bang out some > > javascript listeners. > > I can't see any connection point between what we've been talking about > and what they have implemented. They have a "do_method" thingee that > seems basically RPC-ish. Hey now, I like that do_method thingee. (if they had any balls it would've been do:method) > The payload is a header? They have explicit > event routing? It seems to be inherently peer-to-peer whereas HTTP's > underlying model is client/server. Overall, it seems much more > complicated than what I was thinking of. Some things had to be sacrificed for browser accessibility. > > Most important, I can't figure out how to do what I want to do which is > ask to be notified when a web resource changes its value. As far as I > can tell, the "gateway" would have to publish to the "topic". Merely > changing a resource is not sufficient to trigger a message. But maybe I > misunderstand that part. Yes, the KN server is a message server, it hosts subscriptions and routes events. It is not a filter on existing servers. Somebody could write a mod_watch that did the same stuff and echoed actual HTTP requests (and their responses) If you have an application that knows about changes, but isn't directly URI addressable, you can use their stuff to bounce messages around rather than implementing your own subscription/notification system. Here's a sample message exchange -- create a subscription -- POST http://www.topiczero.com:8000/kn/prescod.net/temperature/ HTTP/1.1 Content-Type: application/x-www-form-url-encoded do_method=route &kn_to=http://www.prescod.net/receivers/temperature/ -- some time passes... -- -- post a notification -- POST http://www.topiczero.com:8000/kn/prescod.net/temperature/ HTTP/1.1 Content-Type: application/x-www-form-url-encoded kn_payload=98.6 -- here comes the message -- POST http://www.prescod.net/receivers/temperature/ HTTP/1.1 Content-Type: application/x-www-form-url-encoded kn_payload=98.6 &kn_id=uniqueMessageID &kn_time_t=979273892 &kn_route_id=some_more_useful_stuff > > > If you are into Java servlets, check out > > http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it > > running somewhere public next week. > > I'm not really sure that we should use a message queuing paradigm as a > starting point. I think that an HTTP API for JMS would turn quite > different than a notifications mechanism for the Web. Calling out 'jms' was just a ploy - I want that project to be an asynch HTTP service implemented as a servlet. That's one way to get it started - but I'll ensure RESTfulness as I go.
> As an aside, doesn't Chunk encoding also cover > some of the application domain. i.e. open a > connection to some URL and get streamed deltas as > long as the connection is open. Chunked just allows content to be sent without pre-computing Content-Length. It must be omitted. Each chunk has its own length, follwed by a zero-length chunk (or stuff like that). Each chunk does not represent the full content, only a range. You could do tricky things with it, like send deltas, but I wouldn't recommend it. (Unless you are writing a book on 'how to abuse HTTP for dummies').
On Tue, 22 Jan 2002, S. Mike Dierken wrote: > Each chunk does not represent the full content, only a range. You could do > tricky things with it, like send deltas, but I wouldn't recommend it. > (Unless you are writing a book on 'how to abuse HTTP for dummies'). This is no more abuse then sending requests as responses or vice-versa :-). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> On Tue, 22 Jan 2002, S. Mike Dierken wrote: > > Each chunk does not represent the full content, only a range. You could do > > tricky things with it, like send deltas, but I wouldn't recommend it. > > (Unless you are writing a book on 'how to abuse HTTP for dummies'). > > This is no more abuse then sending requests as > responses or vice-versa :-). > I respectfully disagree - sending requests as responses or vice versa is allowed if the content-type identifies it as such, and the URI behaves like a first-class web resource. Sending pieces via chunked encoding is okay of the resource identifies is a compound resource - a collection. For example, if you defined a content-type application/folder-contents (or something) and did a GET on a folder, sending the content of each file in that folder would be reasonable (from some point of view). Things that can go wrong with this is the sending of resources not via their URI - but since each resource can any any number of equivalent URIs I suppose that is okay.
> ----- Original Message ----- > From: "Mark Baker" <distobj@...> > > FWIW, we at PF struggled with this some time ago, but what we have now > is *lean*, I mean completely kick ass. It's a shame we're not even > releasing free binaries (nevermind source). It does everything you're > talking about here, but so much more. Cool - now that we know it is possible, we'll just built it open source. Thanks! ;)
> > On Tue, 22 Jan 2002, S. Mike Dierken wrote: > > > Each chunk does not represent the full content, only a range. You could > do > > > tricky things with it, like send deltas, but I wouldn't recommend it. > > > (Unless you are writing a book on 'how to abuse HTTP for dummies'). > > > > This is no more abuse then sending requests as > > responses or vice-versa :-). > > > I respectfully disagree - sending requests as responses or vice versa is > allowed if the content-type identifies it as such, and the URI behaves like > a first-class web resource. I think that opens up a huge pandora's box of issues. If it's "just another content type", then because the end-to-end model has to be respected, it's a kind of "mandatory" content type for intermediaries. It couldn't just be passed-through as most intermediaries do, it would have to be cracked open and processed on each hop. It's an interesting idea that could probably be specified, but I don't see a great need for it today, plus mandatory extensions haven't been deployed and this needs them. Maybe later. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Lucas Gonze" <lucas@...> Cc: <rest-discuss@yahoogroups.com> Sent: Tuesday, January 22, 2002 7:09 AM Subject: Re: [rest-discuss] Indicating Notifications in HTTP > > > > If so, the header there works quite differently > > > than just "Reply-To". > > > > Explain? > > Just like I said here; > > http://groups.yahoo.com/group/rest-discuss/message/47 > > The active header is "Properties" (from DAV), plus the extension is > really the "watch" modifier of it that says we're looking at the > watch property. > Ooh, I like this. Modeling a 'property' as a collection that is URI addressable. Using POST to 'add' to a collection (is that create+insert or just insert?). But how do people know that 'properties' is a name (in the response headers) to use? Is defined by DAV or something? How do people know ";name" is the format of URIs? Have you figured out the opacity issues? Given that the technology of the day (.asp .jsp) doesn't allow for 'extra path info' you will see urls for properties like: http://www.clewless.com/monitors/subs.asp?customer=27 Try appending ";subscriptions" on the end of that. Might need multiple response headers or a single multi-valued header.
> Cool - now that we know it is possible, we'll just built it open source. > Thanks! ;) I'm just giving away the basics. We've got a lot of value-add on top that is specific for solving wireless integration issues. We also have another router that isn't pub/sub, it just does forward and reverse static routes. It's actually our most mature product because we started out with it. The pub/sub router was an afterthought, but it's now well integrated into our product line. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Mark Baker" <distobj@...> > > Mark Baker wrote: > > > > > Absolutely. Me thinks Jeff is straying from the opacity "axiom". > > > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a > > particular application domain, > > It means just that. As soon as you assign any meaning to a URI, then > only those privy to that meaning are in on your little secrets (like > appending "/subs" means "subscribers to the URI before /subs"). > Interoperability means sacrificing private convention for public > specification. So you make the URI-to-URI relationship explicit with > a statement, such as is done with an HTTP header or an RDF statement, > etc.. > That statement (the name and location of the information) is still a little secret that only those in the know. However, it may be better to move that out of the URI, and also do something to ensure backward compatibility - like defining these as 'advisory' and optional. These turns the http response into a multi-link (or something - Paul, help me out here) with named references to interesting sub-properities of the resource. If those sub-properties are addressable, they are also probably subscribable. So a DAV Properties: specified URI should be listenable for just property (not content) changes. If an HTTP WATCH method were to be used, would OPTIONS return that fact? Does it operate per resource? (ignoring the extra requests to figure stuff out)
----- Original Message ----- From: "Mark Baker" <distobj@...> To: "S. Mike Dierken" <mdierken@...> Cc: "S. Alexander Jacobson" <alex@...>; <rest-discuss@yahoogroups.com> Sent: Wednesday, January 23, 2002 9:29 AM Subject: Re: [rest-discuss] Indicating Notifications in HTTP > > > > > I respectfully disagree - sending requests as responses or vice versa is > > allowed if the content-type identifies it as such, and the URI behaves like > > a first-class web resource. > > I think that opens up a huge pandora's box of issues. > > If it's "just another content type", then because the end-to-end model > has to be respected, it's a kind of "mandatory" content type for > intermediaries. It couldn't just be passed-through as most > intermediaries do, it would have to be cracked open and processed > on each hop. I think I understand - since the requests and responses are the way intermediaries understand the resource system (the Web) and maintain useful state about them (deleted, created, etc.) if the requests and responses aren't right there at the top, then they would pass through intermediaries, but the intermediaries would be blind to the information and not able to currently reflect the state of the resourc system (no cache updates, etc.) I hadn't gone to that extent, and while I agree with you, I'm more interested in providing functionality to firewalled nodes than in preserving the public state of the resource system, mainly because I don't think the resources are that public, and also the traffic probably would pass through a special gateway and beyond that the requests & responses would be at the top of the stream.
Ok. I'll bite. Just for fun: If I want to use chunked encoding to send a stockmarket feed, then the chunks are just individual trades over the course of the duration the stream is fed. The document content-type would be something like application/x-stock-trades. This is perfectly HTTP legal and not very abusive because the client has no way to tell if sending delays are caused by network congestion, server load, or actually waiting for the trades to complete. OTOH, sending a HTTP reply in a request begs all sorts of questions about error handling, response structure, proxies, etc. -Alex- On Wed, 23 Jan 2002, S. Mike Dierken wrote: > > > On Tue, 22 Jan 2002, S. Mike Dierken wrote: > > > Each chunk does not represent the full content, only a range. You could > do > > > tricky things with it, like send deltas, but I wouldn't recommend it. > > > (Unless you are writing a book on 'how to abuse HTTP for dummies'). > > > > This is no more abuse then sending requests as > > responses or vice-versa :-). > > > I respectfully disagree - sending requests as responses or vice versa is > allowed if the content-type identifies it as such, and the URI behaves like > a first-class web resource. > Sending pieces via chunked encoding is okay of the resource identifies is a > compound resource - a collection. For example, if you defined a content-type > application/folder-contents (or something) and did a GET on a folder, > sending the content of each file in that folder would be reasonable (from > some point of view). Things that can go wrong with this is the sending of > resources not via their URI - but since each resource can any any number of > equivalent URIs I suppose that is okay. > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> I hadn't gone to that extent, and while I agree with you, I'm more > interested in providing functionality to firewalled nodes than in preserving > the public state of the resource system, mainly because I don't think the > resources are that public, and also the traffic probably would pass through > a special gateway and beyond that the requests & responses would be at the > top of the stream. Ok, but that is not really HTTP anymore. It is something else entirely. You probably want to use MIME-RPC which makes this all fairly straightforward (and can be carried over HTTP). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > On Tue, 22 Jan 2002, Jeff Bone wrote: > > Subscription / notification is really a rather application-specific thing. It's > > not clear to me that a generic subscription / notification mechanism justifies > > polluting the method space rather than just coming up with some generic > > conventions, nor is it clear that adding such a method will spur universal > > development and interoperability of async HTTP applications. IMO, it's a losing > > proposition all the way around, compared to other alternatives. > > Its hard to believe, but I find myself in raging > agreement with Jeff here. A big reason why is > the degree of control applications need over the > meaning of change and the potential volume of data > being transmitted. I agree that there must be a way for applications to implement filtering. I don't think that means that the basic behaviour cannot be standardized. When I "PUT" a purchase order, the HTTP spec. doesn't tell me what I should do once I get it. The basic model is that the thing is available like a file for subsequent GETs. But a particular application could do much more sophisticated stuff. Also, how do I "filter" Google when I do a search? It doesn't return the whole Google database, right? There are an essentially infinite number or URIs available. So what if you use query parameters to say that the resource you want to watch is one that only changes every fifteen minutes, or only changes when a price goes beyond a particular value. Paul Prescod
> Ooh, I like this. Modeling a 'property' as a collection that is URI > addressable. Using POST to 'add' to a collection (is that create+insert or > just insert?). > But how do people know that 'properties' is a name (in the response headers) > to use? Is defined by DAV or something? Yep. > How do people know ";name" is the format of URIs? Have you figured out the > opacity issues? It's on my todo list. I haven't figured out ";" yet though, but when I do I'll write up all my findings on "?" and "/". Roy used that notation first. It suggests to me that its meaning can have a wider scope than just the URI to which it's appended. If so, that's pretty darned useful, though less opaque (which is ok, as long as its interpretation is uniform). It appears to work like a HTTP header. But it is not itself a URI, so perhaps a registry is needed, or we can figure out a way of making it a URI. > Given that the technology of the day (.asp .jsp) doesn't allow for 'extra > path info' you will see urls for properties like: > http://www.clewless.com/monitors/subs.asp?customer=27 > > Try appending ";subscriptions" on the end of that. I've heard that deployed URI support is actually pretty good, except maybe in some funky cases like http://foo.com/bar;q?a=b MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> I think I understand - since the requests and responses are the way > intermediaries understand the resource system (the Web) and maintain useful > state about them (deleted, created, etc.) if the requests and responses > aren't right there at the top, then they would pass through intermediaries, > but the intermediaries would be blind to the information and not able to > currently reflect the state of the resourc system (no cache updates, etc.) Right. > I hadn't gone to that extent, and while I agree with you, I'm more > interested in providing functionality to firewalled nodes than in preserving > the public state of the resource system, mainly because I don't think the > resources are that public, and also the traffic probably would pass through > a special gateway and beyond that the requests & responses would be at the > top of the stream. If you're going to do that, you at least need a gateway that can terminate the HTTP chain so that end-to-end behaviour is guaranteed (i.e. move the "end" in 8-). Just recognize that you're doing this, and don't try to pretend that you're doing HTTP behind the gateway or that will just cause more trouble. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > Ok. I'll bite. Just for fun: > If I want to use chunked encoding to send a > stockmarket feed, then the chunks are just > individual trades over the course of the duration > the stream is fed. The document content-type > would be something like > application/x-stock-trades. > > This is perfectly HTTP legal and not very abusive > because the client has no way to tell if sending > delays are caused by network congestion, server > load, or actually waiting for the trades to > complete. That is true. If the content type and resource is modeled as a collection of trades, it looks fine to me (not that I'm any judge...). And if the resource is modelled as a collection of messages - like a message queue - the same thing applies (using chunked transfer encoding is a nice optimization in this case). Thats what the Destiny project on SourceForge does - keeps returning messages from the collection (the queue). > > OTOH, sending a HTTP reply in a request begs all > sorts of questions about error handling, response > structure, proxies, etc. > Cool. My stuff is more abusive than yours - I'll write the book then. ;) I agree that tunnelling has more http level problems than long-lived responses. I just think it is useful for firewalled systems.
----- Original Message ----- From: "Mark Baker" <distobj@...> > > > I hadn't gone to that extent, and while I agree with you, I'm more > > interested in providing functionality to firewalled nodes than in preserving > > the public state of the resource system, mainly because I don't think the > > resources are that public, and also the traffic probably would pass through > > a special gateway and beyond that the requests & responses would be at the > > top of the stream. > > If you're going to do that, you at least need a gateway that can > terminate the HTTP chain so that end-to-end behaviour is guaranteed > (i.e. move the "end" in 8-). Just recognize that you're doing this, > and don't try to pretend that you're doing HTTP behind the gateway > or that will just cause more trouble. > If I wanted to model the resource system as an addressable collection of messages, what would the HTTP requests and responses look like? Especially if those messages were literally HTTP request and response formats? Like blindly logging all web server activity and having an analysis program consume those from disk via HTTP.
> > Given that the technology of the day (.asp .jsp) doesn't allow for 'extra > > path info' you will see urls for properties like: > > http://www.clewless.com/monitors/subs.asp?customer=27 > > > > Try appending ";subscriptions" on the end of that. > > I've heard that deployed URI support is actually pretty good, except > maybe in some funky cases like http://foo.com/bar;q?a=b > What do you mean by 'deployed URI support'? Is the ';' a special character in URI that is meant to be dealt with by clients parsing URIs?
> > I've heard that deployed URI support is actually pretty good, except > > maybe in some funky cases like http://foo.com/bar;q?a=b > > > > What do you mean by 'deployed URI support'? Just what's out there in browsers, servers, URI parsing libraries, etc.. > Is the ';' a special character in URI that is meant to be dealt with by > clients parsing URIs? Yep. See RFC 2396. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote:
> > Mark Baker wrote:
> >
> > > Absolutely. Me thinks Jeff is straying from the opacity "axiom".
> >
> > IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> > particular application domain,
>
> It means just that.
Come on. That's nice in theory, but it's just neither true nor desirable in
practice. URI *always* (and should!) have some associated semantics in the
higher-level application domain in question. For example, in the following:
http://www.amazon.com/exec/obidos/ASIN/0674000781/
the part following ASIN/ has the semantics "an ISBN." Note that I'm not claiming
that Amazon exposes a particularly RESTful resource model, just that modeling
books as resources identified in some collection via ISBNs does not by itself
violate opacity or break REST. A better resource model might be:
http://www.amazon.com/books/ISBNs/0674000781
The opacity axiom simply says that the underlying application --- HTTP ---
shouldn't ever have to know anything about books. It doesn't say that a
bookselling application shouldn't model and expose those abstractions through the
URI space. Indeed, doing so is a RESTful thing, isn't it? It also doesn't say
that a set of book-oriented applications from various developers should not or
could not agree on a conventional method of modeling books, collections of books,
etc. as resources.
> As soon as you assign any meaning to a URI, then
> only those privy to that meaning are in on your little secrets (like
> appending "/subs" means "subscribers to the URI before /subs").
And this is just fine for "applications" that don't live at the same level of
generalization as HTTP. The issue at hand is whether "events", pub / sub,
notifications, etc. constitute a (or several) higher abstraction / application
domain(s) like "book-oriented applications" (perhaps lower level than that, but
higher level than HTTP per se) or whether they belong at the level of generality
of HTTP. My argument is that they belong at a higher level, for several reasons:
(1) Use of event notification differs from app domain to app domain
(2) It's difficult IMO to provide useful notification generalizations
(3) The higher levels of abstraction are more "fungible" in some sense
tentative (4) In general we should be reluctant to extend rather than just use
HTTP as-is
> It means that too, though even the query string has limits - it's not
> fully transparent. For example, you shouldn't have to know some secret
> query parameter a priori in order to accomplish something.
This is another assertion that is meaningful in a philosophical sense but not in
practical application. It depends on what it is you want to accomplish. For
example, of course I'm going to need to know a secret (parameter names or order,
etc.) to accomplish something useful in a particular domain --- such as querying a
search engine.
Bottom line, opacity doesn't IMO literally say that URI shouldn't have semantics
*at all.* It says that those semantics belong outside the realm of HTTP and URI
as such, and rather belong to and should be interpreted in the context of some
application domain. Defining that context shared by applications in a given
domain is the purview of the developers of those applications, and that context
--- its resource models, conventions, etc. --- do indeed constititute a "shared
secret" among the producers and consumers of the functionality in question. This
doesn't break interface generality either; it just recognizes that there's an
irreducible amount of functionality that should be exposed, and leaves it up to
the developer to expose that by leveraging and without breaking the semantics of
HTTP.
That's my current working hypothesis, anyway. Open to revision.
> It's on my
> todo list to write up my opacity investigation, btw.
Looking forward to it.
jb
Jeff Bone wrote: > >... > > The opacity axiom simply says that the underlying application --- HTTP --- > shouldn't ever have to know anything about books. It doesn't say that a > bookselling application shouldn't model and expose those abstractions through the > URI space. Indeed, doing so is a RESTful thing, isn't it? Agree. > ... It also doesn't say > that a set of book-oriented applications from various developers should not or > could not agree on a conventional method of modeling books, collections of books, > etc. as resources. They can agree on the modelling, if it makes them feel good. But they should not standardize it in software. If they want to be able to go (let's say) from a book's page to it's author's page, software should not blindly add /author. Rather it should look for an <author>...</author> XML tag. That allows the person maintaining the site to move author elements to a totally different site if they decide that is better. They update all of their <author>...</author> tags and they are done. Consider if the original web had said that after you are done with a form it is automatically POSTed to the original URI + /process_form. It would have seemed fine at the time but then later when people wanted to make little form fields that search Google, they wouldn't have been able to. Paul Prescod
> > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a > > > particular application domain, > > > > It means just that. > > Come on. That's nice in theory, but it's just neither true nor desirable in > practice. URI *always* (and should!) have some associated semantics in the > higher-level application domain in question. For example, in the following: > > http://www.amazon.com/exec/obidos/ASIN/0674000781/ > > the part following ASIN/ has the semantics "an ISBN." Note that I'm not claiming > that Amazon exposes a particularly RESTful resource model, just that modeling > books as resources identified in some collection via ISBNs does not by itself > violate opacity or break REST. A better resource model might be: > > http://www.amazon.com/books/ISBNs/0674000781 > > The opacity axiom simply says that the underlying application --- HTTP --- > shouldn't ever have to know anything about books. It doesn't say that a > bookselling application shouldn't model and expose those abstractions through the > URI space. Indeed, doing so is a RESTful thing, isn't it? It also doesn't say > that a set of book-oriented applications from various developers should not or > could not agree on a conventional method of modeling books, collections of books, > etc. as resources. Hmm, maybe I was unclear on what you meant by "application domain". Obviously each resource publisher can have their own conventions. What I thought you were saying was that Amazon and B&N had to have similar looking URIs. That would be a Bad Thing. > > As soon as you assign any meaning to a URI, then > > only those privy to that meaning are in on your little secrets (like > > appending "/subs" means "subscribers to the URI before /subs"). > > And this is just fine for "applications" that don't live at the same level of > generalization as HTTP. The issue at hand is whether "events", pub / sub, > notifications, etc. constitute a (or several) higher abstraction / application > domain(s) like "book-oriented applications" (perhaps lower level than that, but > higher level than HTTP per se) or whether they belong at the level of generality > of HTTP. My argument is that they belong at a higher level, for several reasons: > > (1) Use of event notification differs from app domain to app domain Just like how retrieving a picture of a book is different than retrieving an HTML page of me? 8-) > (2) It's difficult IMO to provide useful notification generalizations > (3) The higher levels of abstraction are more "fungible" in some sense > tentative (4) In general we should be reluctant to extend rather than just use > HTTP as-is Or just make sure "WATCH" is as generic as GET. Uh oh, I've said too much. 8-) > Bottom line, opacity doesn't IMO literally say that URI shouldn't have semantics > *at all.* It says that those semantics belong outside the realm of HTTP and URI > as such, and rather belong to and should be interpreted in the context of some > application domain. I couldn't disagree more. URIs should be as opaque as possible, so that any information about them and their relationships can be made explicit within the HTTP application model. If I can't do a GET on a URI to find out about its relationships with other resources, then that information isn't on the Web, and that's naughty. > That's my current working hypothesis, anyway. Open to revision. Good to hear. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > On Tue, 22 Jan 2002, S. Mike Dierken wrote: > > Each chunk does not represent the full content, only a range. You could do > > tricky things with it, like send deltas, but I wouldn't recommend it. > > (Unless you are writing a book on 'how to abuse HTTP for dummies'). Or "How to Abuse HTTP for Fun and Profit." One of those books on the list of "if I ever get around to it..." ;-) Akshully, Mike, weren't we talking about that at one point? jb
> > They can agree on the modelling, if it makes them feel good. But they > should not standardize it in software. If they want to be able to go > (let's say) from a book's page to it's author's page, software should > not blindly add /author. Rather it should look for an > <author>...</author> XML tag. That allows the person maintaining the > site to move author elements to a totally different site if they decide > that is better. They update all of their <author>...</author> tags and > they are done. Where <author> is a named property and its value is a reference (whose value space is the URI space)? Providing these 'named backpointers' is good - lets address de-referencing to be changed locally. There is still coordination between parties, but only on names and semantics of properties (and their location) and not syntax (references remain opaque). It can be problematic to provide these backpointers when also carrying other content in a response - not that a header won't work, but that some clients can't get to it. What do you guys think?
http://www.prescod.net/HTTP_event_conventions.html I wrote this up in a rush so it isn't 100% coherent but it's a starting place for what I've been thinking about. It addresses many of the concerns that people have raised in one message or another. Mike B: It can watch any resource. Mike D: Notifications must say what kind of action happened. Jeff B: Any notification syntax is allowed. Query-like triggers can be handled (as they are on today's web) through POST parameters. Lucas: Limited support for working with environments where you do not control headers. Alex: It uses MIME. ;) It's about a million miles from being complete but in my mind it has a certain coherence and elegance. Now I've got to try and do real work for a few days... Paul Prescod
Paul Prescod wrote: > http://www.prescod.net/HTTP_event_conventions.html This is actually really good as a starting point. Only a few changes and this could IMO fully describe what I've in the past called "the switchboard pattern" for handling not only asynchrony but also asymmetry of connectivity for general HTTP communication. If it won't step on your toes, Paul, I'm willing to take the pen and make a rev of this. > Now I've got to try and do real work for a few days... I tried to do that over the last 24 hours, and look what happened... ;-) jb
> Or "How to Abuse HTTP for Fun and Profit." One of those books on the list of > "if I ever get around to it..." ;-) Akshully, Mike, weren't we talking about > that at one point? yep - look like i've got a good one for abusing the messaging characterstics. Using chunked encoding to do streaming audio or video might be another - but that's probably what its meant for so we'd have to do something weird on top of it.
Er...couldn't we discuss your changes before putting them right in the spec? Oh damn. I'm not supposed to do any more talking. Okay, go ahead...but be gentle. It's just a baby spec. Jeff Bone wrote: > > Paul Prescod wrote: > > > http://www.prescod.net/HTTP_event_conventions.html > > This is actually really good as a starting point. Only a few changes and > this could IMO fully describe what I've in the past called "the switchboard > pattern" for handling not only asynchrony but also asymmetry of connectivity > for general HTTP communication. If it won't step on your toes, Paul, I'm > willing to take the pen and make a rev of this. > > > Now I've got to try and do real work for a few days... > > I tried to do that over the last 24 hours, and look what happened... ;-) > > jb
Some comments; "X-Event-Subscription". How about just "Subscriptions", since that better describes it's role; a container for subscriptions. If the Location header on a subscription response is a MAY, how does one unsubscribe? Should also mention use of 200/201/204 response codes on a POST action here too. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Nifty. I'd like to see one for detailing 'best practices' for "202 Accepted" - but I just don't have the time right now... All in all this is a really wonderful wrap up of where we are at today! Who is ready to start coding? If you are Java friendly, I'd like to suggest starting with http://www.sourceforge.com/projects/destiny - I know it talks about JMS, but it's more important that it is an HTTP messaging server. --- Some comments: 1 "The response to the Subscription MAY include a Location..." Do you mean: "The response to [creating] the subscription..." 2 "Event: (CHANGED|EXTENDED|DELETED|ADDED|(or application defined)) " I strongly think these should be based on create, read, update, delete [operations on atomic information] and add and remove [operations on collections]. There should be a map to what HTTP methods typically would generate (as you've indicated in the document). I've spent a lot of time thinking about this one and would like to continue discussions on this point. I also believe 'user defined' is to be avoided in the same way that new methods in http are to be avoided. If it comes to a problem with flexibility describing the change to the resource - I highly recommend using 'sub-properties' in the same sense as pointed out by MarkB relating to the ";" in urls. This 'sub-property' is controlled by the resource, but not necessarily independently addressable. If it were addressable, then it would be subscribable, and those subscriptions would receive the event. For example, listening to a users online status might be: Target-URI: http://www.topiczero.com:8000/kn/who/dierken.com/mike/ Property: presence Operation: update 3 "some form of "difference" may suffice " Content negotiation is goodness. Personally, I'd avoid 'delta' events, due to problems with often needing guaranteed delivery and sequence. Sending temperature as "up:3" isn't as good as "98". But I understand that sometimes deltas are okay. 4 "the Event Sink may email notifications " You will probably want user-agent metadata on the subscription (what user-agent, what content-type, and what form of content-type (like different approaches to html mail)). Something for the future, but make sure there is room later. 5 "may define a convention for using query parameters..." Yay! I realize this is a short-term hack for backward compatibility - but you gotta do what you gotta do... 6 "HTTP-equiv could also be used " Nifty. 7 "browser would ask the user" This would probably (d)evolve into HTML in the same way that HTTP authentication evolved into custom HTML forms for logging in. Don't underestimate the power of the marketing side.
----- Original Message ----- From: "Mark Baker" <distobj@...> > Some comments; > > "X-Event-Subscription". How about just "Subscriptions", since > that better describes it's role; a container for subscriptions. > > If the Location header on a subscription response is a MAY, how does > one unsubscribe? Should also mention use of 200/201/204 response > codes on a POST action here too. > Look at the bottom of your email: > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri' b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri'
On Wed, 23 Jan 2002, Paul Prescod wrote: > Also, how do I "filter" Google when I do a search? It doesn't return the > whole Google database, right? There are an essentially infinite number > or URIs available. So what if you use query parameters to say that the > resource you want to watch is one that only changes every fifteen > minutes, or only changes when a price goes beyond a particular value. The difference is that I can use both TCP/IP flow control and connection termination to prevent myself from being choked if Google did choose to send its whole database. In the case of asynch, the notification URL is at risk of being DOSed by an overwhelming number of requests. More generally, it feels like many things are sort of generic but not generic enough. e.g. expiration on time/volume/price the content of notification (the diff may be smaller than the URL) send every x minutes only if changed etc. I read your proposal and it looks nice. I just don't know how much application domain it really covers. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul Prescod wrote: > Er...couldn't we discuss your changes before putting them right in the > spec? Sorry, I wasn't implying that I'm highjacking the content. I was just offering to do a style / clarity / consistency / completeness pass to push it along while you get some work done. :-) It can always be tossed. I think substantial extensions to realize e.g. the full switchboard pattern can wait. > Oh damn. I'm not supposed to do any more talking. Okay, go > ahead...but be gentle. It's just a baby spec. 'Natch. :-) jb
Dont check a mailbox for two days and look what happens... 128
messages? argh.
On Wed, Jan 23, 2002 at 01:08:36PM -0500, Mark Baker wrote:
> > How do people know ";name" is the format of URIs? Have you
> > figured out the opacity issues?
>
> It's on my todo list. I haven't figured out ";" yet though, but
> when I do I'll write up all my findings on "?" and "/".
Would like to see those...
> Roy used that notation first. It suggests to me that its meaning
> can have a wider scope than just the URI to which it's appended.
> If so, that's pretty darned useful, though less opaque (which is
> ok, as long as its interpretation is uniform). It appears to work
> like a HTTP header. But it is not itself a URI, so perhaps a
> registry is needed, or we can figure out a way of making it a URI.
Do you have any references for these uses? I was under the impression
that parameters were just as opaque as any other URI component;
servers certainly seem to treat them as such. IIRC they were
originally introduced to enable VMS files (with versions) to be
easily URIified.
> I've heard that deployed URI support is actually pretty good, except
> maybe in some funky cases like http://foo.com/bar;q?a=b
Python's urlparse is broken; it assumes that you can only
parameterise the last path segment, not every path segment. As a
result,
http://www.example.com/foo;bar/baz?bat
gets parsed as
('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')
--
Mark Nottingham
http://www.mnot.net/
You should take a look at WEBI[1][2]; with a bit of work with an eye to the audience/requirements[3], this could easily be a candidate (connectivity monitoring is the only thing that really stands out, at first glance). I'd very much encourage you to consider this; if someone's interested, please drop me a line. [1] http://www.mnot.net/papers/ietf-49-wrec.pdf [2] http://www.ietf.org/html.charters/webi-charter.html [3] http://www.ietf.org/internet-drafts/draft-ietf-webi-rup-reqs-02.txt On Wed, Jan 23, 2002 at 12:52:38PM -0800, Paul Prescod wrote: > http://www.prescod.net/HTTP_event_conventions.html > > I wrote this up in a rush so it isn't 100% coherent but it's a starting > place for what I've been thinking about. It addresses many of the > concerns that people have raised in one message or another. > > Mike B: It can watch any resource. > > Mike D: Notifications must say what kind of action happened. > > Jeff B: Any notification syntax is allowed. Query-like triggers can be > handled (as they are on today's web) through POST parameters. > > Lucas: Limited support for working with environments where you do not > control headers. > > Alex: It uses MIME. ;) > > It's about a million miles from being complete but in my mind it has a > certain coherence and elegance. > > Now I've got to try and do real work for a few days... > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
> Look at the bottom of your email: > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri' > b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri' Yah, but a) isn't good container based design, because their states are entangled; a POST in one effects a delete in the other. b) is the proper way to do it. Hence the need for at least a SHOULD on the Location header. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > Yah, but a) isn't good container based design, because their states are > entangled; a POST in one effects a delete in the other. b) is the > proper way to do it. Hence the need for at least a SHOULD on the > Location header. Agreed. I was trying to lower the bar for minimal implementations. I think that Mike's idea of an unsub URI might not be a terrible fallback for if software doesn't support DELETE. Paul Prescod
> > Roy used that notation first. It suggests to me that its meaning
> > can have a wider scope than just the URI to which it's appended.
> > If so, that's pretty darned useful, though less opaque (which is
> > ok, as long as its interpretation is uniform). It appears to work
> > like a HTTP header. But it is not itself a URI, so perhaps a
> > registry is needed, or we can figure out a way of making it a URI.
>
> Do you have any references for these uses? I was under the impression
> that parameters were just as opaque as any other URI component;
> servers certainly seem to treat them as such. IIRC they were
> originally introduced to enable VMS files (with versions) to be
> easily URIified.
I was just extrapolating from Roy's example. He's a good reference. 8-)
I'll check out 2396 on the issue later (oh my, is my todo list ever
getting big!).
> > I've heard that deployed URI support is actually pretty good, except
> > maybe in some funky cases like http://foo.com/bar;q?a=b
>
> Python's urlparse is broken; it assumes that you can only
> parameterise the last path segment, not every path segment. As a
> result,
> http://www.example.com/foo;bar/baz?bat
> gets parsed as
> ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')
Yah, I heard that urlparse was quite bad, but I take it that it's an
exception.
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Paul Prescod" <paul@...> > >... > > > > Yah, but a) isn't good container based design, because their states are > > entangled; a POST in one effects a delete in the other. b) is the > > proper way to do it. Hence the need for at least a SHOULD on the > > Location header. > > Agreed. I was trying to lower the bar for minimal implementations. I > think that Mike's idea of an unsub URI might not be a terrible fallback > for if software doesn't support DELETE. > It's not really my idea - just pointing out a common way its done in todays world.
Maybe of interest to you: http://www.prescod.net/reliable_http.html Comments are welcome. Paul Prescod
(This has been said by other people in other places, probably better than I, but here goes anyway...) I've been going over the discussions about the asynchronous capabilities of HTTP and what to do about the missing pieces and have some discomforting thoughts. We all know what it means when we say 'pub/sub' and 'notification' or request and response or messaging, but when we say "And now for the HTTP..." we all disagree. Here we are, a bunch of bright experienced technology people, and there is no obvious way to map a known concept like pub/sub into HTTP. It's a grab bag of methods, uri, headers, content, query terms, uri 'parameters' (where did those come from?), and so on. "Get any little piece wrong", we say to ourselves, "and kiss interoperability and scalability goodbye". Sure, there may be a 'good' way of doing it, but there is no clear right or wrong and multiple independent attempts will arrive at different results. I don't think it is just that we are unfamiliar with HTTP, or even that we are unfamiliar with the concepts of ReST, but I think trying to take a model (pub/sub or rdbms or whatever) map it to another model (ReST) and at the same time map it to a 'wire format' - something gets lost in the translation. I don't see a trend for web applications converging on common approaches of using HTTP for a lot of cases, because most web applications talk to themselves - the only interoperation is through a link and a GET. They can put data in any slot without breaking anything because they wrote both the client and the server. Look at the many ways of doing user login - almost none of them use HTTP security constructs - and things still work. Through the discussion on this form I've learned a /lot/ about designing with HTTP. There may be compromises to that design to work with existing infrastructure (browsers, asp/jsp, etc.), as well as further compromises to achieve some measure of end-user usability, but I'm happy with what I've learned. Something that would help me in the future is to model a large information-centric applications (including security and events) and create a direct mapping into URIs and HTTP. If anybody has any thoughts or experience with this, give me a shout. (The kind of thing I'm thinking about is like an 'object oriented web' but 'OO' isn't appropriate. Components and interfaces are closer. Entity-relationship from rdbms and OMT/UML notation is closer still.) Mike
----- Original Message ----- From: "Mark Baker" <distobj@...> > > Look at the bottom of your email: > > > > > To unsubscribe from this group, send an email to: > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri' > > b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri' > > Yah, but a) isn't good container based design, because their states are > entangled; a POST in one effects a delete in the other. b) is the > proper way to do it. Hence the need for at least a SHOULD on the > Location header. > (btw 'Entangled' is a great term). I like the 'collection/container' based approach also, but was just pointing out a common alternative. I had a thought - your 'good container design' comment about a) mentions that a post in one causes a delete in the other. Does this imply that a resource that is a collection must/should be disjoint from all other addressable collections? Does this imply aliases are to be avoided? If aliases or overlapping collections exist, and events are to be routed, an event in one would/should cause an event in the other(s)? If something is addressable, it is subscribable. If aliases exist, multiple subscriptions via the aliases and there should not be one 'preferred' alias. Also, regarding uri 'parameters' (which I have not read up on, so correct any and all misconceptions) - if these are unique identifiers yet guaranteed to informationally subordinate to the non-parameterized uri, then you have what appears to be an overlapping collection - with the 'parent' resource channeling events for the 'sub-properties'. The sub-properties may be available for fine-grained subscriptions (mini-filters) and the main resource is avialable for catch-all subscriptions. A bit stream-of-unconciousness, but I hope that made sense.
More comments:
8) Status
If a notification of an event is 'about' a resource, you may want to know
about attempted operations that failed.
The HTTP status codes do a good job of categorizing things (client error,
server error, security, etc.)
9) lifetime
Events are about the lifecycle of resources, and you may want to know about
a resource before it is created and after it is deleted. In a class and
instance based system, you could create a subscription that was interested
in a 'type' of instance being created ('tell me when a new purchase order is
created'). In a purely instance based system (like the web) you typically
use containers to represent that ('tell me when a new resource is added to
'pending purchase orders'). The resource 'pending purchase orders' might
only support events and not enumeration.
When a resource is deleted, the uri is still valid and usable - a saving
grace of the web - so that isn't a problem. I've worked with db systems that
used referential integrity and 'referencing' delete entities was a 'bit' of
a problem.
2b) More 'operation' stuff
If there is a concept of 'add' or 'added', then there is concept of
collection - another fuzzy area of the Web. I commonly use a model that
supports collections in a nice way - resources have named properties,
properties can be an atomic value or a collection. These named properties
(atomic or collection) are subscribable (which implies referenceable), but
not directly addressable (retrievable?). The operations of 'add/remove'
would apply to these collection properties, and 'update' would apply to the
atomic properties. Subscriptions on the resource imply a subscription on all
sub-properties as well. I've also allowed a subscription to indicate
multiple operations, but on the Web I'd be okay with one per subscription
(otherwise you get into managing a collection of criteria... but maybe a
subscription uri with a ";criteria" parameter would work...).
For example:
WATCH http://www.topiczero.com:8000/kn/who/prescod.net/paul;presence
HTTP/1.1
ReplyTo: http://nomad.dierken.com/followme/instantmsg.cgi
Accept: text/xml
WATCH http://www.topiczero.com:8000/kn/who/dierken.com/mike;buddies HTTP/1.1
ReplyTo: http://nomad.dierken.com/followme/instantmsg.cgi
Accept: text/xml
----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "Paul Prescod" <paul@...>
Sent: Wednesday, January 23, 2002 2:23 PM
Subject: Re: [rest-discuss] HTTP Event Conventions
>
> Nifty. I'd like to see one for detailing 'best practices' for "202
> Accepted" - but I just don't have the time right now...
>
> All in all this is a really wonderful wrap up of where we are at today!
> Who is ready to start coding? If you are Java friendly, I'd like to
suggest
> starting with http://www.sourceforge.com/projects/destiny - I know it
talks
> about JMS, but it's more important that it is an HTTP messaging server.
>
> ---
>
> Some comments:
>
> 1 "The response to the Subscription MAY include a Location..."
> Do you mean: "The response to [creating] the subscription..."
>
> 2 "Event: (CHANGED|EXTENDED|DELETED|ADDED|(or application defined)) "
> I strongly think these should be based on create, read, update, delete
> [operations on atomic information] and add and remove [operations on
> collections]. There should be a map to what HTTP methods typically would
> generate (as you've indicated in the document). I've spent a lot of time
> thinking about this one and would like to continue discussions on this
> point.
> I also believe 'user defined' is to be avoided in the same way that new
> methods in http are to be avoided.
> If it comes to a problem with flexibility describing the change to the
> resource - I highly recommend using 'sub-properties' in the same sense as
> pointed out by MarkB relating to the ";" in urls. This 'sub-property' is
> controlled by the resource, but not necessarily independently addressable.
> If it were addressable, then it would be subscribable, and those
> subscriptions would receive the event.
> For example, listening to a users online status might be:
> Target-URI: http://www.topiczero.com:8000/kn/who/dierken.com/mike/
> Property: presence
> Operation: update
>
> 3 "some form of "difference" may suffice "
> Content negotiation is goodness. Personally, I'd avoid 'delta' events, due
> to problems with often needing guaranteed delivery and sequence. Sending
> temperature as "up:3" isn't as good as "98". But I understand that
sometimes
> deltas are okay.
>
> 4 "the Event Sink may email notifications "
> You will probably want user-agent metadata on the subscription (what
> user-agent, what content-type, and what form of content-type (like
different
> approaches to html mail)). Something for the future, but make sure there
is
> room later.
>
> 5 "may define a convention for using query parameters..."
> Yay! I realize this is a short-term hack for backward compatibility - but
> you gotta do what you gotta do...
>
> 6 "HTTP-equiv could also be used "
> Nifty.
>
> 7 "browser would ask the user"
> This would probably (d)evolve into HTML in the same way that HTTP
> authentication evolved into custom HTML forms for logging in. Don't
> underestimate the power of the marketing side.
>
Just this part, is worth its weight in gold - all web app developers should burn this into their brains: "One way to make sure that your data gets through is to try and try again until you get a proper acknowledgement. If the action you were completing is "idempotent" then by definition it is safe to try again and again until it succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think about them as if they were file system commands it should be clear why. It never hurts to read a file over and over again. It also does not hurt to write a file over and over again as long as you are writing the same data. And deleting a file repeatedly will at most give you an error message. On the other hand, the POST command is sort of like adding to a file. You can see how adding the same data to a file over and over again is very different than merely overwriting the file with the same data over and over again. POSTed data often accumulates. Because POSTed data accumulates we need to make certain that we set up our system so that multiple POSTs of the same data are not harmful." ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <rest-discuss@yahoogroups.com>; <fnparr@...>; <mconner@...>; <stephen_todd@...> Sent: Wednesday, January 23, 2002 10:40 PM Subject: [rest-discuss] Reliable HTTP > Maybe of interest to you: > > http://www.prescod.net/reliable_http.html > > Comments are welcome. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
----- Original Message ----- From: "Paul Prescod" <paul@...> > Maybe of interest to you: > > http://www.prescod.net/reliable_http.html > > Comments are welcome. > While you are at it, could you formalize with your golden pen the 'best practices' regarding "202 Accepted" (asynchronous response)? Mike
When I am next in Seattle you can dictate and I'll write down. I don't know anything about this stuff unless Mark Baker told me it. I am just the prophet. Plus I don't have any time to write more right now because I have to attend to profit. (or at least break-even) "S. Mike Dierken" wrote: > > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > > > Maybe of interest to you: > > > > http://www.prescod.net/reliable_http.html > > > > Comments are welcome. > > > > While you are at it, could you formalize with your golden pen the 'best > practices' regarding "202 Accepted" (asynchronous response)? > > Mike > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"S. Mike Dierken" wrote: > > ... > > I don't think it is just that we are unfamiliar with HTTP, or even that we > are unfamiliar with the concepts of ReST, but I think trying to take a model > (pub/sub or rdbms or whatever) map it to another model (ReST) and at the > same time map it to a 'wire format' - something gets lost in the > translation. Is HTTP design harder than object oriented or relational or functional design? I think it is just another one of those Zens that domain-elite computer programmers need to pick up and mediocre ones kind of emulate by osmosis. Having to deal with a wire format adds some headache but hey, I learned OO programming using C++. Talk about an additional hurdle! Luckily it wasn't as frighteningly convoluted in the early days as it is now. > I don't see a trend for web applications converging on common approaches of > using HTTP for a lot of cases, because most web applications talk to > themselves - the only interoperation is through a link and a GET. They can > put data in any slot without breaking anything because they wrote both the > client and the server. Look at the many ways of doing user login - almost > none of them use HTTP security constructs - and things still work. That's why nobody understands REST. They didn't have to understand the Web to use it. They memorize a few rules (hopefully!) like GET puts things in the URL. POST changes a database and so forth. Web services are different. You want web services to work like "the web". You want thousands of independently designed clients and servers for the more interesting ones. Maybe the majority of small point to point web services will use RPC. If that works for them, fine! But I hope and expect that the people designing reusable protocols for use with multiple clients and servers will learn about REST. > ... > Something that would help me in the future is to model a large > information-centric applications (including security and events) and create > a direct mapping into URIs and HTTP. Er. Wasn't that your last job? In fact, when I started hearing about REST I remember thinking: "that Dierken lunatic was on to something!" Paul Prescod
My article is going to be published in a couple of weeks and I'd like to think of that as the first wave in a marketing campaign that will get the web services world to start re-evaluating what we have. The rest of you geeks are probably more concerned with substance over style so I doubt I'll get much uptake on this suggestion. Nevertheless...it's worth a try. Frankly, I think the name "REpresentational State Transfer" sucks. Maybe when I get more REST-Zen I'll think that the core idea in the web architecture is the transfer of state representations but right now I think that's just one issue, along with unified naming conventions, generic methods, standardization of content types, client-side scripting, etc. The whole architecture has no single clear defining characteristic so I don't think it should be named after a particular one. Okay, REST isn't going away but maybe we can have a different name when the style is applied to so-called "Web services". I propose World Wide Web Architectural Style : WWWAS Using the full form of "the Web" may get people thinking back to roots. It is not an English word so a single essay will score easily in Google. WWWAS would individuate itself (informally) from REST over a while by adopting standardized XML formats that apply to web services problems. Or maybe WWWAS is REST+XML and everything XML allows. Paul Prescod
> Frankly, I think the name "REpresentational State Transfer" sucks. Maybe The full name won't make much sense to most people, but "REST" is a memorable word. "SOAP" doesn't mean "Simple Object Access Protocol" anymore, so perhaps you can use the term without getting into what it means. > when I get more REST-Zen I'll think that the core idea in the web > architecture is the transfer of state representations but right now I > think that's just one issue, along with unified naming conventions, > generic methods, standardization of content types, client-side > scripting, etc. The whole architecture has no single clear defining > characteristic so I don't think it should be named after a particular > one. Well, REST is that. The implications of doing state transfer include needing some common minimal interface, need a way to identify the things that have state, etc.. No single name could capture everything you want to talk about above, because not all of them are architectural issues. > Okay, REST isn't going away but maybe we can have a different name when > the style is applied to so-called "Web services". I propose World Wide > Web Architectural Style : WWWAS > > Using the full form of "the Web" may get people thinking back to roots. > It is not an English word so a single essay will score easily in Google. > WWWAS would individuate itself (informally) from REST over a while by > adopting standardized XML formats that apply to web services problems. > Or maybe WWWAS is REST+XML and everything XML allows. Ick, I don't care for it much. If I was describing REST, then I would personally feel obligated to use the name. The last thing we need is to have to explain the relationship between REST and whatever new name you come up with for whatever it is you're trying to identify. Please try to avoid defining a new term. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Paul, I gotta disagree on this one. I think REST is a good name --- notwithstanding the problem with existing English terms, it states specifically and tersely *the* core idea. (I.e., I think you're wrong -- REpresentational State Transfer *is* the single, clear, defining characteristic, and the key differentiator between the original Web concept (transfer object state / representations, all objects have a generic and distributable interface and semantics) and any of a number of appropriate and inappropriate technologies that have accreted around the Web. WWWAS sound like yet another bs tech-elite jargon / acronym, and surely we've had (a) enough of those, and (b) enough of those with "www" embedded in them. Referring to something as WWWAS also runs the risk of being a hotbed of disagreement as to what constitutes the Web's architecture; REST runs this risk, too, but is potentially much more contained. $0.02, jb Paul Prescod wrote: > My article is going to be published in a couple of weeks and I'd like to > think of that as the first wave in a marketing campaign that will get > the web services world to start re-evaluating what we have. The rest of > you geeks are probably more concerned with substance over style so I > doubt I'll get much uptake on this suggestion. Nevertheless...it's worth > a try. > > Frankly, I think the name "REpresentational State Transfer" sucks. Maybe > when I get more REST-Zen I'll think that the core idea in the web > architecture is the transfer of state representations but right now I > think that's just one issue, along with unified naming conventions, > generic methods, standardization of content types, client-side > scripting, etc. The whole architecture has no single clear defining > characteristic so I don't think it should be named after a particular > one. > > Okay, REST isn't going away but maybe we can have a different name when > the style is applied to so-called "Web services". I propose World Wide > Web Architectural Style : WWWAS > > Using the full form of "the Web" may get people thinking back to roots. > It is not an English word so a single essay will score easily in Google. > WWWAS would individuate itself (informally) from REST over a while by > adopting standardized XML formats that apply to web services problems. > Or maybe WWWAS is REST+XML and everything XML allows. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> (btw 'Entangled' is a great term). Yah, I thought so. I was recently reading about entangled photons, and the word stuck. > I like the 'collection/container' based approach also, but was just pointing > out a common alternative. > > I had a thought - your 'good container design' comment about a) mentions > that a post in one causes a delete in the other. Does this imply that a > resource that is a collection must/should be disjoint from all other > addressable collections? Just MAY. There may be good reasons for not doing this, but absent any requirements to the contrary, I think this is a cleaner way to go. > Does this imply aliases are to be avoided? By "alias", I assume you mean where a single resource publisher has different URIs that identify the same resource. That's a good rule, generally, no? > If aliases or overlapping collections exist, and events are to be routed, an > event in one would/should cause an event in the other(s)? If something is > addressable, it is subscribable. If aliases exist, multiple subscriptions > via the aliases and there should not be one 'preferred' alias. There appears to be words missing from that last sentence, but if I understand you correctly, yes, there needs to be consistent behaviour for what a subscribe/unsubscribe means on aliases. > Also, regarding uri 'parameters' (which I have not read up on, so correct > any and all misconceptions) - if these are unique identifiers yet guaranteed > to informationally subordinate to the non-parameterized uri, then you have > what appears to be an overlapping collection - with the 'parent' resource > channeling events for the 'sub-properties'. The sub-properties may be > available for fine-grained subscriptions (mini-filters) and the main > resource is avialable for catch-all subscriptions. A bit > stream-of-unconciousness, but I hope that made sense. Er, nope. 8-) What's a subproperty? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Okay. I didn't think it would go over well. Just a shot in the dark. Consider that Simple Object Access Protocol sounds MUCH BETTER than SOAP actually is! But okay, I won't push it. We'll be stuck with a weird name forever. ;) Paul Prescod
> "One way to make sure that your data gets through is to try and try again > until you get a proper acknowledgement. If the action you were completing is > "idempotent" then by definition it is safe to try again and again until it > succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think > about them as if they were file system commands it should be clear why. It > never hurts to read a file over and over again. It also does not hurt to > write a file over and over again as long as you are writing the same data. > And deleting a file repeatedly will at most give you an error message. PUT is idempotent, but it also has side effects. You have to be wary of that. See; http://www.w3.org/1999/04/Editing/ MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> When I am next in Seattle you can dictate and I'll write down. I don't > know anything about this stuff unless Mark Baker told me it. I am just > the prophet. Heh. > Plus I don't have any time to write more right now because I have to > attend to profit. (or at least break-even) The prophet attends to profit. Cute. > > While you are at it, could you formalize with your golden pen the 'best > > practices' regarding "202 Accepted" (asynchronous response)? WRT to reliable HTTP? 202 is one way of managing disconnected operations. See; http://lists.xml.org/archives/xml-dev/200201/msg01222.html MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > ... > > Something that would help me in the future is to model a large > > information-centric applications (including security and events) and create > > a direct mapping into URIs and HTTP. > > Er. Wasn't that your last job? Yes - but I didn't do a rigorous job with the http parts (headers, etc.) and had to make it work in a browser, and had to explain why url addressability is a Good Thing every other week. And try to learn what we were doing and so on. I failed of course, but I learned a lot. > > In fact, when I started hearing about REST I remember thinking: "that > Dierken lunatic was on to something!" > On something, or on to something?
brainstorming - but I like ReST the BeST - Web Applications Next Generation (WANG) XML Applications Next Generation (XANG) Web Service Interoperability Next Gen (WSing) ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, January 24, 2002 6:47 AM Subject: [rest-discuss] Markety name > My article is going to be published in a couple of weeks and I'd like to > think of that as the first wave in a marketing campaign that will get > the web services world to start re-evaluating what we have. The rest of > you geeks are probably more concerned with substance over style so I > doubt I'll get much uptake on this suggestion. Nevertheless...it's worth > a try. > > Frankly, I think the name "REpresentational State Transfer" sucks. Maybe > when I get more REST-Zen I'll think that the core idea in the web > architecture is the transfer of state representations but right now I > think that's just one issue, along with unified naming conventions, > generic methods, standardization of content types, client-side > scripting, etc. The whole architecture has no single clear defining > characteristic so I don't think it should be named after a particular > one. > > Okay, REST isn't going away but maybe we can have a different name when > the style is applied to so-called "Web services". I propose World Wide > Web Architectural Style : WWWAS > > Using the full form of "the Web" may get people thinking back to roots. > It is not an English word so a single essay will score easily in Google. > WWWAS would individuate itself (informally) from REST over a while by > adopting standardized XML formats that apply to web services problems. > Or maybe WWWAS is REST+XML and everything XML allows. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> > If aliases or overlapping collections exist, and events are to be routed, an > > event in one would/should cause an event in the other(s)? If something is > > addressable, it is subscribable. If aliases exist, multiple subscriptions > > via the aliases and there should not be one 'preferred' alias. > > There appears to be words missing from that last sentence, but if I > understand you correctly, yes, there needs to be consistent behaviour > for what a subscribe/unsubscribe means on aliases. Yes - my mistake. "If aliases exist, multiple subscriptions [exist] via the aliases and there should not be one 'preferred' alias."
"S. Mike Dierken" wrote: > > ... > > In fact, when I started hearing about REST I remember thinking: "that > > Dierken lunatic was on to something!" > > > On something, or on to something? Yes. Paul Prescod
I don't know yet if HTTP has to be hard to design with, but I agree that it is at present. The amount of obscurantia needed is very large; few people outside of the standards development community have it. Witness that REST advocates regularly need to point to primary materials such as http://www.w3.org/1999/04/Editing/override-entry.txt and RFCs. What is missing is concise documentation related to HTTP semantics. Things like RFC 2616 need to cover too much turf for non-fanatics to find answers in a timely way. Eg, wading through a sea of BNF diagrams to glean semantics is impractical. I wouldn't blame this on HTTP. The REST design style is at a stage where lore is passed on person to person. This can change if anybody takes the initiative to develop documentation for a general audience. The REST Wiki is a beginning.
Mark Baker wrote: > >> > "One way to make sure that your data gets through is to try and try again > > until you get a proper acknowledgement. If the action you were completing is > > "idempotent" then by definition it is safe to try again and again until it > > succeeds. The HTTP GET, PUT and DELETE methods are idempotent. > > PUT is idempotent, but it also has side effects. You have to be wary of > that. See; > > http://www.w3.org/1999/04/Editing/ I agree that lost update is a problem. I don't see how it relates to "PUT also has side effects." Overwriting someone else's data is not a side effect in the traditional sense! Do you think that the issue is sufficiently related to reliability to mention it in that essay? Paul Prescod
> I agree that lost update is a problem. I don't see how it relates to > "PUT also has side effects." Overwriting someone else's data is not a > side effect in the traditional sense! > > Do you think that the issue is sufficiently related to reliability to > mention it in that essay? Well, it's just that you said that you can keep invoking PUT over and over, which is true, but you have to be aware that you may be stomping over somebody else's changes. Yes, I think this relates to reliability quite closely. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Wed, 23 Jan 2002, S. Mike Dierken wrote: > I've been going over the discussions about the asynchronous capabilities of > HTTP and what to do about the missing pieces and have some discomforting > thoughts. > We all know what it means when we say 'pub/sub' and 'notification' or > request and response or messaging, but when we say "And now for the HTTP..." > we all disagree. Thats because we are talking about using HTTP to implement something that isn't the domain of HTTP. HTTP was designed to be a synchronous, client/server, connectionless protocol. It was designed to let clients request/update resources from a server simply and easily. It was not designed for asynch, p2p, chat, or distributed computation. When using HTTP for any of these things we are simply designing a new protocol on top of a set of HTTP primitives. It is far from clear that the optimal design for an asynch protocol is to ride on top of HTTP. Much as it would not be surprising if we disagreed about the best design for an email system using C++ and the STL, it should not be at all surprising that we disgaree when using HTTP. There is much too much distance between the application domain and the tools we are using. > I don't see a trend for web applications converging on common approaches of > using HTTP for a lot of cases, because most web applications talk to > themselves - the only interoperation is through a link and a GET. They can > put data in any slot without breaking anything because they wrote both the > client and the server. Look at the many ways of doing user login - almost > none of them use HTTP security constructs - and things still work. I agree. That was part of the motivation for MIME-RPC. But I would say something stronger. Most organizations are designing for internal use or to bind customers/suppliers closer to themselves. They prefer to expose their organizational constructs over the internet rather than modify their organizational constructs match those of HTTP. To put it another way, they are designing applications not protocols. > Something that would help me in the future is to model a large > information-centric applications (including security and events) and create > a direct mapping into URIs and HTTP. If anybody has any thoughts or > experience with this, give me a shout. (The kind of thing I'm thinking about > is like an 'object oriented web' but 'OO' isn't appropriate. Components and > interfaces are closer. Entity-relationship from rdbms and OMT/UML notation > is closer still.) I tried to open this discussion earlier, but got no response. I asked for a REST consisten way of implementing terrorist_or_not.com (a made up application). The idea is that security checkpoints send front and side views of individuals to some server and the server sends back information about whether the person looks like a known terrorist in the database. We can add the complexity that processing the request may take long enough for the response to arrive back asynchronously (but sometimes the server can decide quickly). I think the implementation is straightforward using MIME-RPC (because it can get much closer to application level semantics). The REST implementation is much less obvious (at least to me). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > Thats because we are talking about using HTTP to > implement something that isn't the domain of HTTP. > HTTP was designed to be a synchronous, > client/server, connectionless protocol. It was > designed to let clients request/update resources > from a server simply and easily. > > It was not designed for asynch, p2p, chat, or > distributed computation. When using HTTP for any > of these things we are simply designing a new > protocol on top of a set of HTTP primitives. It > is far from clear that the optimal design for an > asynch protocol is to ride on top of HTTP. I'm talking also about designing resource-centric systems. I see problems in 'consistent/correct' use of HTTP in those cases also.
> Thats because we are talking about using HTTP to > implement something that isn't the domain of HTTP. No, Alex, that's not true. HTTP was designed to support *all* the things you mentioned below. Why? Because it defines a very general application model that all of them can be mapped onto. You just have to model the application properly to make it fit the REST application model. Granted, some applications will fit better than others, and some will have too much trouble fitting at all, but my rule of thumb on this is straightforward; if you're doing it now with TCP, you can do it with HTTP. It has served me well. > HTTP was designed to be a synchronous, > client/server, connectionless protocol. Correction. It was designed to be a stateless, request/response protocol. It is not necessarily synchronous, nor is it "client/server" in the traditional sense of the term where each actor plays a fix role as either client or server, but not both. HTTP permits actors playing both roles. > It was > designed to let clients request/update resources > from a server simply and easily. More or less, yes. Now name an app that can't be modelled as a set of resources which are manipulated with the HTTP method set. > It was not designed for asynch, p2p, chat, or > distributed computation. All of those can be modelled the way I described. I use it for chat (and sometimes p2p) on a daily basis. See http://www.snapchannels.net > > Something that would help me in the future is to model a large > > information-centric applications (including security and events) and create > > a direct mapping into URIs and HTTP. If anybody has any thoughts or > > experience with this, give me a shout. (The kind of thing I'm thinking about > > is like an 'object oriented web' but 'OO' isn't appropriate. Components and > > interfaces are closer. Entity-relationship from rdbms and OMT/UML notation > > is closer still.) > > I tried to open this discussion earlier, but got > no response. I asked for a REST consisten way of > implementing terrorist_or_not.com (a made up > application). > > The idea is that security checkpoints send front > and side views of individuals to some server and > the server sends back information about whether > the person looks like a known terrorist in the > database. > > We can add the complexity that processing the > request may take long enough for the response to > arrive back asynchronously (but sometimes the > server can decide quickly). > > I think the implementation is straightforward > using MIME-RPC (because it can get much closer to > application level semantics). The REST > implementation is much less obvious (at least to > me). This would be pretty easy. POST the picture to /terrorists, which would add the picture to a database, and the response to the POST could include a text/plain message saying "Terrorist!!" or "Not a terrorist". The response could also be a 201 response (indicating that a resource was created), which returned a URI that identified that particular picture in the database. So an HTML response could say; ... <a href="that-uri">This person</a> is not a terrorist. ... MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> I tried to open this discussion earlier, but got > no response. I asked for a REST consisten way of > implementing terrorist_or_not.com (a made up > application). > > The idea is that security checkpoints send front > and side views of individuals to some server and > the server sends back information about whether > the person looks like a known terrorist in the > database. > > We can add the complexity that processing the > request may take long enough for the response to > arrive back asynchronously (but sometimes the > server can decide quickly). > > I think the implementation is straightforward > using MIME-RPC (because it can get much closer to > application level semantics). The REST > implementation is much less obvious (at least to > me). My view is that HTTP is centered on read/write and it looks like you want 'find'. I suppose you can do a 'find' as a parameterized 'read' - only your parameters are image bits, not text. That makes it kind of hard to use GET to do the read. One way to do it is: (add a suspect) ==> POST http://www.terrorist_or_fed.com/suspects/ HTTP/1.1 Content-Type: mulitpart/related --- image 1 --- --- image 2 --- <== 202 Accepted Location: http://www.terrorist_or_fed.com/suspects/12345/ (get status of suspect) ==> GET http://www.terrorist_or_fed.com/suspects/12345/ HTTP/1.1 Accept: text/xml <== 200 Success Content-Type: text/xml <suspect> <status>verified</status> <category>terrorist</category> </suspect>
On Wed, 23 Jan 2002, S. Mike Dierken wrote: > Just this part, is worth its weight in gold - all web app developers should > burn this into their brains: > > "One way to make sure that your data gets through is to try and try again > until you get a proper acknowledgement. If the action you were completing is > "idempotent" then by definition it is safe to try again and again until it > succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think > about them as if they were file system commands it should be clear why. It > never hurts to read a file over and over again. It also does not hurt to > write a file over and over again as long as you are writing the same data. > And deleting a file repeatedly will at most give you an error message. Developers should be very careful here. All of these methods are time dependent and there is no guarantee that multiple idempotent requests won't interfere with one another. Order matters. Suppose you decide to increment a value by 1 and then by 100. Now suppose you GET the value 25. You then PUT the value 26, but it fails so you keep trying. While this is happening you GET the value 25 again, and PUT the value 125. At the end of this process the resource value will be either 26 or 125, but the correct value would have been 126. Order matters. Idempotency doesn't help you much. Paul's RPOST proposal has a similar problem. There is no way for the client to guarantee that RPOSTS will actually get posted in the correct order. Even if the server is issuing message-ids and only processes RPOSTS in order of message-ids: a. Nothing in the spec says that clients have to use message-id's in the order in which they were issued. b. It is impossible to guarantee that the client uses all message-Ids so the server has no way to guarantee in-orderness. It is really hard to get all this right without implementing a lot of layers of transactions. I tried to document this for mime-rpc (see http://www.mime-rpc.com/serviceSpec.html). The general points are: 1. clients should issue their own message-ids. If they don't want to get stepped on, they should make them sufficiently unique (and secret). 2. reliable messaging looks like repeat requests 3. you may want to support a seriality protocol in which clients send a cardinality header (I haven't decided if this should really be an ordinality header, leaving the cardinality header for the transaction protocols). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > If you're going to do that, you at least need a gateway that can > > terminate the HTTP chain so that end-to-end behaviour is guaranteed > > (i.e. move the "end" in 8-). Just recognize that you're doing this, > > and don't try to pretend that you're doing HTTP behind the gateway > > or that will just cause more trouble. > > > > If I wanted to model the resource system as an addressable collection of > messages, what would the HTTP requests and responses look like? Especially > if those messages were literally HTTP request and response formats? But they wouldn't be, past a certain point. That point is the gateway. > Like > blindly logging all web server activity and having an analysis program > consume those from disk via HTTP. Erm, I thought you were doing this because you've only got on way comms with your resource? Sure, you could log all messages by doing that, but in that case you're not tunneling because the message are truly opaque. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a > > > particular application domain, > > > > It means just that. As soon as you assign any meaning to a URI, then > > only those privy to that meaning are in on your little secrets (like > > appending "/subs" means "subscribers to the URI before /subs"). > > Interoperability means sacrificing private convention for public > > specification. So you make the URI-to-URI relationship explicit with > > a statement, such as is done with an HTTP header or an RDF statement, > > etc.. > > > That statement (the name and location of the information) is still a little > secret that only those in the know. > However, it may be better to move that out of the URI, and also do something > to ensure backward compatibility - like defining these as 'advisory' and > optional. These turns the http response into a multi-link (or something - > Paul, help me out here) with named references to interesting sub-properities > of the resource. If those sub-properties are addressable, they are also > probably subscribable. So a DAV Properties: specified URI should be > listenable for just property (not content) changes. Ok. > If an HTTP WATCH method were to be used, would OPTIONS return that fact? > Does it operate per resource? (ignoring the extra requests to figure stuff > out) OPTIONS works on the whole req/resp chain, including the resource (except when "*" is used). Yah, it should have the Allow header in the response which would tell you what methods were supported. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Thu, 24 Jan 2002, Mark Baker wrote: > No, Alex, that's not true. HTTP was designed to support *all* the > things you mentioned below. Why? Because it defines a very general > application model that all of them can be mapped onto. You just have to > model the application properly to make it fit the REST application model. > Granted, some applications will fit better than others, and some will > have too much trouble fitting at all, but my rule of thumb on this is > straightforward; if you're doing it now with TCP, you can do it with > HTTP. It has served me well. I think everything is looking like a nail to you. I don't deny that HTTP is a wonderful thing. However, I could quite reasonably make the claim that you can do everything you can do in HTTP using SMTP. More generally, I think there are a large class of applications in which you are using HTTP simply to get access to TCP and that it would actually be more efficient just to use TCP directly. To put it another way, you can send TPC over carrier pigeon. That doesn't mean that you always want to do so. The real reason to use HTTP is the amount of existing plumbing to support it. If your application isn't really going to be able to take advantage of that plumbing it isn't so useful. For example, if I wanted to implement a Presence server for clients that may be behind firewalls. I could do it via HTTP by having the clients ping every n seconds, but that would be an inefficient use of network resources. A better solution might be to rely on TCP directly and have clients simply hold open a TCP connections. The server can then determine presence simply by checking whether it still has a connection to the client. (yes, I'm leaving out lots of details, but you get my point) > > HTTP was designed to be a synchronous, > > client/server, connectionless protocol. > > Correction. It was designed to be a stateless, request/response > protocol. It is not necessarily synchronous, nor is it "client/server" > in the traditional sense of the term where each actor plays a fix > role as either client or server, but not both. HTTP permits actors > playing both roles. No. HTTP only has a client making a request and a server responding to the request. The server can't send a request unless it plays the role of client. Even in traditional client/server (long connections), there was nothing that prevented this from happening. Its just that the protocol itself is defined in terms of clients making requests of servers. > > It was > > designed to let clients request/update resources > > from a server simply and easily. > > More or less, yes. Now name an app that can't be modelled as a set > of resources which are manipulated with the HTTP method set. Ok, name an app that can't be modelled as a set of email addresses. The issue is whether the app SHOULD be modelled as a set of HTTP resources or a email addresses or whatever. See the presence example above. Think of it this way. Just because every computer language is turing complete, that doesn't mean every language is equivalently useful for implementing your application. Not everything is the nail to your HTTP hammer. > > It was not designed for asynch, p2p, chat, or > > distributed computation. > > All of those can be modelled the way I described. I use it for chat > (and sometimes p2p) on a daily basis. See http://www.snapchannels.net Congratulations. Looks cool. Doesn't mean that was the best way to go. For example, would you use HTTP for an IM client (if you needed to support large numbers of them)? Having millions of clients polling for messages seems like a bad idea. > This would be pretty easy. POST the picture to /terrorists, > which would add the picture to a database, and the response to the > POST could include a text/plain message saying "Terrorist!!" or > "Not a terrorist". The response could also be a 201 response > (indicating that a resource was created), which returned a URI > that identified that particular picture in the database. So an > HTML response could say; > ... > <a href="that-uri">This person</a> is not a terrorist. > ... I'm not sure you read the problem correctly. The client is simply making a query to the server and getting a yes/no response. In other words, it is making an idempotent request. Accoding to REST, the client should use GET for such a a request, but I don't know how you send two pictures using GET. So I'm not sure you can use REST. There is no requirement that the server maintain a copy of the pictures so you would not need a 201. The server may take a long time to respond to the query so it may issue a 202 Accepted. But, if it does, then we also need a convention for delivery of the reply. I think MIME-RPC provides these conventions and allows this application to be deployed over SMTP almost exactly as it would be deployed over HTTP. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 24 Jan 2002, S. Mike Dierken wrote: > My view is that HTTP is centered on read/write and it looks like you want > 'find'. I suppose you can do a 'find' as a parameterized 'read' - only your > parameters are image bits, not text. That makes it kind of hard to use GET > to do the read. > [...post images then get results...] Hmm. This is a start, but: * If HTTP is centered on read/write and I want find, then perhaps I want a different protocol. But, then why does the URI spec have a query string? It feels like we are now hacking around either the inadequacies of HTTP or the inadequacies of REST. * I think you would PUT rather than POST the images (you are not appending to anything) * either PUT or POST is bad, because the server now needs to maintain a copy of the results for some indeterminate period of time -- which is ugly. * if processing the request takes a while, the client has to keep polling the GET url until it gets a response -- which is also ugly. The best protcol for this may not be HTTP, but to the extent we want to use it, I think the best design is for the Client to POST the two images as multpart/mixed with reply-to-url/message-id headers. And then for the Server to reply back with the answer or reply 202 and eventually send result to the callback url. That being said, if we want to expose the application to web browsers, the correct answer is for the server to handle multipart/form-data, and either respond with the answer, or response with a form asking where the answer should be delivered. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > The real reason to use HTTP is the amount of > existing plumbing to support it. > > If your application isn't really going to be able > to take advantage of that plumbing it isn't so > useful. > Ask not what the Web can do for you, rather ask what you can do for the Web.
"S. Alexander Jacobson" wrote: > More generally, I think there are a large class of > applications in which you are using HTTP simply to > get access to TCP and that it would actually be > more efficient just to use TCP directly. Ah, glasshoppah, I see where you are failing. You have not yet passed through the No Barrier. You have not yet achieved true Web Zen. The satori, the total consciousness of Webby Sabi has yet to visit the tempestuous storm crashing over your lobes. You must do the following: sit on a serene hillside far from the troubles of man, fast, and repeat the following until you achieve enlightenment: "HTTP is not a protocol, it is a universal application. HTTP is not a protocol, it is a universal application. HTTP is not a protocol...." ;-) jb PS - Deja vu, Alex. You're cribbing *my* old position. I was woefully wrong....
Alex, no offense dude, but you don't get REST yet. It would really help things a lot in this discussion if you stopped pulling a Dave Winer by thinking you understand it, and dismissing it so quickly as unsuitable. > I think everything is looking like a nail to you. You're damned right. Putting something on the Web requires being able to see things as a nail. Some things won't ever be nails, but with REST, the vast majority of things can be seen as nails. > I don't deny that HTTP is a wonderful thing. > However, I could quite reasonably make the claim > that you can do everything you can do in HTTP > using SMTP. Nope. How would you retrieve information with SMTP, without additional a priori agreement? > For example, if I wanted to implement a Presence > server for clients that may be behind firewalls. > I could do it via HTTP by having the clients > ping every n seconds, but that would be an > inefficient use of network resources. > > A better solution might be to rely on TCP > directly and have clients simply hold open a TCP > connections. The server can then determine > presence simply by checking whether it still has a > connection to the client. (yes, I'm leaving out > lots of details, but you get my point) HTTP can use persistent connections on a GET to receive information. This is safe if the information that's received isn't another protocol (like an encapsulated message/http). But you first have to model your presence app as a set of resources. e.g. each user gets a URI, a persistent GET to that URI returns a stream of presence messages as their presence status changes, etc.. > Even in traditional client/server (long > connections), there was nothing that prevented > this from happening. Its just that the protocol > itself is defined in terms of clients making > requests of servers. Name a protocol that doesn't work this way. > > > It was > > > designed to let clients request/update resources > > > from a server simply and easily. > > > > More or less, yes. Now name an app that can't be modelled as a set > > of resources which are manipulated with the HTTP method set. > > Ok, name an app that can't be modelled as a set of > email addresses. The Web. > The issue is whether the app SHOULD be modelled as > a set of HTTP resources or a email addresses or > whatever. In part, that's true. But often (unless you've been doing this as long as I have 8-), you won't know until you try. You're not even trying. > > All of those can be modelled the way I described. I use it for chat > > (and sometimes p2p) on a daily basis. See http://www.snapchannels.net > > Congratulations. Looks cool. Doesn't mean that > was the best way to go. For example, would you > use HTTP for an IM client (if you needed to > support large numbers of them)? Having millions > of clients polling for messages seems like a bad > idea. If I could offload to a proxy farm, sure. Proxies are an integral part of REST for this and other reasons. But as I said, if you can use TCP, you can probably use HTTP. Can that IM app use TCP? > I'm not sure you read the problem correctly. > > The client is simply making a query to the server > and getting a yes/no response. > > In other words, it is making an idempotent > request. You mean that if a picture of a terrorist was submitted, that nobody would want to store it? Seriously? If there is a chance that it might not be idempotent, then you have to use POST. But as Paul and I discussed a while ago, HTTP is missing a method to support idempotent operations on content, like transcoding or whatever. This is not a failing in REST, it is a missing feature of HTTP, but it could easily be added. > Accoding to REST, the client should use > GET for such a a request, but I don't know how you > send two pictures using GET. So I'm not sure you > can use REST. Well, no, it's according to TimBL, not REST. I have some issues with Tim's views of this too; http://lists.w3.org/Archives/Public/www-tag/2002Jan/0075.html That is, other idempotent requests are fine (OPTIONS is one), so long as it doesn't act on the information space formed by GET, and that GET remains the only method used for URI resolution (i.e. when you click on a URI, it can only ever mean GET). A new idempotent data submission method would be fine. > The server may take a long time to respond to > the query so it may issue a 202 Accepted. But, > if it does, then we also need a convention for > delivery of the reply. One convention is described in RFC 2616. Put a URI in the body of the 202 response that represents the completed request. > I think MIME-RPC provides these conventions and > allows this application to be deployed over > SMTP almost exactly as it would be deployed over > HTTP. That's because you're building a new protocol and tunneling it over SMTP and HTTP. i.e. you're disregarding the view of the world that each of these other application protocols attempts to enforce. You've also got a hammer it seems; one that likes to flatten everything to ensure a consistent view of the world. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > > ... > > Much as it would not be surprising if we disagreed > about the best design for an email system using > C++ and the STL, it should not be at all > surprising that we disgaree when using HTTP. There is always a gap between one model and another. The problem is we've learned to think about it one way and now we must learn to think about it another. If you taught someone REST and you taught them sockets and asked them to invent an email system I think they would find it easier to do it using HTTP and REST. >... > To put it another way, they are designing > applications not protocols. Big mistake. Maintaining applications is extremely expensive. A purchase order application is no easier to maintain in the long run than an email application. How many companies have their own email applications? Rather they buy interoperable products implementing the same protocol. > The idea is that security checkpoints send front > and side views of individuals to some server and > the server sends back information about whether > the person looks like a known terrorist in the > database. > > We can add the complexity that processing the > request may take long enough for the response to > arrive back asynchronously (but sometimes the > server can decide quickly). I don't now if anyone answered you yet. Here's how I would go about thinking about it. You want it to be asyncronous. That means that the server must have "persistent state" that survives longer than a single connection and yet is meaningful to the client. That suggests to me that you are creating a new reasource (if only a temporary one). So you do a POST of the picture. mime/multipart could be used if there is a associated XML metadatda. The server returns a Location: for the new resource. If you want a web interface then you can use a POST form. The new resource represents the computation. The client can do a GET on it any time to see how the computation is progressing. When it is done the computation result could appear there. In the meantime, status reports are there so that the client can check back whenever it wants. If you want a web interface, consider a META http-equiv=refresh thing. The client may also want an asyncronous notification of when this status resource changes. In the interests of layering and distribution of processing, I would think of this as a completely unrelated part of the system. Some clients could poll. Others could ask for a notification. Maybe the resource for status and for the final result should be separate...I can't see big tradeoffs one way or the other off the top of my head. If there was a web interface, a button on the HTML could give the user the asych notification option. Conventions for asyncronous notification are here: * http://www.prescod.net/HTTP_event_conventions.html If you had some kind of mod_asych then adding asynch support would require no extra effort. And you could easily support either or both of email and HTTP-based notification. Anyhow, that's how I would model it. Notice how I try to think about the web interface at each step. It allows me to envision the process in concrete terms and ensure that I am always creating resources that are useful to the client. Using content-negotiation I can really create these HTML forms for testing purposes even if the main goal of the service is for automated users. As these pictures are large, you might want to consider allowing users to submit some kind of a hash to check if the picture is already on the site. That's another benefit of modelling the system so that results are resources. You could point someone at an existing result in your "cache". REST rewards you for making things into resources as functional programming rewards you for making your functions small and reusable. Paul Prescod
Mark Baker wrote: > >... > > But as I said, if you can use TCP, you can probably use HTTP. If this turns out to be literally true, so that one day there is only one TCP-based protocol then TCP won't be very useful. It's like an operating system that can only be used for one application. Why not just code the application to the bare metal if you're not amortizing any costs. On the other hand, I suspect that people will always resist resource-modelling their application so TCP will be a rich home for RPC applications forever. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Hmm. This is a start, but: > * If HTTP is centered on read/write and I want > find, then perhaps I want a different protocol. Yeah, that's what I heard Google did. ;) > But, then why does the URI spec have a query > string? It feels like we are now hacking around > either the inadequacies of HTTP or the > inadequacies of REST. PUT/POST/DELETE/GET are primitives. You build things on top of them. Like CPU instructions. Modern CPUs don't have an evaluate polynomial instruction. It was found that it was really expensive to have instructions that catered only to one kind of problem or another. RPCs are like that. > * I think you would PUT rather than POST the > images (you are not appending to anything) I believe PUT is only good if the client already has an address to PUT the thing. If not, then yes you are creating something and the new thing is considered a "sub-resource" (appendage) of the old thing. > * either PUT or POST is bad, because the server > now needs to maintain a copy of the results for > some indeterminate period of time -- which is > ugly. PUT or POST do not require this, really, but maintaing the data is good for caching and it is more polite in my opinion to send the client a URL than the data. What if it is a handheld computer? If they want all of the data they should be able to get it but if they want only a link then the server should be willing to serve it for a while. > * if processing the request takes a while, the > client has to keep polling the GET url until it > gets a response -- which is also ugly. If it wants to poll it can do so. Otherwise it can ask for a notification. >... > That being said, if we want to expose the > application to web browsers, the correct answer is > for the server to handle multipart/form-data, and > either respond with the answer, or response with a > form asking where the answer should be delivered. More or less my design also. And inventing a new protocol to do this would have only made your life harder. Working with sockets. No caching. Can't use PHP, Zope or JSP. Can't use web browsers. Would require a "client library" for each language. Etc. Etc. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Developers should be very careful here. All of > these methods are time dependent and there is no > guarantee that multiple idempotent requests won't > interfere with one another. Order matters. > > Suppose you decide to increment a value by 1 and > then by 100. Now suppose you GET the value 25. > You then PUT the value 26, but it fails so you > keep trying. While this is happening you GET the > value 25 again, and PUT the value 125. But the "failure" and "keep trying" parts have nothing to do with this problem. That's why I think it is orthogonal. Between your *original* GET and your PUT someone could have twiddled the data. Also, in this case it would probably be better to let the server merge the data using POST. Of course the lost update problem is unavaoidable when only the client can merge the data (i.e. with human authors). >... > Even if the server is issuing message-ids and only > processes RPOSTS in order of message-ids: > a. Nothing in the spec says that clients have to > use message-id's in the order in which they were > issued. Are we talking about multiple clients or a single client? If a single client then the single client can sychronize its own messages! Why should the server worry about that? If we're talking about multiple clients, then the service should be implemented so that order doesn't matter. If syncronization is important then I guess we need some kind of "lock" resources to keep clients in order. I can't think of an application of this off the top of my head. >... > 1. clients should issue their own message-ids. If > they don't want to get stepped on, they should > make them sufficiently unique (and secret). I'm not happy trusting the clients not to step on each other. > 2. reliable messaging looks like repeat requests To the server application it should not. The reliable messaging infrastructure (i.e. part of the web application framework) should merge them. > 3. you may want to support a seriality protocol in > which clients send a cardinality header (I haven't > decided if this should really be an ordinality > header, leaving the cardinality header for the > transaction protocols). I don't understand why the server is responsible for the client keeping its ducks in a row and I don't think that the clients should trust the server to verify the semantics of an "optional" header. Many servers could just let this pass quietly. Paul Prescod
Mark Baker wrote: > > > I agree that lost update is a problem. I don't see how it relates to > > "PUT also has side effects." Overwriting someone else's data is not a > > side effect in the traditional sense! > > > > Do you think that the issue is sufficiently related to reliability to > > mention it in that essay? > > Well, it's just that you said that you can keep invoking PUT over and > over, which is true, but you have to be aware that you may be stomping > over somebody else's changes. Yes, I think this relates to > reliability quite closely. Let me ask this the way I asked Alex. Is there anything about this problem that is *cause* by the repeat-try reliability solution that would not occur in a system that had inherently reliable once-only message delivery? Even in a perfect world where messages are delivered once and only once you can get the phantom write problem. PUTting over and over again may increase the chances just because of time passing but the problem is essentially the same. If I understand that correctly then I'll put in a footnote about that. Paul Prescod
Paul Prescod wrote: > If this turns out to be literally true, so that one day there is only > one TCP-based protocol then TCP won't be very useful. It's like an > operating system that can only be used for one application. Why not just > code the application to the bare metal if you're not amortizing any > costs. Answers: generality, simplicity, loose coupling. Think of how the filesystem namespace and the generic file io interface is (a) both a universal metaphor --- devices, versioning systems, servers, the process abstraction, virtual memory, network streams, etc. can and are all presented as "files" in the filesystem in various flavors of UNIX. (Many UNIX purists think that the introduction of a new namespace and API with Berkeley sockets was the beginning of the end; Plan 9 stands as a wonderful existance proof of the benefits of keeping everything in one namespace with a generic interface, sort of UNIX "as it should have evolved.") > On the other hand, I suspect that people will always resist > resource-modelling their application so TCP will be a rich home for RPC > applications forever. Quite possibly. It's unfortunate how much complexity people will wantonly introduce, for no good reason at all. :-( jb
Paul, Cleared off some time to take another look at your event spec thisevening, but looking at the list it seems that there's been a lot of discussion and feedback that would impact it; you've probably got more of a clear idea how the discussion has molded it. Here's a suggestion: how about we put it up on the REST Wiki? I'll be happy to transfer it over, format it, etc. Then, assuming everybody doesn't go morph the hell out of it, we can manage evolution of the document in place. Having this many interesting parties collaborate on a document online may be a bit of an exercise in discipline, but I think it's manageable. You? jb
Jeff Bone wrote: > Paul Prescod wrote: > > > If this turns out to be literally true, so that one day there is only > > one TCP-based protocol then TCP won't be very useful. It's like an > > operating system that can only be used for one application. Why not just > > code the application to the bare metal if you're not amortizing any > > costs. > > Answers: generality, simplicity, loose coupling. Think of how the > filesystem namespace and the generic file io interface is (a) both a Missed the (b) / second part: it also serves as a generic integration framework for plugging arbitrary components together. Much like the Web. :-) jb
Can we encourage people to add comments without changing the text until we've got some kind of consensus? Actually, I didn't go through the comments in detail yet because I thought you had write perms. The only ones that I thought through were: > Some comments; > > "X-Event-Subscription". How about just "Subscriptions", since > that better describes it's role; a container for subscriptions. * Sounds good to me. > If the Location header on a subscription response is a MAY, how does > one unsubscribe? Should also mention use of 200/201/204 response > codes on a POST action here too. * Location: should be at least a SHOULD if not a MUST * Mike D said an Unsub-URI: might be a good hack for servers that find resource modelling difficult * Mike D had about a hundred other suggestions that I haven't thought through yet. http://groups.yahoo.com/group/rest-discuss/message/198 http://groups.yahoo.com/group/rest-discuss/message/211 Paul Prescod
I'll transfer it over after dinner and make these changes in the process. We can't prevent people from mucking things up directly --- that openness is a part of the Wiki Way ;-) --- but we can ask them nicely to on the document. Also, our wiki has built-in versioning, so we can always trivially recover / roll back if somebody gets ugly. :-) jb Paul Prescod wrote: > Can we encourage people to add comments without changing the text until > we've got some kind of consensus? > > Actually, I didn't go through the comments in detail yet because I > thought you had write perms. The only ones that I thought through were: > > > Some comments; > > > > "X-Event-Subscription". How about just "Subscriptions", since > > that better describes it's role; a container for subscriptions. > > * Sounds good to me. > > > If the Location header on a subscription response is a MAY, how does > > one unsubscribe? Should also mention use of 200/201/204 response > > codes on a POST action here too. > > * Location: should be at least a SHOULD if not a MUST > > * Mike D said an Unsub-URI: might be a good hack for servers that find > resource modelling difficult > * Mike D had about a hundred other suggestions that I haven't thought > through yet. > > http://groups.yahoo.com/group/rest-discuss/message/198 > http://groups.yahoo.com/group/rest-discuss/message/211 > > Paul Prescod
> Mark Baker wrote: > > > >... > > > > But as I said, if you can use TCP, you can probably use HTTP. > > If this turns out to be literally true, so that one day there is only > one TCP-based protocol then TCP won't be very useful. It's like an > operating system that can only be used for one application. Why not just > code the application to the bare metal if you're not amortizing any > costs. You got it. Yes, it may allow for some interesting things to occur, such as replacing IP and DNS. > On the other hand, I suspect that people will always resist > resource-modelling their application so TCP will be a rich home for RPC > applications forever. Yah, just like all those renegade SNA and DECNET users. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> Let me ask this the way I asked Alex. > > Is there anything about this problem that is *cause* by the repeat-try > reliability solution that would not occur in a system that had > inherently reliable once-only message delivery? Even in a perfect world > where messages are delivered once and only once you can get the phantom > write problem. PUTting over and over again may increase the chances just > because of time passing but the problem is essentially the same. > > If I understand that correctly then I'll put in a footnote about that. Ah, well phrased. Yes, there's nothing special about the lost update problem with HTTP. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > >.... > > Missed the (b) / second part: it also serves as a generic integration framework > for plugging arbitrary components together. Much like the Web. I don't follow. If the interface all applications use for streamed processing is "httplib.HTTPConnection()" then why does anyone care whether TCP is underneath or not? Paul Prescod
(Btw, I decided to just call it HttpEvents for the time being, as that's a
valid Wikiword. Hope this doesn't offend, it's purely a pragmatic decision.)
I've copied Paul's HttpEvents spec (formerly YEHEA ;-) over to the REST
Wiki. The purpose of putting it there is to have a collaborative medium for
*writing the document.* It shouldn't take the place of *discussing those
changes* here on the list. I haven't made any substantive changes yet other
than the ones suggested by various folks and collected by Paul, mostly just
formatted for the Wiki.
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents
Fyi,
jb
Paul Prescod wrote: > > Missed the (b) / second part: it also serves as a generic integration framework > > for plugging arbitrary components together. Much like the Web. > > I don't follow. If the interface all applications use for streamed > processing is "httplib.HTTPConnection()" then why does anyone care > whether TCP is underneath or not? Nonononono... sorry, let me be more clear. People *don't* care if TCP is underneath, that's not the issue. I'm pointing out that HTTP etc. is a framework which allows arbitrary applications supporting a generic interface to be plugged together in arbitrary ways to achieve new functionality --- just like the filesystem namespace and file / stream- IO on UNIX. Consider the following: ls /foo > /tmp/foo; wc -l /tmp/foo What have I done there? I've *written a program* that counts the files in a particular directory, and I've done it by *composing* (plugging together) two different components that don't know anything about each other. How am I able to do that? Well, all resources in "true" UNIX (okay, so the paradigm didn't get pushed far enough until Plan 9, but anyway) are represented in the filesystem namespace and have a common generic interface: open, read, etc. They all look like named bytestreams. In a sense, the UNIX abstractions support a crude kind of compositional algebra of operations for stream processing. And this is a very powerful integration framework. The Web is similar, it's just harder to see because we don't have good dataflow / stream scripting tools and conventions. GET, PUT, DELETE, etc. are very analogous to the file IO system calls in UNIX. The fact that most people access the Web through more procedural interfaces (e.g. "httplib.HTTPConnection()") often obscures this fact, but it's a fact nonetheless. Application domains which are appropriately modeled as resources with appropriate semantics for the standard methods can therefore use each other in arbitrary and ad-hoc ways that the original developers didn't necessarily anticipate. The motivation for re-modeling various application domains as resources on the Web is much the same motivation for pushing all kinds of abstractions (such as the process table, network connections, etc.) into the filesystem in various UNIX variants: it lowers the cost of reusing / integrating those components. Sure, you can model your chat application as an entirely new protocol, but then it makes it harder to integrate with other things. Having HTTP as *the* one generic model for doing distributed computation *increases* the overall value of the Web, because it increases exponentially the number of connections available between network-available information and services, while at the same time vastly simplifying the process of plugging those things together. That's all I was pointing out. jb
Jeff Bone wrote: > Having HTTP as *the* one generic model for doing distributed > computation *increases* the overall value of the Web, Sorry, Internet. I.e., to the extent that the Web and the Internet become indistinguishable through the use of a global modeling paradigm and generic interfaces, it exponentially magnifies the value of the thing as a whole. Separate protocols increase balkanization and dimish total potential value. Metcalfe's, etc. jb
> Sorry, Internet. I.e., to the extent that the Web and the Internet become > indistinguishable through the use of a global modeling paradigm and generic interfaces, it > exponentially magnifies the value of the thing as a whole. Separate protocols increase > balkanization and dimish total potential value. Metcalfe's, etc. Yup, absolutely. 10 years from now, nothing but Web. That's when the fun begins. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Thu, 24 Jan 2002, Mark Baker wrote: > Alex, no offense dude, but you don't get REST yet. It would really > help things a lot in this discussion if you stopped pulling a Dave > Winer by thinking you understand it, and dismissing it so quickly > as unsuitable. Mark, please don't accuse me of pulling a Dave Winer :-) You would agree that it is possible to understand REST without agreeing that it is the solution to all problems. Unless REST is a religion, I think it comes down to this: 1. Is HTTP really the best model for your app. 2. If not, is it worth implementing in HTTP anyway to gain the advantages of reusability, interoperation, etc. I think there are many cases where it is not. I think many of your arguments in favor of HTTP are not in favor of a real HTTP but rather some hypothetical HTTP. That being said, I've learned a lot in this discussion and will strive to implement more consistently with HTTP in the future. > You're damned right. Putting something on the Web requires being able > to see things as a nail. Some things won't ever be nails, but with > REST, the vast majority of things can be seen as nails. Yes. I get this and agree. > > I don't deny that HTTP is a wonderful thing. > > However, I could quite reasonably make the claim > > that you can do everything you can do in HTTP > > using SMTP. > > Nope. How would you retrieve information with SMTP, without additional > a priori agreement? How do autoreplies work? Send an empty message to an email address and get an autoreply. There are lots of more sophisticated versions of this. Btw, implementing asynch with HTTP also requires prior agreement. > HTTP can use persistent connections on a GET to receive information. > This is safe if the information that's received isn't another protocol > (like an encapsulated message/http). Talk about HTTP abuse! Given that most real HTTP clients/servers will time out a connection, I think this one is impractical. Note, the reason for closing connections is that holding open a thread or child process(!!) for each client is expensive. In theory one could design a special purpose web server that does polling, but that is not the same one you would use for CGI or servlets. Once you have to write your own HTTPd for the application, re-using HTTP seems much less exciting. > But you first have to model your presence app as a set of resources. > e.g. each user gets a URI, a persistent GET to that URI returns a > stream of presence messages as their presence status changes, etc.. Again, that may be, but since you also have to write a custom client, I don't see the bonus of HTTP here. A simpler approach might just be to have the client open a socket connection with some auth information, and to multiplex chat messages back and forth on that socket. You might argue that the HTTP approach is better because it is more likely to get through the firewall. However, it is equally likely that the firewall will shut down excesively long HTTP connections. > > Even in traditional client/server (long > > connections), there was nothing that prevented > > this from happening. Its just that the protocol > > itself is defined in terms of clients making > > requests of servers. > > Name a protocol that doesn't work this way. That is my point. Doing P2P with HTTP also requires "additional a priori agreement." You seemed to be claiming otherwise. My general point then is that once you require a priori agreement, you might as well use protocols for which that a priori agreement is already well defined. For messaging, that would be SMTP. For news distribution, that would be NNTP For presence, it need not be HTTP and it might very well be IRC. > > Ok, name an app that can't be modelled as a set of > > email addresses. > > The Web. See above, re auto-replies. > > The issue is whether the app SHOULD be modelled as > > a set of HTTP resources or a email addresses or > > whatever. > > In part, that's true. But often (unless you've been doing this as long > as I have 8-), you won't know until you try. You're not even trying. I am trying. But in general I am trying to use whatever protocol people are already using for whatever I am doing. > > Congratulations. Looks cool. Doesn't mean that > > was the best way to go. For example, would you > > use HTTP for an IM client (if you needed to > > support large numbers of them)? Having millions > > of clients polling for messages seems like a bad > > idea. > > If I could offload to a proxy farm, sure. Proxies are an integral part > of REST for this and other reasons. My point is that you would rather design a protocol that doesn't impose so much load on your server. I'd rather run 1 presence server on my own protocl than 10 proxy servers using HTTP. > But as I said, if you can use TCP, you can probably use HTTP. Can that > IM app use TCP? Sure. Client keeps a socket open. Server watches TCP to make sure the connection is still open. This is hugely lighter weight than your HTTP implementation. > > I'm not sure you read the problem correctly. > > > > The client is simply making a query to the server > > and getting a yes/no response. > > > > In other words, it is making an idempotent > > request. > > You mean that if a picture of a terrorist was submitted, that nobody > would want to store it? Seriously? The client stores it and has procedures for delivering the message to the master terrorist database if recognition happens. The local terrorist server has a local copy of the database. (whatever). > If there is a chance that it might not be idempotent, then you have to > use POST. Your talking about a different application. > But as Paul and I discussed a while ago, HTTP is missing a method to > support idempotent operations on content, like transcoding or whatever. > This is not a failing in REST, it is a missing feature of HTTP, but it > could easily be added. But it not part of HTTP!!! There is the theory of HTTP and the reality of the HTTP protocol and the further reality of its implementations. > That is, other idempotent requests are fine (OPTIONS is one), so long as > it doesn't act on the information space formed by GET, and that GET > remains the only method used for URI resolution (i.e. when you click on > a URI, it can only ever mean GET). A new idempotent data submission > method would be fine. If you are using POST then you lose the benefit of caching and therefore much of the benefit of HTTP. But, more to the point, sending multiple pictures to a server is NOT modeling the application as a set of resources (whether you use GET or POST). It is a form of RPC! > > The server may take a long time to respond to > > the query so it may issue a 202 Accepted. But, > > if it does, then we also need a convention for > > delivery of the reply. > > One convention is described in RFC 2616. Put a URI in the body of > the 202 response that represents the completed request. HTTP doesn't deliver. RFC2616 is incredibly vague on this issue. The result is that applications are forced into a priori negotiations. I am trying, in MIME-RPC to firm it up, so that two applications written by strangers can talk to each other. Do you have a better idea? > > I think MIME-RPC provides these conventions and > > allows this application to be deployed over > > SMTP almost exactly as it would be deployed over > > HTTP. > > That's because you're building a new protocol and tunneling it over > SMTP and HTTP. i.e. you're disregarding the view of the world that > each of these other application protocols attempts to enforce. > You've also got a hammer it seems; one that likes to flatten > everything to ensure a consistent view of the world. 8-) MIME-RPC isn't really a new protocol. It is just a recognition that we are all already using MIME and should enjoy it with the transport that makes sense for your application. RFC2045: When you want asynchronous messaging, send MIME over SMTP RFC2616: When you want to do synchronous messaging, send MIME over HTTP. RFC977: When you want to distribute/replicate messages, use MIME over NNTP RFCxxx: When you want to do p2p messaging, send MIME over ____? This is the Internet. I'm just pointing it out. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Jeff Bone wrote: > > Paul Prescod wrote: > > > > Missed the (b) / second part: it also serves as a generic integration framework > > > for plugging arbitrary components together. Much like the Web. > > > > I don't follow. If the interface all applications use for streamed > > processing is "httplib.HTTPConnection()" then why does anyone care > > whether TCP is underneath or not? > > Nonononono... sorry, let me be more clear. People *don't* care if TCP is underneath, > that's not the issue. .... etc. etc.... Whoa, Jeff. Are you in FoRK withdrawl? The question was whether it made sense in the future to merge TCP and HTTP so as to get rid of the extra overhead of TCP. As long as there are many TCP protocols, the TCP layer is a useful common basis. When there is only one application protocol it makes sense to optimize away the generality underneath it. Paul Prescod
On Thu, 24 Jan 2002, Paul Prescod wrote: > There is always a gap between one model and another. The problem is > we've learned to think about it one way and now we must learn to think > about it another. If you taught someone REST and you taught them sockets > and asked them to invent an email system I think they would find it > easier to do it using HTTP and REST. The more comparable example is if you asked them to set up an asynchronous peer to peer messaging system (aka email). Would they choose HTTP or SMTP? > > The idea is that security checkpoints send front > > and side views of individuals to some server and > > the server sends back information about whether > > the person looks like a known terrorist in the > > database. > > > If you want a web interface then you can use a POST form. See my reply to MB. This is not modeling the application in terms of resources. It is RPC. Returning a URL and then asking the client to watch the new URL seems like a lot of overhead and waste. > The client may also want an asyncronous notification of when this status > resource changes. In the interests of layering and distribution of > processing, I would think of this as a completely unrelated part of the > system. Some clients could poll. Others could ask for a notification. > Maybe the resource for status and for the final result should be > separate...I can't see big tradeoffs one way or the other off the top of > my head. Good argument, but the polling is ugly. A callback system is much nicer and much ligher on system resources! > Conventions for asyncronous notification are here: > > * http://www.prescod.net/HTTP_event_conventions.html Ok. So that is another new protocol. It is not real life HTTP. It also seems no better than just sending a reply-to in the first place. > Anyhow, that's how I would model it. Notice how I try to think about the > web interface at each step. I am doing the same thing. The whole point of MIME-RPC is to model the web interface. Which uses MIME rather than SOAP or XML-RPC. > As these pictures are large, you might want to consider allowing users > to submit some kind of a hash to check if the picture is already on the > site. Again, the pictures are taken at the client site so the server won't have copies. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 24 Jan 2002, Paul Prescod wrote: > > That being said, if we want to expose the > > application to web browsers, the correct answer is > > for the server to handle multipart/form-data, and > > either respond with the answer, or response with a > > form asking where the answer should be delivered. > > More or less my design also. And inventing a new protocol to do this > would have only made your life harder. Working with sockets. No caching. > Can't use PHP, Zope or JSP. Can't use web browsers. Would require a > "client library" for each language. Etc. Etc. I am all in favor of using existing protocols. I want to use HTTP for request/response and SMTP for asynch. I want to use MIME as the content for both. What you are missing is that the browser post is RPC! -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 24 Jan 2002, Paul Prescod wrote: > But the "failure" and "keep trying" parts have nothing to do with this > problem. That's why I think it is orthogonal. Between your *original* > GET and your PUT someone could have twiddled the data. The point is that HTTP does not promise to be "Reliable" Your spec does. > > Even if the server is issuing message-ids and only > > processes RPOSTS in order of message-ids: > > a. Nothing in the spec says that clients have to > > use message-id's in the order in which they were > > issued. > > Are we talking about multiple clients or a single client? If a single > client then the single client can sychronize its own messages! Why > should the server worry about that? Even if with a single client. The server is not guaranteeing to process messages in any order at all! Assuming the server issues sortable message ids, and the client sends them in order. How should the server handle recieving: RPOST 4 Jane RPOST 2 Tarzan RPOST 3 You RPOST 1 Me > If we're talking about multiple clients, then the service should be > implemented so that order doesn't matter. If syncronization is important > then I guess we need some kind of "lock" resources to keep clients in > order. I can't think of an application of this off the top of my head. This is a chat application. The Posts append messages to a chat window. The user is typing: Me Submit Tarzan Submit You Submit Jane Submit You need to handle order in a reliable protocol. > >... > > 1. clients should issue their own message-ids. If > > they don't want to get stepped on, they should > > make them sufficiently unique (and secret). > > I'm not happy trusting the clients not to step on each other. Message Ids and passwords are no different. As long as you don't leak message-ids among clients you are safe. A client that wants security just issues a sufficiently random message-id. (You trust clients to be safe with their passwords too). > > 2. reliable messaging looks like repeat requests > > To the server application it should not. The reliable messaging > infrastructure (i.e. part of the web application framework) should merge > them. Yes. I agree. This was just shorthand. > > 3. you may want to support a seriality protocol in > > which clients send a cardinality header (I haven't > > decided if this should really be an ordinality > > header, leaving the cardinality header for the > > transaction protocols). > > I don't understand why the server is responsible for the client keeping > its ducks in a row and I don't think that the clients should trust the > server to verify the semantics of an "optional" header. Many servers > could just let this pass quietly. See above re "Me Tarzan, You Jane" -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 24 Jan 2002, Paul Prescod wrote: > Is there anything about this problem that is *cause* by the repeat-try > reliability solution that would not occur in a system that had > inherently reliable once-only message delivery? Even in a perfect world > where messages are delivered once and only once you can get the phantom > write problem. PUTting over and over again may increase the chances just > because of time passing but the problem is essentially the same. HTTP does not claim to be Reliable. Idempotency is irrelevant. You need Reliability on all methods. You might want to call the protocol Reliable Delivery of POST requests. But even then, you still need a semantic for delivery failure (which MAY happen). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > Note, the reason for closing connections is that > holding open a thread or child process(!!) for > each client is expensive. The KnowNow servers supposedly does 10K clients per Solaris box. I don't know if that is expensive or not. [honest, i'm not trying to plug them, but they're the only example of http events that I can point to with any amount of understanding] > > > But you first have to model your presence app as a set of resources. > > e.g. each user gets a URI, a persistent GET to that URI returns a > > stream of presence messages as their presence status changes, etc.. > > Again, that may be, but since you also have to > write a custom client, I don't see the bonus of > HTTP here. I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was 'custom', but I can now give it away to 10K script kiddies to innovate with. Change graphics, chat with their thermometers, etc. The bonus is that the client is just like 10 million other clients, with a large support staff - all are different dynamically loaded modules within the WebApp called WWW.
On Thu, Jan 24, 2002 at 11:34:48PM -0800, S. Mike Dierken wrote: > > Note, the reason for closing connections is that holding open a > > thread or child process(!!) for each client is expensive. > > The KnowNow servers supposedly does 10K clients per Solaris box. I don't > know if that is expensive or not. > [honest, i'm not trying to plug them, but they're the only example of http > events that I can point to with any amount of understanding] A decent event loop/queue (different kind of event ;) could easily scale to many tens or even hundreds of thousands of open connections; you're really only limited by memory... -- Mark Nottingham http://www.mnot.net/
On Thu, 24 Jan 2002, S. Mike Dierken wrote: > > Note, the reason for closing connections is that > > holding open a thread or child process(!!) for > > each client is expensive. > The KnowNow servers supposedly does 10K clients per Solaris box. I don't > know if that is expensive or not. > [honest, i'm not trying to plug them, but they're the only example of http > events that I can point to with any amount of understanding] I just took a look at the two knownow demos... If you are talking about the knownow web clients, they don't open a peristent GET, they just make repeated requests, (polling the server). This is a workaround for the lack of sockets in javascript. And is much less efficient than a straight socket conection would be. If you are talking about the knownow event routers, it sounds like they are implementing listservs. If they are sending out 10k concurrent email messages, that is very nice. If they are sending out only 100-1000 concurrent messages and just claim a max of 10k listeners, that is incredibly unimpressive. Either way, this has little to do with persistent GET and the merits of HTTP for presence applications. The main point is that HTTP is suboptimal for this application (but you may need it if the client is a web browser). > > Again, that may be, but since you also have to > > write a custom client, I don't see the bonus of > > HTTP here. > I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was > 'custom', but I can now give it away to 10K script kiddies to innovate with. > Change graphics, chat with their thermometers, etc. > The bonus is that the client is just like 10 million other clients, with a > large support staff - all are different dynamically loaded modules within > the WebApp called WWW. Yeah. Me too. How many chat clients can your web server support? According to (1), a typical test Apache server can handle ~250 requests per second. Assuming your clients poll once per second, you max out at 250 simulatenous clients. That sucks! Even if your server could handle higher capacity the bandwidth of handling large numbers of pings will also eventually overwhelm you. Alternatively, you could also document a more scalable protocol like Jabber, IRC, or Kazaa, give away the source, get the same hackers to work on it, and perhaps get bought by AOL! -Alex- (1) http://www.acme.com/software/thttpd/benchmarks.html ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul Prescod wrote: > Whoa, Jeff. Are you in FoRK withdrawl? Quite possibly. I'll be headed to the methadone clinic shortly to help avoid similar withdrawal today. ;-) (I misparsed your original point.) jb
> The main point is that HTTP is > suboptimal for this application HTTP is suboptimal for *all* applications. You can *always* do better performance wise by building an application protocol specific to the task. The issue is, what can be gained by sacrificing this ability and optimizing for the general case instead? As it turns out, a whole freaking lot. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Fri, 25 Jan 2002, Mark Baker wrote: > > The main point is that HTTP is > > suboptimal for this application > > HTTP is suboptimal for *all* applications. You can *always* do better > performance wise by building an application protocol specific to the > task. The issue is, what can be gained by sacrificing this ability and > optimizing for the general case instead? As it turns out, a whole > freaking lot. 1 server versus 100 servers seems like a good reason not to use HTTP for presence/chat. If I were doing asynch, I would much rather reuse the very well tested and widely deployed SMTP infrastructure than a new HTTP infrastructure. For Reliable delivery (a subcategory of Asynch), I would again rather rely on SMTP than HTTP. For the basic terrorist_or_not.com, HTTP is a great protocol, but, as we have seen, REST is not. For many applications, RPC (over HTTP) makes sense, but REST does not. So... Sometimes you don't want HTTP. Sometimes you want HTTP, but not REST. Sometimes you want HTTP and REST. As always, you do what makes sense for your application. YMMV. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I'm a REST newbie, but I've been following the discussions here, and thinking about event delivery in other contexts as well. I'm posting this not some much as serious proposal to enhance the spec, but more to get some feedback on whether I'm "getting" REST. In Paul's spec at http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents, the various scenarios all involve using the Event-Target header to specify a URI where events will be delivered. This URI might be a micro server on the application client, or a third party event queuing/forwarding service. One additional scenario occurred to me. Suppose the server application is willing to queue events for the client. In that case, the Client could POST to the Subscription URI without the Event-Target header. The response to the Subscription would still include the Location: header (a URI that represents the subscription). The Client would then POST to the subscription URI to retrieve queued events, or DELETE to end the susbscription. I originally was thinking that the client could GET the subscription URI in order to retrieve queued events, but now I think that that would be wrong, because a GET in this case would change the state of the resource by returning any queued events. I suppose a GET might instead return an HTML page or XML document describing the current supscription state. So, does this proposal make sense? If not, I'd like to learn where I went wrong. Thanks, Jim Ancona jim@...
"S. Alexander Jacobson" wrote: > 1 server versus 100 servers seems like a good > reason not to use HTTP for presence/chat. There's no data to support that assertion -wrt- scaling in that application context. > If I were doing asynch, I would much rather reuse > the very well tested and widely deployed SMTP > infrastructure than a new HTTP infrastructure. Me to. But no new HTTP infrastructure is needed, really. > For Reliable delivery (a subcategory of Asynch), I > would again rather rely on SMTP than HTTP. Okay. > For the basic terrorist_or_not.com, HTTP is a > great protocol, but, as we have seen, REST > is not. You want to run that through by me again? REST is the overall architectural style of HTTP. I don't see how you distinguish the two. > For many applications, RPC (over HTTP) makes > sense, but REST does not. It only makes sense because you don't understand REST yet. ;-) jb
One terminological suggestion, two problems, two suggested solutions. Suggestion: rather than calling the target of event notifications an "event target" why not reify the notion of the subscriber and simply call the header that indicates that URI "Subscriber"? NB: we should probably work on making terminology consistent with the general metaphors, roles, and activities of pub / sub. ---- Subscription lifetimes are problematic. They shouldn't last forever; doing so places an undue and unnecessary burden on the resource in question. The server for a subscribable resource (Publisher?) should be able to indicate when a subscription expires, and should provide a mechanism by which the subscriber can renew the subscription. (Note that this is an *extremely* useful concept in modeling presence, for example. It's also simply a good idea rom a robustness and scalability perspective.) Suggested solution: when a Subscriber (client) obtains a subscription via the URI indicated in the "Subscription" header, the response SHOULD contain a header "Expiration" which indicates when the subscription expires. If an Expiration is indicated, the Subscriber MUST "renew" the subscription at some point before the Expiration date in some fashion. (How? Presumably via a POST of some sort to the particular subscription's Location: URI?) If a Subscriber fails to renew a subscription by the indicated expiration, the server MAY at any subsequent point remove the subscription resource and stop sending notifications to the Subscriber. ---- The mechanism Paul describes is potentially very dangerous; it needs a kind of authentication beyond simple principal / session authentication. Consider: Mallory wants to DoS Alice. To do so, Mallory subscribes to Bob, but gives Alice's URI to Bob as the Subscriber / EventTarget. Even if Bob authenticates Mallory --- indeed, even if Mallory is a valid user from Bob's perspective --- that still doesn't prevent Mallory from using Bob to attack Alice. Somehow, the "client" that requests a subscription needs to be verifiably the "same" in some sense as the Subscriber / EventTarget. Suggested solution: the response to the Subscription POST SHOULD contain a SubscriptionID header with some arbitrary token. The Subscriber MUST return this header in the responses to all notifications POSTED by the Publisher (server) to the Subscriber URI. The Publisher MAY delete any subscription and cease notifications for any Subscriber that fails to return the appropriate SubscriptionID in the response to any notification. ---- $0.02, jb
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > I just took a look at the two knownow demos... > If you are talking about the knownow web clients, > they don't open a peristent GET, they just make > repeated requests, (polling the server). This is > a workaround for the lack of sockets in > javascript. And is much less efficient than a > straight socket conection would be. They use a persistent response. If the connection is closed, they re-open it. That might be where the 'repeated requests' are coming from. Those are very infrequent. > > If you are talking about the knownow event > routers, it sounds like they are implementing > listservs. If they are sending out 10k concurrent > email messages, that is very nice. If they are > sending out only 100-1000 concurrent messages and > just claim a max of 10k listeners, that is > incredibly unimpressive. Oh. Remember, I don't have real numbers as I do not work there - it could be bigger and I would have no way of knowing. These are 10K concurrent listeners, I don't know the fan-out of an event (how many listeners per event average). This is only one node in a cluster - I don't know that there is a limit to the cluster size. > > Either way, this has little to do with persistent > GET and the merits of HTTP for presence > applications. The main point is that HTTP is > suboptimal for this application (but you may need > it if the client is a web browser). If the client were another server, would http be sufficient? > > > > Again, that may be, but since you also have to > > > write a custom client, I don't see the bonus of > > > HTTP here. > > I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was > > 'custom', but I can now give it away to 10K script kiddies to innovate with. > > Change graphics, chat with their thermometers, etc. > > The bonus is that the client is just like 10 million other clients, with a > > large support staff - all are different dynamically loaded modules within > > the WebApp called WWW. > > Yeah. Me too. How many chat clients can your web server support? 10,000. Like I said, the KN server can handle 10k concurrent browser clients per cluster node. > According to (1), a typical test > Apache server can handle ~250 requests per second. > Assuming your clients poll once per second, you > max out at 250 simulatenous clients. That sucks! Yeah - good thing nobody except strawman.org does that. > Even if your server could handle higher capacity > the bandwidth of handling large numbers of pings > will also eventually overwhelm you. > > Alternatively, you could also document a > more scalable protocol like Jabber, IRC, or Kazaa, > give away the source, get the same hackers to > work on it, and perhaps get bought by AOL! Or examine your assumptions. Nobody here is suggesting polling is the preferred way to go. A server that transparently handled polling for backward compatibility would help in many situations, as long as the scalability/traffic problems don't surface.
----- Original Message ----- From: "Jeff Bone" <jbone@...> > > The mechanism Paul describes is potentially very dangerous; it needs a > kind of authentication beyond simple principal / session > authentication. Very good point. > Consider: Mallory wants to DoS Alice. To do so, > Mallory subscribes to Bob, but gives Alice's URI to Bob as the > Subscriber / EventTarget. Even if Bob authenticates Mallory --- indeed, > even if Mallory is a valid user from Bob's perspective --- that still > doesn't prevent Mallory from using Bob to attack Alice. Somehow, the > "client" that requests a subscription needs to be verifiably the "same" > in some sense as the Subscriber / EventTarget. > > Suggested solution: the response to the Subscription POST SHOULD > contain a SubscriptionID header with some arbitrary token. The > Subscriber MUST return this header in the responses to all notifications > POSTED by the Publisher (server) to the Subscriber URI. The Publisher > MAY delete any subscription and cease notifications for any Subscriber > that fails to return the appropriate SubscriptionID in the response to > any notification. > Another way to think about this particular approach of creating subscriptions is that it is creating a 'route' from a source to a target. The agent creating that route needs permissions to read from the source and write to the target. In addition, since the target is receiving information about the source, the target needs permissions to read from the source. And if the permissions change, then the 'route' needs to be updated to reflect that - for example if Alice is denied permission to read the source, the route/subscription should be disabled (if you can't 'see' a resource, you shouldn't be able to 'hear' it either). (you can argue that it should be deleted, but re-enabling permissions isn't going to tell you what subscriptions need to be re-created.) details details...
"S. Alexander Jacobson" wrote: > > On Thu, 24 Jan 2002, Paul Prescod wrote: > > There is always a gap between one model and another. The problem is > > we've learned to think about it one way and now we must learn to think > > about it another. If you taught someone REST and you taught them sockets > > and asked them to invent an email system I think they would find it > > easier to do it using HTTP and REST. > > The more comparable example is if you asked them > to set up an asynchronous peer to peer > messaging system (aka email). Would they choose > HTTP or SMTP? If they understood REST I think that they would choose HTTP. Better applications can be built if you model data elements and processes as resources rather than endpoints. If you're building a *new* application then you need to write the software on the client and server sides anyhow. We all know how little effort it takes to put HTTP on the client side. I've shipped products with HTTP servers written in four different languages. >... > > If you want a web interface then you can use a POST form. > > See my reply to MB. This is not modeling the > application in terms of resources. It is RPC. I don't know why you say it is RPC. The definition in my mind of RPC is that the incoming message has a tag or identifier that instructs the server what to do with it. But this "endpoint" resource would have one and only one task. It would expect the input to be appropriate for that task. > Returning a URL and then asking the client to > watch the new URL seems like a lot of overhead and > waste. No, it is just a separation of concerns. Yes it takes more round-trips than the SMTP system. It is also much more functional. The client can check for status whenever it wants. Other clients can be attached to the *same* computation because it is a first-class resource. Clients can share information about what computations they are watching by sharing the URI. Disconnected clients have the option of polling which they do not with SMTP (unless there is a mailbox intermediary). >... > Good argument, but the polling is ugly. A > callback system is much nicer and much ligher on > system resources! The point is that the same system could support *both*. This would be much harder to do with SMTP. > > Conventions for asyncronous notification are here: > > > > * http://www.prescod.net/HTTP_event_conventions.html > > Ok. So that is another new protocol. It is not > real life HTTP. If I use XHTML or RSS am I using XML? It is real life HTTP up until the point that where I start doing things against the HTTP model such as inventing private namespaces or telling the server what to do through method names or using POST for logical queries. > ... It also seems no better than just > sending a reply-to in the first place. If you just send a reply-to then the client and server have no mutually visible resource that represents the transaction. That means that the client can't monitor it. The client can't cancel it. You could invent some kind of UUID system but now you're inventing a private namespace. > > Anyhow, that's how I would model it. Notice how I try to think about the > > web interface at each step. > > I am doing the same thing. The whole point of > MIME-RPC is to model the web interface. Which > uses MIME rather than SOAP or XML-RPC. When I say "web interface" I mean HTML web application. Paul Prescod
"S. Alexander Jacobson" wrote: > > ... > > Even if with a single client. The server is not > guaranteeing to process messages in any order at > all! > > Assuming the server issues sortable message ids, > and the client sends them in order. How should > the server handle recieving: > > RPOST 4 Jane > RPOST 2 Tarzan > RPOST 3 You > RPOST 1 Me Why would a single client CHOOSE to send the messages in the wrong order???? I need you to explain why the client is not written so that the RPOST 3 message always comes after the RPOST 2 message and before the RPOST 4 message. The "default" way to write such an application would be to fully handle one message before even considering the next. I don't see how this is the server's responsibility. Paul Prescod
scarhill wrote: > > ... > One additional scenario occurred to me. Suppose the server application > is willing to queue events for the client. In that case, the Client > could POST to the Subscription URI without the Event-Target header. > The response to the Subscription would still include the Location: > header (a URI that represents the subscription). The Client would then > POST to the subscription URI to retrieve queued events, or DELETE to > end the susbscription. You could certainly define a web service this way. I am on the fence about whether it makes sense to handle this case in the general spec instead of simplifying things by requiring the Queue to be a separate component. It could go either way. > I originally was thinking that the client could GET the subscription > URI in order to retrieve queued events, but now I think that that > would be wrong, because a GET in this case would change the state of > the resource by returning any queued events. I would prefer to make each event into a separate resource and do a GET/DELETE on that resource. The top-level subscription resource would contain an index of these sub-resources. Paul Prescod
On Fri, Jan 25, 2002 at 08:41:52AM -0500, S. Alexander Jacobson wrote: > > Yeah. Me too. How many chat clients can your web > server support? According to (1), a typical test > Apache server can handle ~250 requests per second. > Assuming your clients poll once per second, you > max out at 250 simulatenous clients. That sucks! [..] > (1) http://www.acme.com/software/thttpd/benchmarks.html Err, that's hits per second, not concurrent connections. You're using a benchmark of Apache by an Apache competitor as an indication of how all Web servers perform in general? Tsk. It's widely acknowledged that Apache is performance-limited, in a trade-off for stability, developability, etc. Let me be more explicit: I know of at least two vendors who have HTTP implementations that can handle 50,000+ concurrent persistent connections on commodity hardware. It's much more instructive to look at intermediary implementations when you're talking about the performance overhead of HTTP; they're more optimised for performance, and they're not doing anything with the payload; it's all just overhead. It's relatively easy to achieve 1000+ reqs/sec [1]. Most modern HTTP intermediaries can approach or exceed wire speed. I'd note that these numbers don't include any of the larger commercial vendors (with more developed implementations) who participated in past years, but now don't want their numbers made public, as it starts a performance war... [1] http://www.measurement-factory.com/results/public/cacheoff/N04/raw.html -- Mark Nottingham http://www.mnot.net/
--- Paul Prescod <paul@...> wrote: > I would prefer to make each event into a separate resource and do a > GET/DELETE on that resource. The top-level subscription resource would > contain an index of these sub-resources. So how would the client find out which event resources were available? By doing a GET on the top-level subscription resource? Then it would have to do a GET/DELETE on each event. Sounds like a lot of round trips. Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
"S. Alexander Jacobson" wrote: > > On Thu, 24 Jan 2002, Paul Prescod wrote: > > But the "failure" and "keep trying" parts have nothing to do with this > > problem. That's why I think it is orthogonal. Between your *original* > > GET and your PUT someone could have twiddled the data. > > The point is that HTTP does not promise to be > "Reliable" Your spec does. I guess we have a different definition of reliable. I mean that the message gets through. I consider ordering issues to be orthogonal. Part of the web zen is loose coupling between components. If responsibility for ordering can be pushed off completely onto the client then I think it should be. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > HTTP does not claim to be Reliable. Idempotency > is irrelevant. You need Reliability on all > methods. Idempotency is relevant. I'm trying to define the minimum "protocol" extension needed to allow once and only once delivery. Idempotency means that I need do nothing with GET and PUT because by definition, eleven deliveries are the same as one. Locking, ordering, lost updates etc. are all orthogonal issues. > You might want to call the protocol Reliable > Delivery of POST requests. But even then, you > still need a semantic for delivery failure (which > MAY happen). The client will know if it failed to deliver. How coud the protocol help? You want an HTTP server to report to an HTTP client that the network cable is unplugged? Paul Prescod
> > I originally was thinking that the client could GET the subscription > URI in order to retrieve queued events, but now I think that that > would be wrong, because a GET in this case would change the state of > the resource by returning any queued events. I suppose a GET might > instead return an HTML page or XML document describing the current > supscription state. > If you ensure multiple GETs don't pop the head off the queue then you can use it. You'd need an explicit 'ack' to pop the head off the queue. Perhaps DELETE would do it, but I don't know whether that is correct or not - whether that breaks the 'queue modelled as a resource' concept. GET returning an explicit list of messages with ids might be more resty... hard to say.
HTTP callbacks create new security issues. In the following message I present an orderly way to approach those issues. An HTTP request is asymetric with regard to state. Client state is opaque, except that it must have enough state to interpret a response. Server state is exposed using HTTP methods. Clients have always been less prone to security problems than servers, because they expose so much less state. The only client resource exposed is the state machine that performs the request. For a callback sink to be no less secure than a client request, the only resource the sink can expose is a similar state machine. What's in that state machine? There is a contractual obligation to perform standard syntactic operations like reading the number of bytes specified in the Content-Length response header. There is implicit knowledge of a reader process with an open socket, some memory allocated, maybe some access restrictions. There is implicit knowledge of context: the reader assumes that the writer is the same process it initially contacted. Etc -- this is not an exhaustive list. One thing that is not exposed is information about the sink state after the transaction is completed. Any approach to callbacks that directly addressed security could be evaluated by comparison with the above baseline. For the purpose of doing such an evaluation, it is useful to define a new pseudo-method as follows: this method exposes no more server state than is in a requester state machine. A reasonable name for this pseudo-method is NOTIFY. A NOTIFY method MAY affect any properties of sink state that a response MAY affect; it MUST affect any elements of sink state that a response MUST affect; etc. NOTIFY is not necessarily a new actual method. It is just a convenience for discussion. It should be possible to define it as a synonym for existing HTTP operations. For example, we might be able to POST to a well-known list of properties, with one property for every aspect of a requester state machine. EG, POST $root_uri/properties/headers/Content-Length/ HTTP/1.1 POST $root_uri/properties/assumptions/source_identity/ HTTP/1.1 POST $root_uri/properties/states/message_send_complete/ HTTP/1.1 A sink MUST NOT expose any properties that a request state machine wouldn't. So, to the degree that properties of request state machines can be known in advance, the list of exposable properties can be known in advance. A source MUST NOT POST a value to $root_uri/properties/headers/ that would not be a legal value in a response header. A sink MUST accept any value in $root_uri/properties/headers/ that would be a legal value in a response header. Given this equipment, we can place Jeff's comments about authentication and expiration. Expiration is the inverse of caching, therefore sink URIs and values related to expiration would be defined based on cache-response-directives in section 14.9 of RFC 2616. A requester can assume authentication, but a callback sink can't. (There are probably other assumptions in the state machine of a requester.) These can be tackled one by one and addressed by a URI hierarchy exposing them as properties. EG, POST $root_uri/properties/assumptions/source_identity/ HTTP/1.1 Some miscellaneous comments: * Mike Dierken's reply-in-request is an obvious reference point here. It strikes me as surprizingly sensible now. * It is unavoidable for the state machine that accepts POST callbacks at the sink to leak state in a different way from the state machine of a requester. However, well-made HTTP servers should already keep this leakage to a minimum, since they are necessarily more paranoid than HTTP clients. Summarizing, exposed sink properties must be a small and strictly limited subset of all POSTable properties. Given that exposed sink properties are a 1-1 match with reply properties, then it should be possible to perform callbacks without creating new security leaks. - Lucas
Jim Ancona wrote:
>
> --- Paul Prescod <paul@...> wrote:
> > I would prefer to make each event into a separate resource and do a
> > GET/DELETE on that resource. The top-level subscription resource would
> > contain an index of these sub-resources.
>
> So how would the client find out which event resources were available? By doing
> a GET on the top-level subscription resource? Then it would have to do a
> GET/DELETE on each event. Sounds like a lot of round trips.
With persistent connections, I don't think that this is any worse than
POP or IMAP. Actually consider this level of chatter:
+OK paulp has 9 visible messages (0 hidden) in 29777 octets.
448: Client to Server (6 bytes)
STAT
448: Server to Client (13 bytes)
+OK 9 29777
448: Client to Server (6 bytes)
LIST
448: Server to Client (39 bytes)
+OK 9 visible messages (29777 octets)
448: Server to Client (75 bytes)
1 4107
2 3284
3 3819
4 2889
5 2966
6 3219
7 1792
8 3724
9 3977
.
448: Client to Server (6 bytes)
UIDL
448: Server to Client (28 bytes)
+OK uidl command accepted.
448: Server to Client (219 bytes)
1 dNS"!H~+!!9o>!!Qj("!
2 73n"!p2<!!(h\"!m*(!!
3 B#<"!<!g!!XZ&#!5*&"!
4 -P^"!-L6!!^i7"!4>]!!
5 ZT%#!nTH"!P0)#!PMI!!
6 Z(`"!K\>!!<JS"!~aD"!
7 [A["!GP`!!)\c"!+=V"!
8 *aV"!m2E"!7YO"!nLF"!
9 CE+!!mAH!!DEG!!["_!!
.
448: Client to Server (8 bytes)
RETR 1
448: Server to Client (17 bytes)
+OK 4107 octets
Paul Prescod
> > So how would the client find out which event resources were available? By doing > a GET on the top-level subscription resource? Then it would have to do a > GET/DELETE on each event. Sounds like a lot of round trips. > Round trips are needed for reliability - confirming that the message actually made it down to the client and was successfully processed. You could PUT a status of 'accepted' on inital delivery and after some time passes do a final ack via DELETE. (or use PUT for both and have the collection defined to be messaging only in a certain state, or not, and have the client filter... lots of choices)
> Another way to think about this particular approach of creating > subscriptions is that it is creating a 'route' from a source to a target. > The agent creating that route needs permissions to read from the source and > write to the target. In addition, since the target is receiving information > about the source, the target needs permissions to read from the source. And > if the permissions change, then the 'route' needs to be updated to reflect > that - for example if Alice is denied permission to read the source, the > route/subscription should be disabled (if you can't 'see' a resource, you > shouldn't be able to 'hear' it either). (you can argue that it should be > deleted, but re-enabling permissions isn't going to tell you what > subscriptions need to be re-created.) > details details... All good thoughts. For the most generic purposes, though, I think this is more complexity than is required. It takes the task out of the realm of simple authentication --- not of principal but of transaction --- and into a realm of authentication + authorization. (To clarify the distinction: authentication is proving continuity of identity for some purpose, authorization is deciding whether / proving that some authenticated principal has permission to do something.) With a scheme similar to the one I proposed, you're only doing the most basic kind of authentication --- you're simply proving that the Subscriber event sink "knows" and (continuously) "approves of" the subscription that was requested on its behalf. With Mike's more sophisticated scheme, it seems that you need to introduce some notion of permissions and authorization vis-a-vis those permissions. This may be useful or even necessary for some applications, but IMO it's not really necessary for the most basic uses of HttpEvents. And, it can be built on top of the simpler mechanism. jb
On Fri, 25 Jan 2002, Jeff Bone wrote: > > > "S. Alexander Jacobson" wrote: > > > 1 server versus 100 servers seems like a good > > reason not to use HTTP for presence/chat. > > There's no data to support that assertion -wrt- scaling in that application > context. Mark Nottingham noted: A decent event loop/queue (different kind of event ;) could easily scale to many tens or even hundreds of thousands of open connections; you're really only limited by memory... Mike noted that the state of the art know-now server scales to 10k. I think Mike is overestimating, but that is another mail. Even if Mike is correct, you are looking at at least an order of magnitude difference in deployment costs between the two systems. Note: In theory one could implement an HTTPd using an event loop/queue (e.g. Medusa), in practice one doesn't and the rest of the HTTP infrastructure doesn't really support this scale. > > If I were doing asynch, I would much rather reuse > > the very well tested and widely deployed SMTP > > infrastructure than a new HTTP infrastructure. > > Me to. But no new HTTP infrastructure is needed, really. !!!!What is most of the recent discussion about!? In contrast, here is a short version of "reliable delivery" using SMTP: Send the message to the address using SMTP. Here is a short version of asynchronous callbacks using SMTP: Send the message to the reply-to address using SMTP Contrast this with all of Pauls various specs. > > For the basic terrorist_or_not.com, HTTP is a > > great protocol, but, as we have seen, REST > > is not. > > You want to run that through by me again? REST is the overall architectural > style of HTTP. I don't see how you distinguish the two. Terrorist_or_not.com uses RPC to deliver the queries. The target of the POST is a function not a resource. I think the format of the POST should me multipart/form-data. XML-RPC folks prefer XML-RPC and SOAP people prefer SOAP envelopes. These are all RPC. No one here has given a persuasive non-RPC version of the application. > > For many applications, RPC (over HTTP) makes > > sense, but REST does not. > > It only makes sense because you don't understand REST yet. ;-) I think I understand REST. I'm not sure you do :-). If you do, explain how to make terrorist_or_not.com non-RPC and why it would be better that way. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
A couple misc points: * I don't know that a URI hierarchy is the right way to expose properties. This creates a stateful way of sending messages property by property which is not so good. It can be avoided by PUTting an entire callback to the sink instead of POSTing a series of callback properties. * Status codes and replies returned by the sink should not expose state that a requester can't expose. Therefore sink replies MUST NOT have an entity-body, a source MUST NOT GET sink properties, a sink MUST NOT return 301 Moved Permanently, etc.
I'm going to read it again, but... I don't get it. Yet, probably. It looks like you are in fact reifying the whole notion of a response. I'm not sure how that could be useful. A couple of bits of feedback: > Given this equipment, we can place Jeff's comments about authentication and > expiration. Expiration is the inverse of caching, I don't think so. The expiry we're talking about is expiration of the commitment on the part of the source to notify the sink. That commitment is the subscription abstraction, and can and probably should be reified. Expiration defines a sort of TTL for an instance of that subscription abstraction. (Actually, Expiration should probably be expressed as TTL rather than any absolute date or time construct.) WRT caching, expiration and notification are both mechanisms for invalidating cached objects, but IMO these are mostly orthogonal to the issue of how to model a publisher / subscriber relationship. jb
On Fri, 25 Jan 2002, S. Mike Dierken wrote: > > I just took a look at the two knownow demos... > > If you are talking about the knownow web clients, > > they don't open a peristent GET, they just make > > repeated requests, (polling the server). > They use a persistent response. If the connection is closed, they re-open > it. That might be where the 'repeated requests' are coming from. Those are > very infrequent. What is a persisent response? I think they may do keep-alive my repeatedly asking the server "any messages, any messages,....", but that is still polling and it is still ugly (a waste of resources and bandwidth). > > > > If you are talking about the knownow event > > routers, it sounds like they are implementing > > listservs. If they are sending out 10k concurrent > > email messages, that is very nice. If they are > > sending out only 100-1000 concurrent messages and > > just claim a max of 10k listeners, that is > > incredibly unimpressive. > Oh. Remember, I don't have real numbers as I do not work there If you don't have real numbers then lets drop knownow. > > Either way, this has little to do with persistent > > GET and the merits of HTTP for presence > > applications. The main point is that HTTP is > > suboptimal for this application (but you may need > > it if the client is a web browser). > If the client were another server, would http be sufficient? Not if you only want to send messages when the client is "available." > > Yeah. Me too. How many chat clients can your web server support? > 10,000. Like I said, the KN server can handle 10k concurrent browser clients > per cluster node. Ok. Great. What is the polling frequency? My point is that whatever the number, a server that allows clients to hold open connections for long periods of time will perform orders of magnitude better. You could implement with HTTP if the server chunk encoded delivery of messages and the client held the connection open long enough, but as you noted this is a serious abuse of HTTP and as I noted, most servers and intermediaries aren't happy to let an HTTP connection stay silent for too long. > > Even if your server could handle higher capacity > > the bandwidth of handling large numbers of pings > > will also eventually overwhelm you. > > > > Alternatively, you could also document a > > more scalable protocol like Jabber, IRC, or Kazaa, > > give away the source, get the same hackers to > > work on it, and perhaps get bought by AOL! > Or examine your assumptions. > > Nobody here is suggesting polling is the preferred way to go. A server that > transparently handled polling for backward compatibility would help in many > situations, as long as the scalability/traffic problems don't surface. The issue is that HTTP requires polling to establish presence. Let me ask it all another way, do you want to use HTTP instead of telnet/ssh (to interact with the shell)? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I was so excited about this, I put together a draft [1] that night. It does have some commonality with Paul's proposal, but it's optimised for the problem domain. Comments appreciated. I'd be happy to add some people as co-authors if they're interested, but I don't know that you'd want to get involved in the politics of WEBI ;) Please discuss here; it's not ready for discussion in WEBI yet. [1] http://test.mnot.net/wni.txt On Wed, Jan 23, 2002 at 03:53:16PM -0800, Mark Nottingham wrote: > > You should take a look at WEBI[1][2]; with a bit of work with an eye > to the audience/requirements[3], this could easily be a candidate > (connectivity monitoring is the only thing that really stands out, at > first glance). > > I'd very much encourage you to consider this; if someone's > interested, please drop me a line. > > > [1] http://www.mnot.net/papers/ietf-49-wrec.pdf > [2] http://www.ietf.org/html.charters/webi-charter.html > [3] http://www.ietf.org/internet-drafts/draft-ietf-webi-rup-reqs-02.txt > > > > On Wed, Jan 23, 2002 at 12:52:38PM -0800, Paul Prescod wrote: > > http://www.prescod.net/HTTP_event_conventions.html > > > > I wrote this up in a rush so it isn't 100% coherent but it's a starting > > place for what I've been thinking about. It addresses many of the > > concerns that people have raised in one message or another. > > > > Mike B: It can watch any resource. > > > > Mike D: Notifications must say what kind of action happened. > > > > Jeff B: Any notification syntax is allowed. Query-like triggers can be > > handled (as they are on today's web) through POST parameters. > > > > Lucas: Limited support for working with environments where you do not > > control headers. > > > > Alex: It uses MIME. ;) > > > > It's about a million miles from being complete but in my mind it has a > > certain coherence and elegance. > > > > Now I've got to try and do real work for a few days... > > > > Paul Prescod > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > -- > Mark Nottingham > http://www.mnot.net/ > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
----- Original Message ----- From: "Jeff Bone" <jbone@...> > > > > Another way to think about this particular approach of creating > > subscriptions is that it is creating a 'route' from a source to a target. > > The agent creating that route needs permissions to read from the source and > > write to the target. In addition, since the target is receiving information > > about the source, the target needs permissions to read from the source. And > > if the permissions change, then the 'route' needs to be updated to reflect > > that - for example if Alice is denied permission to read the source, the > > route/subscription should be disabled (if you can't 'see' a resource, you > > shouldn't be able to 'hear' it either). (you can argue that it should be > > deleted, but re-enabling permissions isn't going to tell you what > > subscriptions need to be re-created.) > > details details... > > All good thoughts. For the most generic purposes, though, I think this is more > complexity than is required. It takes the task out of the realm of simple > authentication --- not of principal but of transaction --- and into a realm of > authentication + authorization. (To clarify the distinction: authentication > is proving continuity of identity for some purpose, authorization is deciding > whether / proving that some authenticated principal has permission to do > something.) > > With a scheme similar to the one I proposed, you're only doing the most basic > kind of authentication --- you're simply proving that the Subscriber event sink > "knows" and (continuously) "approves of" the subscription that was requested on > its behalf. With Mike's more sophisticated scheme, it seems that you need to > introduce some notion of permissions and authorization vis-a-vis those > permissions. This may be useful or even necessary for some applications, but > IMO it's not really necessary for the most basic uses of HttpEvents. And, it > can be built on top of the simpler mechanism. > You are probably right. I wasn't intending that these authorization concepts be visible in any message exchange - just that there are many applications of subscribing that need to take these issues into consideration. The minimal communication is just authentication aware. For example, when the subscription is used to deliver an event, and the event server provided the authentication credentials of the creator of the subscription, the receiver may reject the events (401, etc) - the event server (as an intermediary) may disable that subscription and perhaps echo that rejection back to the subscriber so they can deal with the delivery error. Is an event server that we are talking about in reality an intermediary - with issues of credential hand-off, etc.?
"S. Alexander Jacobson" wrote: > Mark Nottingham noted: > A decent event loop/queue (different kind of > event ;) could easily scale to many tens or even > hundreds of thousands of open connections; > you're really only limited by memory... > > Mike noted that the state of the art know-now > server scales to 10k. I think Mike is > overestimating, but that is another mail. Go do some homework re: scalability considerations on network servers of various kinds. The constraining factor for our buddies at KN is how many open sockets and how much data can reasonably be handled by / pumped through various OS kernels, etc. It's network protocol stack considerations. A Web-based service has the same *fundamental* constraints as any other TCP-based service; the problem is compounded by various factors, but scalability in terms of users / machine is going to be same-order for a Web-based solution and any other TCP-based solution, all other things being equal. (UDP offers some advantages, but just as many disadvantages. Our event notification protocol at Activerse was a sort of mucked-up HTTP-alike over UDP, and its a design decision I've regretted ever since then.) > Even if Mike is correct, you are looking at at > least an order of magnitude difference in > deployment costs between the two systems. No offense, but this just isn't true. Any differences are functions of the various HTTP implementations, not anything having to do with HTTP itself. Any TCP-based solution is going to hit roughly the same limits on the same hardware. > !!!!What is most of the recent discussion about!? How to *use HTTP* --- not how to fill in the holes. It's a subtle point. You'll get it eventually. > > > For the basic terrorist_or_not.com, HTTP is a > > > great protocol, but, as we have seen, REST > > > is not. > > > > You want to run that through by me again? REST is the overall architectural > > style of HTTP. I don't see how you distinguish the two. > > Terrorist_or_not.com uses RPC to deliver the > queries. The target of the POST is a function not > a resource. (a) The point is that REST is not a protocol, HTTP is a protocol (b) REST is the architectural style of HTTP + URI (c) If HTTP is a great protocol, then REST is a great style ;-) (d) If you're using HTTP to do RPCs, you aren't using HTTP (e) Instead, you're tunneling some other protocol *through* HTTP (f) If you're tunneling other protocols through HTTP, you just don't get HTTP (g) If you don't get HTTP, you can't understand REST > I think the format of the POST should me > multipart/form-data. XML-RPC folks prefer XML-RPC > and SOAP people prefer SOAP envelopes. > These are all RPC. I think Mark's perspective --- certainly my own perspective --- is that the XML-RPC and SOAP communities and the RPC-oriented "web services" efforts that we see all over the place today --- largely represent the same kind of sadly futile tail-chasing that lots of *very smart people* in our industry are prone to getting into every few years with new technology. DCE. CORBA. PUSH. All of these things are interesting, but they've all ended up in a kind of complexity death spiral that absolutely limits their proliferation. The Web, by contrast, is all about maximum proliferation. Given the Web as an existance proof, we should look at it to learn what characteristics it has that influence adoption, scalability, etc. > If you do, explain how to make > terrorist_or_not.com non-RPC and why it would be > better that way. I'll take that challenge. Next message. jb
Jeff Bone wrote: > > One terminological suggestion, two problems, two suggested solutions. > > Suggestion: rather than calling the target of event notifications an > "event target" why not reify the notion of the subscriber and simply > call the header that indicates that URI "Subscriber"? Okay. > ... > Suggested solution: when a Subscriber (client) obtains a subscription > via the URI indicated in the "Subscription" header, We need to differentiate between the subscription factory and the subscription... i.e. there is National Geographic. The subscribed-to resource. There is "publisher's clearinghouse". The subscription factory. And there is MY subscription. The thing that I need to spend money to upkeep. > ... the response SHOULD > contain a header "Expiration" which indicates when the subscription > expires. Okay. But there must be a way to retreive this later or the expiration data is "information not on the web." It should always be available at the "my subscription" resource. In fact the ability to get it in the original subscription transaction should be viewed as an optimization to avoid a hop. > ... If an Expiration is indicated, the Subscriber MUST "renew" the > subscription at some point before the Expiration date in some fashion. > (How? Presumably via a POST of some sort to the particular > subscription's Location: URI?) I don't want to end up overloading POST to the subscription URI. I guess right now we don't have any behaviour there yet so it should be okay to use that for renewal. I guess you can "suggest" a renewal period and the POST will return one. > ... If a Subscriber fails to renew a > subscription by the indicated expiration, the server MAY at any > subsequent point remove the subscription resource and stop sending > notifications to the Subscriber. Fine. Maybe there should be a way to let them "piggy back" notifications with expiration information. i.e. as long as we talk to each other in the next hour I'll extend your subscription for an hour. But let's leave that out for now and see if there is demand for it later. > The mechanism Paul describes is potentially very dangerous; it needs a > kind of authentication beyond simple principal / session > authentication. Consider: Mallory wants to DoS Alice. To do so, > Mallory subscribes to Bob, but gives Alice's URI to Bob as the > Subscriber / EventTarget. Even if Bob authenticates Mallory --- indeed, > even if Mallory is a valid user from Bob's perspective --- that still > doesn't prevent Mallory from using Bob to attack Alice. Attack is a strong word. I would say that annoyance is the best you could achieve with any reasonable web service. Plus, if the web service has authenticated Mallory, and thus has a form of accountability, then what's worse about this than having Mallory directly send data to a URI at Alice? Why bother with the intermediary? > ... Somehow, the > "client" that requests a subscription needs to be verifiably the "same" > in some sense as the Subscriber / EventTarget. The client needs to say that it really does want the messages. Whether it is the same or not is irrelevant. i.e. if I sign you up for FoRK, that's only a problem if you happen to be a FoRK addict and you're trying to quit. If you WANT FoRK then what does it matter whether you signed yourself up or not? This suggests that the original subscription should be jiggered so that it expires after the first message. It should require a confirmation for further messages. The confirmation does not have to be as complicated as a subscriptionID. A simple "please continue this subscription" should suffice. I feel like somehow this is related to expiration. Some subscriptions expire after a certain amount of time. Others expire after a certain number of messages. Most SHOULD start in a state such that they expire after the first message. Paul Prescod
On Fri, 25 Jan 2002, Paul Prescod wrote: > > The more comparable example is if you asked them > > to set up an asynchronous peer to peer > > messaging system (aka email). Would they choose > > HTTP or SMTP? > If they understood REST I think that they would choose HTTP. Better > applications can be built if you model data elements and processes as > resources rather than endpoints. That's nuts. Then you not only have to write software you have to invent a whole new protocol!!! In particular, you have to rewrite RFC2821(SMTP) to ride on top of HTTP. Thats a major PITA! (That being said, I think SMTP could be substantially improved and would love it if someone were willing to do so and could get it widely deployed) > If you're building a *new* application > then you need to write the software on the client and server sides > anyhow. We all know how little effort it takes to put HTTP on the client > side. I've shipped products with HTTP servers written in four different > languages. Writing a dumb SMTP server is pretty straightforward too. BFD. > > > If you want a web interface then you can use a POST form. > > > > See my reply to MB. This is not modeling the > > application in terms of resources. It is RPC. > > I don't know why you say it is RPC. The definition in my mind of RPC is > that the incoming message has a tag or identifier that instructs the > server what to do with it. But this "endpoint" resource would have one > and only one task. It would expect the input to be appropriate for that > task. Then your definition of RPC is incoherent. Suppose that XML-RPC were modified so that the method name appeared in the URL rather than the body, would it stop being RPC? Terrorist_or_not.com passes two arguments to a procedure on the server and that procedure returns a value. You cannot intepret the interaction as anything like either reading, writing, or appending to a file. > > Returning a URL and then asking the client to > > watch the new URL seems like a lot of overhead and > > waste. > > No, it is just a separation of concerns. Yes it takes more round-trips > than the SMTP system. It is also much more functional. The client can > check for status whenever it wants. Other clients can be attached to the > *same* computation because it is a first-class resource. Clients can > share information about what computations they are watching by sharing > the URI. Disconnected clients have the option of polling which they do > not with SMTP (unless there is a mailbox intermediary). Nothing prevents the server from returning a status URL AND commiting to deliver via email. Then you get the best of both worlds, anyone can check status and still no polling. Your point about disco clients is just insane. Have you heard of SMTP relay? > > Good argument, but the polling is ugly. A > > callback system is much nicer and much ligher on > > system resources! > > The point is that the same system could support *both*. This would be > much harder to do with SMTP. I am not objecting to supporting both! My contention is simply that using HTTP only precludes callbacks. As I said before, sometimes you want something other than HTTP. Sometimes you want something other than REST. > > > Conventions for asyncronous notification are here: > > > > > > * http://www.prescod.net/HTTP_event_conventions.html > > > > Ok. So that is another new protocol. It is not > > real life HTTP. > > If I use XHTML or RSS am I using XML? It is real life HTTP up until the > point that where I start doing things against the HTTP model such as > inventing private namespaces or telling the server what to do through > method names or using POST for logical queries. Terrorist_or_not.com uses POST for logical queries? Is that a problem? How would you solve it? My general point is that you are defining a new protocol on which endpoints have to have made "a priori agreement" (to use MBs words). Since endpoints do not yet understand WATCH, CHANGED, DELETED, etc, you are not talking about HTTP. You are inventing a new protocol. Your argument is like saying that HTTP is not a new protocol because it already uses TCP/IP. > > ... It also seems no better than just > > sending a reply-to in the first place. > > If you just send a reply-to then the client and server have no mutually > visible resource that represents the transaction. That means that the > client can't monitor it. The client can't cancel it. You could invent > some kind of UUID system but now you're inventing a private namespace. Again, if it is important to have monitoring, you can also send a location header that points to the request status (which is what RFC2616 actually says to do!). Again, I'm not objecting to monitoring. I am objecting to polling. To be clear both to you and to Mike. I am objecting to polling and to the work involved in reinventing the wheel on asynch. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > > Even if with a single client. The server is not > > guaranteeing to process messages in any order at > > all! > > > > Assuming the server issues sortable message ids, > > and the client sends them in order. How should > > the server handle recieving: > > > > RPOST 4 Jane > > RPOST 2 Tarzan > > RPOST 3 You > > RPOST 1 Me > > Why would a single client CHOOSE to send the messages in the wrong > order???? I am saying that: 1. your spec does not specify that the client should use message IDs in any particular order. 2. even if it did and clients sent message-IDs in that order, there is no guarantee that the server would recieve them in that order 3. even if the server did recieve them in order, there is no guarantee that it processes them in order. For example, suppose the client does RPOSTs to four load balanced intermediaries. None of the intermediaries can reach the endpoint so they just ping away until they get a connection. Once they get a connection, there is no reason to assume that the server recieve the messages in any particular order. Note, there is also no mechanism to feedback error messages if delivery fails. You are so into status notification, w/r/t terrorist_or_not.com. You seem not to care about delivery failure here. SMTP takes care of delivery failure. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > I guess we have a different definition of reliable. I mean that the > message gets through. I consider ordering issues to be orthogonal. Part > of the web zen is loose coupling between components. If responsibility > for ordering can be pushed off completely onto the client then I think > it should be. It can't be. You need to handle it. See my prior message on this. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > > You might want to call the protocol Reliable > > Delivery of POST requests. But even then, you > > still need a semantic for delivery failure (which > > MAY happen). > > The client will know if it failed to deliver. How coud the protocol > help? You want an HTTP server to report to an HTTP client that the > network cable is unplugged? Well SMTP notifies senders of delivery failure. How does RPOST work w/r/t proxies? Is your assumption that the client keeps a socket open until a connection happens? This seems ugly. I don't see why you don't just want to use SMTP which already takes care of these problems. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote:
>
> ...
>
> !!!!What is most of the recent discussion about!?
> In contrast, here is a short version of "reliable
> delivery" using SMTP:
>
> Send the message to the address using SMTP.
I don't claim to be an SMTP expert but I find that very hard to believe.
What happens if a network outage occurs such that the server believes
that it received a complete message and properly closed the session but
the client does not know that the session was considered closed. Or vice
versa. SMTP has the same issue that HTTP does and I see nothing in the
SMTP spec to indicate that there is a way to recognize that the client
is retry-ing the send.
S: MAIL FROM:<Smith@...>
R: 250 OK
S: RCPT TO:<Jones@...>
R: 250 OK
S: RCPT TO:<Green@...>
R: 550 No such user here
S: RCPT TO:<Brown@...>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK
> Here is a short version of asynchronous callbacks
> using SMTP:
>
> Send the message to the reply-to address using SMTP
You can do the same in HTTP. Just return a reply-to address. *BUT*.
*BUT*. *BUT*. The part you're missing is that we are trying to identify
what makes the web such a great, scalable, interoperable, popular system
and extend that into the domain of asynch, events, etc. reply-to is
trivial. But what if you want to say that you DON'T want the reply any
more? What if you want to have a centralized list of the things you are
expecting replies about? If you haven't given the reply-request a URI
then you can't do these things.
>...
>
> Terrorist_or_not.com uses RPC to deliver the
> queries. The target of the POST is a function not
> a resource.
That is not the definition of RPC. What's wrong with a function being a
resource? It becomes RPC when the function starts dispatching on method
names and setting up private namespaces.
Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Well SMTP notifies senders of delivery failure. You're talking about *relaying* failures. Not *protocol* failures. It's a totally different problem. > How does RPOST work w/r/t proxies? Do you mean proxies or relays? A proxy's job is to pretend it doesn't exist. Relays: Unrelated. Totally different problem. Part of the virtue of REST is that you assemble systems from logical components. > Is your assumption that the client keeps a socket > open until a connection happens? ??? We're talking about delivery of *one* message. Of course I expect it to keep a socket open if it can. But if it can keep a socket open then why is it having trouble delivering the message? > This seems ugly. I don't see why you don't just > want to use SMTP which already takes care of these > problems. Because it doesn't. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > 1. your spec does not specify that the client > should use message IDs in any particular order. If the client is happy with out of order delivery, so should the server be. > 2. even if it did and clients sent message-IDs in > that order, there is no guarantee that the server > would recieve them in that order If I open a TCP connection to machine X and send a message, that message has, by definition, arrived before any other messages I send. > 3. even if the server did recieve them in order, > there is no guarantee that it processes them in > order. If the server application needs to care about order then it should syncronize them. If it doesn't, it shouldn't. > For example, > suppose the client does RPOSTs to four load > balanced intermediaries. Now you're bringing in intermediaries. Clients do not typically do load balancing. Servers do load balancing. If a client wants to set up a system to do load balancing using intermdiaries then it needs to find a way to syncronize them. If a particular REST server wants to provide message ordering to the clients as a feature then fine, it can do that. I'm not going to put something in the spec that is only useful to a tiny percentage of all users. > ... None of the > intermediaries can reach the endpoint so they just > ping away until they get a connection. The client made a mistake sending time-ordered messages over intermediaries that are not synchronized. >... > Note, there is also no mechanism to feedback error > messages if delivery fails. We're back into this zone where you are talking about relaying and I haven't mentioned it. If you want to define a spec for reliable delivery of HTTP messages over *relays* then go ahead. That's a totally different problem. In any client/server protocol (including SMTP) it makes no sense to try and give feedback that there is a problem at the TCP layer. "It looks like my packets aren't getting through to you. I just thought you should know." Paul Prescod
> It looks like > you are in fact reifying the whole notion of a response. I'm not > sure how that > could be useful. I am saying that the sink API should do nothing but reify the whole notion of a response. It should have the same capabilities, no more, no less. If there are capabilities needed beyond that the implementation of choice should be requests performed by the sink. If there are capabilities that have to be in the sink API then they have a high burden of proof WRT security. For example, we can say a priori that the sink accepting mime headers is not a new security risk, but we can't say the same about the sink doing Kerberos authentication. > > Expiration is the inverse of caching, > > I don't think so. The expiry we're talking about is expiration of the commitment on the part of the source to notify the sink. That commitment is the subscription abstraction, and can and probably should be reified. Expiration defines a sort of TTL for an instance of that subscription abstraction. (Actually, Expiration should probably be expressed as TTL rather than any absolute date or time construct.) The only parts of the sink API that should address caching are reply headers related to caching. There's not much relevant there, so this is moot. Because of that we can make a affirmative statement that the sink API is not the place to address expiration. - Lucas
"S. Alexander Jacobson" wrote: > >... > > That's nuts. Then you not only have to write > software you have to invent a whole new > protocol!!! There is nothing wrong with inventing a new protocol to solve new problems or to solve old problems better. > .. In particular, you have to > rewrite RFC2821(SMTP) to ride on top of HTTP. Well, millions of people access their email through HTTP (with or without HTML). And millions of people do File Transfers without the File Transfer Protocol. So I don't see why SMTP will remain immune to the onslaught of HTTP. But anyhow, we're talking about inventing new protocols anyhow. If you're sending purchase orders over SMTP and you have complex workflows etc., you are inherently inventing a new protocol. Here's what an essay I am writing says: <p>There is a subtlety here: people think that they can get network effects by switching from HTTP to SMTP (e.g. for asychronous messaging). Of course there is some truth in this. If you were writing an email client today it would not make sense to support HTTP instead of SMTP. That's simple support for a legacy code base -- like supporting CICS. <p>On the other hand, if you were developing a new application then the network effects in SMTP's favour are not so strong. Getting bits from one machine to another asynchronously is the least of your problems in a complicated buzzword-compliant, secure, work-flow based business-to-business application. The hard problems involve security and accountability. And those hard problems are easier solved with a universal addressing mechanism like the one built into HTTP. <p>People believe that SMTP is great because it allows asynchronous notifications but KnowNow has shown how a few hundred bytes of JavaScript can implement peer-to-peer asynchronous notifications using HTTP. Would an SMTP solution be any smaller or simpler? >... > > If you're building a *new* application > > then you need to write the software on the client and server sides > > anyhow. We all know how little effort it takes to put HTTP on the client > > side. I've shipped products with HTTP servers written in four different > > languages. > > Writing a dumb SMTP server is pretty straightforward too. BFD. Right. So choosing based on what server you have hanging around makes no sense. You should choose based on which will help you to model your app in the most flexible, scalable, extensible, secure, reliable way. HTTP has URIs. They allow all of that stuff. SMTP does not. It makes that stuff really hard. >... > Then your definition of RPC is incoherent. > Suppose that XML-RPC were modified so that the > method name appeared in the URL rather than the > body, would it stop being RPC? It depends? Are they setting up private namespaces in the parameters? Or are all parameters either URIs or resource representations? >... > > No, it is just a separation of concerns. Yes it takes more round-trips > > than the SMTP system. It is also much more functional. The client can > > check for status whenever it wants. Other clients can be attached to the > > *same* computation because it is a first-class resource. Clients can > > share information about what computations they are watching by sharing > > the URI. > > Nothing prevents the server from returning a > status URL AND commiting to deliver via email. Fine. Now you are starting to make your solution more complex so that it starts to resemble mine in scope and features. How does your client cancel the request if it realizes that the computation is wasted? >... > Your point about disco clients is just insane. > Have you heard of SMTP relay? Can you read? > > Disconnected clients have the option of polling which they do > > not with SMTP (unless there is a mailbox intermediary). SMTP relay *is* the mailbox intermediary. Sometimes polling is a better solution. That's why POP uses it. My solution allows polling *and* direct notification *and* intermediated queued notification. And as a new RESTer pointed out it would be easy to add server-queued notification. >... > > The point is that the same system could support *both*. This would be > > much harder to do with SMTP. > > I am not objecting to supporting both! My > contention is simply that using HTTP only > precludes callbacks. I have no idea what you're saying. How can using HTTP preclude callbacks? > ... > > If I use XHTML or RSS am I using XML? It is real life HTTP up until the > > point that where I start doing things against the HTTP model such as > > inventing private namespaces or telling the server what to do through > > method names or using POST for logical queries. > > Terrorist_or_not.com uses POST for logical > queries? Is that a problem? How would you solve > it? If you want asynch then you are involving server state, so you need to use POST. > My general point is that you are defining a new > protocol on which endpoints have to have made > "a priori agreement" (to use MBs words). Call it a new protocol. What does it matter? Terrorist.com is going to require a new "protocol" in some sense regardless. Especially if you set up a status URI then you are setting up a protocol that spans *two other* protocols. We're going to take the "common problem" of asynch notifications and develop standard conventions. If you want to call that a new protocol then that's okay too. As longas we don't abuse HTTP as POSTing getStateName does, then what does it matter what we call it? The point is that everything that is already in HTTP is basically *right* and we are building on it, rather than working around the flaws in it. >... > Your argument is like saying that HTTP is not a > new protocol because it already uses TCP/IP. Are cookies a new protocol? Or an extension to HTTP? >... > To be clear both to you and to Mike. I am > objecting to polling and to the work involved in > reinventing the wheel on asynch. Polling is just an option. Not a requirement. HTTP asych does not require polling. Reinventing the wheel is necessary if we want to bring asnch to the web. SMTP has no concept of URI. Therefore it is not web aware. That isn't surprising since it predates the web. This is a big limitation that makes it infeasible for many applications. Asynch HTTP is not an option. It is something that needs to happen. Whether you use it for your application or not is up to you. Paul Prescod
> If the client is happy with out of order delivery, so should the server > be. This is way too far head. In-order delivery is a real issue, but a RESTy solution isn't even a possibility until notifications are doable.
On Fri, 25 Jan 2002, Jeff Bone wrote: > > !!!!What is most of the recent discussion about!? > > How to *use HTTP* --- not how to fill in the holes. It's a subtle point. HTTP uses TCP/IP. It does not fill in holes. Please clarify your point? > (d) If you're using HTTP to do RPCs, you aren't using HTTP Uhm. So, SOAP and XML-RPC aren't using HTTP? > > I think the format of the POST should me > > multipart/form-data. XML-RPC folks prefer XML-RPC > > and SOAP people prefer SOAP envelopes. > > These are all RPC. > > I think Mark's perspective --- certainly my own perspective --- is that the > XML-RPC and SOAP communities and the RPC-oriented "web services" efforts that we > see all over the place today blah blah blah. I think most web apps (of which terrorist_or_not.coom is an example) are RPC. The issue here is whether they are or aren't. The other RESTers here seemed to have no problem with the overall design of posting multipart/form-data to some URL. I just fail to see why that is REST. I think you and I agree that it isn't. Perhaps if you explain why to Mark and Paul, they will understand it better than if I do. ;-) > > If you do, explain how to make > > terrorist_or_not.com non-RPC and why it would be > > better that way. > > I'll take that challenge. Next message. Looking forward. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > HTTP uses TCP/IP. It does not fill in holes. > Please clarify your point? Forget it, I'm lost, you're lost, we're all off in the weeds. Next point. > > (d) If you're using HTTP to do RPCs, you aren't using HTTP > > Uhm. So, SOAP and XML-RPC aren't using HTTP? It may be possible to use SOAP with HTTP --- Mark's got a better read on the current state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do. It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP. I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through HTTP. > blah blah blah. I think most web apps (of > which terrorist_or_not.coom is an example) are > RPC. The issue here is whether they are or > aren't. I don't have any issue here. I think you're probably right --- most probably are. But that doesn't really say anything except that most developers don't really understand HTTP, and it's easier for them to superimpose their own procedural or OO view of the world on top of HTTP. > The other RESTers here seemed to have no problem > with the overall design of posting > multipart/form-data to some URL. I'm lost again. I don't have any problem with the idea of posting any particular kind of data to some URL, cf. my own example. > I just fail to see why that is REST. It's REST because it's HTTP. That's what POST *is for,* per the HTTP spec. > I think you and I agree that it isn't. Perhaps > if you explain why to Mark and Paul, they will > understand it better than if I do. ;-) Mark and Paul aren't objecting to the use of POST in this fashion per se, AFAICT. Perhaps they could comment. I find it hard to see why they would. I suspect that you're failing to understand their objections. jb
Jeff Bone wrote: > >... > > Mark and Paul aren't objecting to the use of POST in this fashion per se, AFAICT. > Perhaps they could comment. I find it hard to see why they would. I suspect that > you're failing to understand their objections. I'm lost too. The most important thing is that you don't start setting up private naming schemes in parameters. That's when you start going off into the RPC weeds. Paul Prescod
On Fri, 25 Jan 2002, Paul Prescod wrote: > There is nothing wrong with inventing a new protocol to solve new > problems or to solve old problems better. Remember worse is better. > > .. In particular, you have to > > rewrite RFC2821(SMTP) to ride on top of HTTP. > > Well, millions of people access their email through HTTP (with or > without HTML). And millions of people do File Transfers without the File > Transfer Protocol. So I don't see why SMTP will remain immune to the > onslaught of HTTP. You are talking about user-agents, not MTAs or relays. > But anyhow, we're talking about inventing new protocols anyhow. If > you're sending purchase orders over SMTP and you have complex workflows > etc., you are inherently inventing a new protocol. Only if you think any use of an HTTP endpoint is a protocol. If I send POs over SMTP and they get sent back approved or rejected, I am defining something that endpoints are doing. I am not inventing a new transport protocol. > Here's what an essay > <p>There is a subtlety here: people think that they can get network > effects by switching from HTTP to SMTP (e.g. for asychronous > messaging). Of course there is some truth in this. If you were writing > an email client today it would not make sense to support HTTP instead > of SMTP. That's simple support for a legacy code base -- like > supporting CICS. The same is true of the presence application. You know the joke about the creationist talking to the programmer. The creationist said: God created the world in 6 days. The Programmer responded "Yeah, thats because he didn't have an installed base" You reuse what is available and have to be compatible. > <p>On the other hand, if you were developing a new application > then the network effects in SMTP's favour are not so strong. Getting > bits from one machine to another asynchronously is the least of your > problems in a complicated buzzword-compliant, secure, work-flow based > business-to-business application. The hard problems involve security > and accountability. And those hard problems are easier solved with a > universal addressing mechanism like the one built into HTTP. Asynchronous delivery may be one of your problems and SMTP does a decent job. And if your project is that big, I think you would rather reuse SMTP than invent a new asynch protocol just for your project. The hard problems of security and accountability are orthogonal issues. > <p>People > believe that SMTP is great because it allows asynchronous notifications > but KnowNow has shown how a few hundred bytes of JavaScript can > implement peer-to-peer asynchronous notifications using HTTP. Would an > SMTP solution be any smaller or simpler? If you have a fixed set of players then perhaps KnowNow is the best solution. But I don't think you want every party to be permanently connected to every other just to recieve messages. I do think you may want to interop with organizations that do not use KnowNow. Where is the KnowNow RFC? > Right. So choosing based on what server you have hanging around makes no > sense. You should choose based on which will help you to model your app > in the most flexible, scalable, extensible, secure, reliable way. HTTP > has URIs. They allow all of that stuff. SMTP does not. It makes that > stuff really hard. When you want asynchronous messaging, use SMTP. When you want synchronous tracking, use HTTP. These are orthogonal. > > Then your definition of RPC is incoherent. > > Suppose that XML-RPC were modified so that the > > method name appeared in the URL rather than the > > body, would it stop being RPC? > > It depends? Are they setting up private namespaces in the parameters? Or > are all parameters either URIs or resource representations? Obviously function names in URLs are private namespaces because URLs are opaque. All parameters are not URIs. They are form-data delivered via HTTP post. You know all this. You are avoiding the issue. > > Nothing prevents the server from returning a > > status URL AND commiting to deliver via email. > > Fine. Now you are starting to make your solution more complex so that it > starts to resemble mine in scope and features. How does your client > cancel the request if it realizes that the computation is wasted? My initial spec didn't require the tracking that you seem to want. You kept expanding the scope of my spec to justify your features. If we want computation cancelation, then perhaps we return a location header with the 202. But, if we want to support users with web browsers (CICS!), we should really return the location of a form in the body that will allow the user to inquire. The location of the target is irrelevant in such a case. > >... > > Your point about disco clients is just insane. > > Have you heard of SMTP relay? > > Can you read? I can. Can you? Here is what RFC2821 says: As discussed above, when the SMTP server receives mail from a particular host address, it could activate its own SMTP queuing mechanisms to retry any mail pending for that host address. In other words. When a disco client reconnects, it can just (mail) ping the server to get messages. It doesn't ping unless it has been disco for a while so this is a very different type of polling. > > > Disconnected clients have the option of polling which they do > > > not with SMTP (unless there is a mailbox intermediary). > > SMTP relay *is* the mailbox intermediary. Sometimes polling is a better > solution. That's why POP uses it. My solution allows polling *and* > direct notification *and* intermediated queued notification. And as a > new RESTer pointed out it would be easy to add server-queued > notification. No. Your solution requires the client to poll even when it has been connected. With SMTP the client may choose either to get direct notification or to poll (in which case it supplies the polling server!). Your solution requires the application server to bear the cost of operating a polling server and the client to poll repeatedly. > > I am not objecting to supporting both! My > > contention is simply that using HTTP only > > precludes callbacks. > > I have no idea what you're saying. How can using HTTP preclude > callbacks? Because the server has no way to back contact the client. It has to wait for the client to reconnect. You can of course propose a new protocol by which the client supplies a URL to which the server should POST the result, but that is a new protocol and you have yet to show why that mechanism is a better protocol (for example it has no reliability!). > > ... > > > If I use XHTML or RSS am I using XML? It is real life HTTP up until the > > > point that where I start doing things against the HTTP model such as > > > inventing private namespaces or telling the server what to do through > > > method names or using POST for logical queries. > > > > Terrorist_or_not.com uses POST for logical > > queries? Is that a problem? How would you solve > > it? > > If you want asynch then you are involving server state, so you need to > use POST. You are evading the issue. Simple terrorist_or_not.com does not require asynch, but still must use POST for logical queries. > > My general point is that you are defining a new > > protocol on which endpoints have to have made > > "a priori agreement" (to use MBs words). > > Call it a new protocol. What does it matter? Terrorist.com is going to > require a new "protocol" in some sense regardless. Especially if you set > up a status URI then you are setting up a protocol that spans *two > other* protocols. Your missing the point. Terrorist.com is just an application. A new user doesn't have to set up anything new to use it. She simply opens up a web browser, adds 2 image files to the form and a reply-to email address. The server either gives her an immediate answer or tells her that it is too busy and that it will send her the the answer when it gets to it. In the meantime, she can update/check status at *this* location. In contrast, your solution would require her to set up a special HTTP server to recieve the callback using a new callback HTTP protocol. > We're going to take the "common problem" of asynch notifications and > develop standard conventions. If you want to call that a new protocol > then that's okay too. As longas we don't abuse HTTP as POSTing > getStateName does, then what does it matter what we call it? Look. If you want to develop a protocol called HTTP-MTP, thats fine. Just realize that you are competing head-on with SMTP without offering any majorly visible advantages. Any any advantages you do get, might be better achieved through evolutionary improvement in SMTP. > The point is that everything that is already in HTTP is basically > *right* and we are building on it, rather than working around the flaws > in it. If HTTP is so right, talk to me about the lack of logical queries with large bodies? > > Your argument is like saying that HTTP is not a > > new protocol because it already uses TCP/IP. > > Are cookies a new protocol? Or an extension to HTTP? I believe they are defined by a different RFC. In particular, supporting HTTP does not enail supporting cookies. > > To be clear both to you and to Mike. I am > > objecting to polling and to the work involved in > > reinventing the wheel on asynch. > > Polling is just an option. Not a requirement. HTTP asych does not > require polling. Polling is necessary unless you invent a new HTTP asynch delivery protocol. > Reinventing the wheel is necessary if we want to bring asnch to the web. I don't see you as bringing asynch to the web. The issues are all orthogonal. > SMTP has no concept of URI. Therefore it is not web aware. Show me something you want to do that requires a change in SMTP? There is no reason you can't have SMTP servers also expose an HTTP server in which you inquire about message-ids it has delivered, but that is irrelevant to the actual delivery of messages. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > Terrorist_or_not.com passes two arguments to a > procedure on the server and that procedure returns a > value. > > You cannot intepret the interaction as anything > like either reading, writing, or appending to a > file. You *absolutely* can. Consider Plan 9: its networking mechanism presents a set of services which look like files: they can be opened, read, written to etc. to communicate with the services in question. For e.g. name resolution, the client opens a file (something like) /net/cs (i.e., "connection server" is reified as a "file") writes a string like "www.foo.com", then reads the file contents back to receive something like "209.224.18.5". That is *just like* what you're describing above, with the exception that you're only passing a single parameter. (Other Plan 9 services accept multiple "parameters" in this fashion.) > As I said before, sometimes you want something > other than HTTP. Sometimes you want something > other than REST. This is really getting old, Alex. Sigh. Mark, let me say now how very sorry I am for having put you through this, now that I see how it looks from the other side of the fence. ;-) jb
"S. Alexander Jacobson" wrote in various places: > Using MIME-RPC over HTTP, you would POST either > a list (multipart/mixed), or a struct > (multipart/form-data) to some URL (e.g. > terroristornot.com/verify). > In other words, [in the REST version, the app] is making an idempotent > request. Accoding to REST, the client should use > GET for such a a request, but I don't know how you > send two pictures using GET. So I'm not sure you > can use REST. > You cannot sanely do this with GET, therefore I > think you cannot sanely do this with REST. IMO, the issue of idempotence --- what it means in what contexts, which methods are guaranteed to be truly idempotent vs. which ones *may* be idempotent ---- is one of the less well-understood aspects of the Web. The Web (its protocols and technologies) is a work-in-progress, one that's evolving from a rather informal origin to more a more formal definition. The claim that *no* idempotent operation should be performed by a method other than GET is a bit suspect, as you point out. And idempotent operations which carry content might be deserving of another method. I do agree that you cannot use GET alone to do Terrorist-Or-Not in a practical fashion. Whether or not this means that you can't build it in a RESTful fashion depends on how literally you want to interpret certain utterings of e.g. TBL. ;-) I don't, however, think this means that you have to ditch resource modeling (rather than procedural API exposure) or the HTTP protocol. It just means you have to think about how to do it within the framework provided. Went back and looked at Mike's suggestion; it's generally fine with the caveat that yes, it results in two separate request / response cycles. I didn't see what your particular objection to it was, other than perhaps that. If there's an issue with that, you can always collapse that into a single request-response cycle. In other words, the more concise version of Mike's solution would (with some minor name changing just to make me happy ;-) simply be: (request) ==> POST http://www.terrorist_or_not.com/terrorists/checker HTTP/1.1 Content-Type: mulitpart/related --- image 1 --- --- image 2 --- <== (response) 200 OK <suspect> <status>verified</status> <category>terrorist</category> <details>http://www.terrorist_or_not.com/terrorists/123456</details> </suspect> There's no reason why the thing that checks terrorists can't be reified as a resource with a generic interface that obeys the semantics of HTTP methods. Indeed, the above kind of thing is exactly what POST is for. The Response could be XML, or HTML, or some MIME encoding, or whatever; that's up to the app, and REST / HTTP has no particular preference. It might be possible to leverage other HTTP response codes to expose *more* of the application's semantics to HTTP, but the above is entirely valid. (E.g. it might return a 202 Accepted and indicate a Location: to retrieve the current status of the query from, segueway to...) Now your next objection will be that in some cases the verification process may take too long for a single HTTP request-response cycle. In that case, the service would simply create a resource for the pending query and return that as the Location: in a 202 Accepted response. The client would then poll that resource to get the status of the query. Your *next* objection will be that polling is undesirable. Well, that's certainly true. Asynchrony of requests and responses from the perspective of a particular application is often desirable. That's what we've been talking about: different mechanisms to build asynchronous communication patterns atop HTTP without breaking the semantics of HTTP. The problem isn't that it's impossible, it's that there are many different ways to go about this. What's needed isn't a new protocol or new standard, its a set of generic conventions and guidelines. Your next objection will be that HTTP is unreliable (as in guaranteed delivery.) That's true. But them's the hard facts, main. If you really believe that our SMTP fabric is reliable in that sense, I want some of what you're smoking. ;-) In any case, there's no reason to believe either is or can be absolutely more reliable than the other. The main objection to duplicating SMTP's messaging functionality in HTTP is that it's redundant; the best argument for it is that it unifies the space of addressable things and their interfaces, and that has positive implications for integration and Metcalfe-value. Per reliable ordered delivery, that's a Hard Problem in a distributed setting --- as you're clearly aware. Neither HTTP nor SMTP does or *can* solve the problem without extensive work. Solutions to the general problem such as ISIS (Ken Birman's reliable ordered multicast / group communication toolkit from over a decade ago) provide solutions but are generally too expensive for most apps. Happily, most distributed apps can easily sacrifice globally consistent message delivery order, etc. in favor of weaker consistency / better performance. Bottom line, you've been offered a variety of solutions, etc. to your "terrorist-or-not" problem and related issues; whether you accept them is up to you. I still haven't seen any single point you've raised that addresses Mark Baker's fundamental challenge, which is "Show me an application that I can't do with HTTP." He posed that challenge to me a while back, and I haven't been able to come up with a single good answer. There are things that can be done more effectively if HTTP is extended, but in general there are very few of these. (As mentioned, a system which uses the resource space as a kind of generative communication space ala Linda would benefit greatly from an atomic GET+DELETE operation; most of the extensions that really do make sense are those that guarantee atomicity for various combinations of existing methods.) jb
"S. Alexander Jacobson" wrote: > On Fri, 25 Jan 2002, Paul Prescod wrote: > > There is nothing wrong with inventing a new protocol to solve new > > problems or to solve old problems better. > > Remember worse is better. I absolutely buy "worse is better." (BTW, Dick Gabriel was on my technical advisory board at my last play, Activerse.) What you're failing to understand is that "worse is better" favors HTTP. :-) > You are talking about user-agents, not MTAs or > relays. He's talking about the overall functionality --- the "what," not the "how." His point is that the particular underlying machinery is in some sense non-essential to the problem domain --- it's the "how," not the "what." Ugh. We have gone way beyond the point of diminishing returns on this one. jb
Ok, so you want the client to accumulate a queue of RPOSTs and only RPOST follow-on messages after prior ones have been sent sucessfully. Fine. I thought you would let clients spin out a thread for each RPOST. Then my only other major comment is that you should let clients generate message-ids and avoid the extra round-trips. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > The claim that *no* idempotent operation > should be performed by a method other than GET is a bit suspect, as you point out. > And idempotent operations which carry content might be deserving of another method. > > I do agree that you cannot use GET alone to do Terrorist-Or-Not in a practical > fashion. Whether or not this means that you can't build it in a RESTful fashion > depends on how literally you want to interpret certain utterings of e.g. TBL. ;-) I think TBL revised his wording on this in light of HEAD and PUT being idempotent: http://lists.w3.org/Archives/Public/www-tag/2002Jan/0076.html
> > Ugh. We have gone way beyond the point of diminishing returns on this one. > It's time to retire to our respective corners and come back out with working code.
Ok. Capacity argument on the presence server conceded. Not conceding the capacity argument on asynch messaging. You don't want thousands of clients polling asking "is it ready yet?". And you don't want an email system in which every party has to hold open a connection to every other party. -Alex- On Fri, 25 Jan 2002, Mark Nottingham wrote: > > On Fri, Jan 25, 2002 at 08:41:52AM -0500, S. Alexander Jacobson wrote: > > > > Yeah. Me too. How many chat clients can your web > > server support? According to (1), a typical test > > Apache server can handle ~250 requests per second. > > Assuming your clients poll once per second, you > > max out at 250 simulatenous clients. That sucks! > [..] > > (1) http://www.acme.com/software/thttpd/benchmarks.html > > Err, that's hits per second, not concurrent connections. You're using > a benchmark of Apache by an Apache competitor as an indication of how > all Web servers perform in general? Tsk. It's widely acknowledged > that Apache is performance-limited, in a trade-off for stability, > developability, etc. > > Let me be more explicit: I know of at least two vendors who have HTTP > implementations that can handle 50,000+ concurrent persistent > connections on commodity hardware. > > It's much more instructive to look at intermediary implementations > when you're talking about the performance overhead of HTTP; they're > more optimised for performance, and they're not doing anything with > the payload; it's all just overhead. It's relatively easy to achieve > 1000+ reqs/sec [1]. Most modern HTTP intermediaries can approach or > exceed wire speed. > > I'd note that these numbers don't include any of the larger > commercial vendors (with more developed implementations) who > participated in past years, but now don't want their numbers made > public, as it starts a performance war... > > > [1] http://www.measurement-factory.com/results/public/cacheoff/N04/raw.html > > > > -- > Mark Nottingham > http://www.mnot.net/ > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Ok, how about a new approach. Let's say you and I each have an SMTP, FTP, and HTTP server on our machines. Without any further agreement between us, which one can be used to do the most things? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Fri, 25 Jan 2002, Jeff Bone wrote: > I do agree that you cannot use GET alone to do Terrorist-Or-Not in a practical > fashion. Whether or not this means that you can't build it in a RESTful fashion > depends on how literally you want to interpret certain utterings of e.g. TBL. ;-) Ok. So idempotence is a red herring. My general judgement of this is that I think you shouldn't rely on idempotence. Every things should be interpreted as a once-off (otherwise known as linear types -- see http://linux.rice.edu/~rahul/hbaker/Use1Var.html) > I don't, however, think this means that you have to ditch resource modeling (rather > than procedural API exposure) or the HTTP protocol. It just means you have to > think about how to do it within the framework provided. Ok. I guess I'm just not getting how posting two images to a URL is resource modeling. > There's no reason why the thing that checks terrorists can't be reified as a > resource with a generic interface that obeys the semantics of HTTP methods. Ok. But that is true of every RPC server as well. You send arguments to the server and it sends back a result. Suppose there was another argument, that had one of two values: isTerrorist | isFed Would that make it non-Restful? > Your *next* objection will be that polling is undesirable. Well, that's certainly > true. Asynchrony of requests and responses from the perspective of a particular > application is often desirable. That's what we've been talking about: different > mechanisms to build asynchronous communication patterns atop HTTP without breaking > the semantics of HTTP. I don't understand why SMTP doesn't do what you want. In particular SMTP doesn't look all that different than HTTP with some new methods (MAIL, RCPT, VRFY, etc.). What do you get from replacing SMTP? If the point is simply that you want HTTP clients to me able to talk to mail servers, why not simply do the direct mapping described above? > Your next objection will be that HTTP is unreliable (as in guaranteed delivery.) > That's true. But them's the hard facts, main. If you really believe that our SMTP > fabric is reliable in that sense, I want some of what you're smoking. ;-) HTTP is inherently unreliable. SMTP is only in practice unreliable because the implementations suck. Talk to the folks at ironport about this. If you want to know more. > In any > case, there's no reason to believe either is or can be absolutely more reliable > than the other. The main objection to duplicating SMTP's messaging functionality > in HTTP is that it's redundant; the best argument for it is that it unifies the > space of addressable things and their interfaces, and that has positive > implications for integration and Metcalfe-value. Ok. So the big bonus here is that my email address is http://i2x.com/~alex rather than alex@.... GETting this URL would retrieve my homepage or some form of status information and POSTing to it would send me an email. Interesting, but I guess I just don't see so much value there. > Per reliable ordered delivery, that's a Hard Problem in a distributed setting --- separate issue. > Bottom line, you've been offered a variety of solutions, etc. to your > "terrorist-or-not" problem and related issues; whether you accept them is up to > you. They are all fine. What I fail to get is what exactly you don't like about RPC. > I still haven't seen any single point you've raised that addresses Mark > Baker's fundamental challenge, which is > > "Show me an application that I can't do with HTTP." I answered this before. My answer was show me an application that you can't do with SMTP. You should use what makes you feel comfortable and model applications as messages sent between agents :-). And, you're right, transactional stuff is another answer. You don't really want to use HTTP to interact with Oracle. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Mark Baker wrote: > > Ok, how about a new approach. > > Let's say you and I each have an SMTP, FTP, and HTTP server on our > machines. Without any further agreement between us, which one can be > used to do the most things? Well it depends how they are configured. I'd guess it would have to be wide open to do anything useful. Can you make a strong case that a wide open HTTP server is more "powerful" than a wide open FTP server? Either can PUT, GET, DELETE. And FTP servers have directories that you can append to.... Paul Prescod
On Fri, 25 Jan 2002, Jeff Bone wrote: > > Uhm. So, SOAP and XML-RPC aren't using HTTP? > > It may be possible to use SOAP with HTTP --- Mark's got a better read on the current > state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do. > It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP. > I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through > HTTP. I don't see what the difference is between XML-RPC and Mike's solution to the terrorist-or-not.com problem. One encodes with MIME, the other with XML-RPC. > > blah blah blah. I think most web apps (of > > which terrorist_or_not.coom is an example) are > > RPC. The issue here is whether they are or > > aren't. > > I don't have any issue here. I think you're probably right --- most probably are. > But that doesn't really say anything except that most developers don't really > understand HTTP, and it's easier for them to superimpose their own procedural or OO > view of the world on top of HTTP. You were making an argument about existence proofs. My point is that existence goes both ways. > > I just fail to see why that is REST. > > It's REST because it's HTTP. That's what POST *is for,* per the HTTP spec. XML-RPC uses POST too. But you deny that it is REST! -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > > !!!!What is most of the recent discussion about!? > > In contrast, here is a short version of "reliable > > delivery" using SMTP: > > > > Send the message to the address using SMTP. > > I don't claim to be an SMTP expert but I find that very hard to believe. I am not an expert either, but I believe that with SMTP, the sender keeps trying to SEND until it gets an OK from the Reciever. The reciever should use the message-id to recognize repeat sends and deliver once to the user. I think that is the behavior you want. > > Here is a short version of asynchronous callbacks > > using SMTP: > > > > Send the message to the reply-to address using SMTP > > You can do the same in HTTP. Just return a reply-to address. *BUT*. > *BUT*. *BUT*. The part you're missing is that we are trying to identify > what makes the web such a great, scalable, interoperable, popular system > and extend that into the domain of asynch, events, etc. reply-to is > trivial. But what if you want to say that you DON'T want the reply any > more? What if you want to have a centralized list of the things you are > expecting replies about? If you haven't given the reply-request a URI > then you can't do these things. Build that. Those things are orthogonal from asynchronous message delivery (or polling). > > Terrorist_or_not.com uses RPC to deliver the > > queries. The target of the POST is a function not > > a resource. > > That is not the definition of RPC. What's wrong with a function being a > resource? It becomes RPC when the function starts dispatching on method > names and setting up private namespaces. You can't GET a function and URLs are opaque. Does something magical happen when some content moves from the body to the url? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > I would say that if you standardize how this is done so that any client > could send any purchase order to any server and reliably parse the > return result then you have a new protocol. If you are just building a > one-off app then by all means, use whatever software you've got laying > around. Do asynch FTP if it is convenient. Sure. Post the PO to a URL. Or... email the PO to an email address. This is a file format issue, not a protocol issue. > > Asynchronous delivery may be one of your problems > > and SMTP does a decent job. > > You claim it does. But who do you know using SMTP for these kinds of > jobs? I know about thousands of complicated ecommerce apps using HTTP > and none using SMTP. Even inside of organizations, most companies do not > use SMTP for asynch delivery of business-critical information. They use > MQseries etc. Thats because SMTP implementations typicall suck. Check out http://ironport.com. > > ... The hard problems of security and > > accountability are orthogonal issues. > > This is the crux of our communication problem. You think asynchronous > delivery is hard and using HTTP makes it harder. I think it is easy and > using HTTP makes no difference. No. I just don't see why you are reinventing the wheel. > I think security and accountability are brutally hard and I think that > reifying objects as addressable entities makes them much more managable. > Thirty years of Unix and even Windows NT supports my position. How do I > make it possible for a user to print or not to print? I treat the > printer (or print queue) as a resource and give them permissions to it. > How do I cancel jobs? I reify them as objects and then delete them. How > do I know who did what? I look at the logs for those addressable > objects. Ok. So I think SMTP is like the network transport layer. Windows is perfectly happy to use TCP/IP rather than NetBIOS as its transport. These issues are orthogonal to the procedures for accessing server logs. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > I am looking at RFC2821. It has a whole section > on "Retry stratgies." Message-id is covered in > RFC2822. The spec does not explicitly cover using > message-ids in retry context, but SMTP agents may > obviously use it for exactly this purpose. No. If the spec does not say that they may ignore two messages sent with the same Message-ID then they should not. Plus: > In all cases, it is the meaning that the sender > of the message wishes to convey (i.e., whether this is the same > message or a different message) that determines whether or not the > "Message-ID:" field changes, not any particular syntactic difference > that appears (or does not appear) in the message. > > "Go to http://www.google.com/ Type in Paul Constock. Hit Enter." > > That is a user interface convention. If you think that the web's fundamental addressing mechanism is user interface then the gap between us is too large to be bridged in a predictable amount of time. > ... By that > argument, is I urlencoded XML-RPC and passed it in > the qu\ery string, it would no longer be RPC. You would also need to use the appropriate HTTP methods for each task. (GET for queries, PUT for updates, etc.) But other then that, I can't think of anything theoretically wrong with double-encoding query strings as XML-RPC and then as URL encoding. It's just ugly as sin. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Thats because SMTP implementations typicall suck. > Check out http://ironport.com. Demonstrates nothing. If we set about building real applications with SMTP we would soon have a thread "why is SMTP hard to design with?" >... > > No. I just don't see why you are reinventing the > wheel. The wheel is square. > > I think security and accountability are brutally hard and I think that > > reifying objects as addressable entities makes them much more managable. > > > Thirty years of Unix and even Windows NT supports my position. How do I > > make it possible for a user to print or not to print? I treat the > > printer (or print queue) as a resource and give them permissions to it. > > How do I cancel jobs? I reify them as objects and then delete them. How > > do I know who did what? I look at the logs for those addressable > > objects. > > Ok. So I think SMTP is like the network transport > layer. Windows is perfectly happy to use TCP/IP > rather than NetBIOS as its transport. These > issues are orthogonal to the procedures for > accessing server logs. If a) my fundamental concepts are addresses and addressable objects (my point above) b) I already have about five or six layers of "transport" (a simple fact) c) I can easily glue together an address-centric system that does asynch notifications and routing (you admitted that doing this isn't hard) then what benefit am I getting out of SMTP? It seems like there are a lot of people out there who have an emotional attachment to it just because it is out there. A few hundred lines of code gets me HTTP callbacks. A few hundred more get me HTTP event relaying. A few hundred more get me guaranteed message delivery. Once I've built these I can use them for every HTTP service in the world...even HTML apps. What does SMTP bring to the table other than a warm fuzzy feeling? Backwards compatibility? I can have that through a simple gateway. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Only if you think any use of an HTTP endpoint is a > protocol. If I send POs over SMTP and they get > sent back approved or rejected, I am defining > something that endpoints are doing. I am not > inventing a new transport protocol. I would say that if you standardize how this is done so that any client could send any purchase order to any server and reliably parse the return result then you have a new protocol. If you are just building a one-off app then by all means, use whatever software you've got laying around. Do asynch FTP if it is convenient. >... > Asynchronous delivery may be one of your problems > and SMTP does a decent job. You claim it does. But who do you know using SMTP for these kinds of jobs? I know about thousands of complicated ecommerce apps using HTTP and none using SMTP. Even inside of organizations, most companies do not use SMTP for asynch delivery of business-critical information. They use MQseries etc. > ... And if your project > is that big, I think you would rather reuse SMTP > than invent a new asynch protocol just for your > project. Right. That's why you would like for rest-discuss to have defined a set of conventions for you to use. Now will you let us get back to work doing that? > ... The hard problems of security and > accountability are orthogonal issues. This is the crux of our communication problem. You think asynchronous delivery is hard and using HTTP makes it harder. I think it is easy and using HTTP makes no difference. I thin security and accountability are brutally hard and I think that reifying objects as addressable entities makes them much more managable. Thirty years of Unix and even Windows NT supports my position. How do I make it possible for a user to print or not to print? I treat the printer (or print queue) as a resource and give them permissions to it. How do I cancel jobs? I reify them as objects and then delete them. How do I know who did what? I look at the logs for those addressable objects. Paul Prescod
On Fri, 25 Jan 2002, Paul Prescod wrote: > No. If the spec does not say that they may ignore two messages sent with > the same Message-ID then they should not. No. The spec leaves it up to the recieving application. If you want to claim this is a new protocol then it is a one line protocol: only process any given message-id once. Also, in good implementations duplicate messages should be very rare. See RFC1047. > > > "Go to http://www.google.com/ Type in Paul Constock. Hit Enter." > > > > That is a user interface convention. > > If you think that the web's fundamental addressing mechanism is user > interface then the gap between us is too large to be bridged in a > predictable amount of time. No. My point is that you can "link" to a post using hidden fields. So I don't see why this is so important. > > ... By that > > argument, is I urlencoded XML-RPC and passed it in > > the qu\ery string, it would no longer be RPC. > > You would also need to use the appropriate HTTP methods for each task. > (GET for queries, PUT for updates, etc.) But other then that, I can't > think of anything theoretically wrong with double-encoding query strings > as XML-RPC and then as URL encoding. It's just ugly as sin. So how do you put the terrorist images in the query string? Remember you can't pass content type. I think the only implementation of terrorist_or_not.com consistent with REST is: 1. GET URL for terrorist1 image 2. GET URL for terrorist2 image 3. PUT terrorist1.gif 4. PUT terrorist2.jpg 5. GET /terrorist/check?1=url1&2=url2 In contrast, the RPC version represents only a single request and does not force the server into deciding when it is ok to garbage collect the images. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I'm not sure what Plan9 has to do with anything, but I am curious how resource synchornization works. What happens when two apps try to write/read the /net/cs file? Is it locked? -Alex- On Fri, 25 Jan 2002, Jeff Bone wrote: > "S. Alexander Jacobson" wrote: > > > Terrorist_or_not.com passes two arguments to a > > procedure on the server and that procedure returns a > > value. > > > > You cannot intepret the interaction as anything > > like either reading, writing, or appending to a > > file. > > You *absolutely* can. Consider Plan 9: its networking mechanism presents a > set of services which look like files: they can be opened, read, written to > etc. to communicate with the services in question. For e.g. name resolution, > the client opens a file (something like) /net/cs (i.e., "connection server" is > reified as a "file") writes a string like "www.foo.com", then reads the file > contents back to receive something like "209.224.18.5". That is *just like* > what you're describing above, with the exception that you're only passing a > single parameter. (Other Plan 9 services accept multiple "parameters" in this > fashion.) > > > As I said before, sometimes you want something > > other than HTTP. Sometimes you want something > > other than REST. > > This is really getting old, Alex. Sigh. Mark, let me say now how very sorry > I am for having put you through this, now that I see how it looks from the > other side of the fence. ;-) > > jb > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I've learned a lot in this discussion, but I think I am done. Here are my conclusions: 1. The distinction between RPC and REST is incoherent. We are really talking only about side-effects. Since there are many interesting queries that involve message bodies, and HTTP defines only GET as having no side-effect, REST doesn't help you much. Thinking of applications as simple messages between entities gets you just as far (if not farther). 2. You certainly CAN implement the actual delivery of email using HTTP rather than SMTP. I just don't think it provides you with a lot of value. I think it makes more sense to focus on tracking and controlling email messages which I think is orthogonal and doesn't crash you into an installed base. To put it another way, adding monitoring tools for mail servers that expose an HTTP interface seems like a good idea. Bothering to replace SMTP itself with HTTP seems much less useful (and irrelevant to the better activity!). Feel free to agree/disagree. I am done with this argument either way. -Alex- PS I am really impressed with how powerful HTTP persistent connections can be. Thank you for the insight. ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > No. The spec leaves it up to the recieving > application. You're telling me that the SMTP spec gives SMTP implementations permission to discard messages according to their own discretion? > ... If you want to claim this is a new > protocol then it is a one line protocol: > > only process any given message-id once. > > Also, in good implementations duplicate messages > should be very rare. See RFC1047. If SMTP was reliable RFC1047 wouldn't need to exist. Can we quit arguing about it? SMTP is not reliable! It has some error reporting capabilities for use in relaying circumstances. That has nothing to do with my "reliable HTTP" paper. >... > No. My point is that you can "link" to a post > using hidden fields. So I don't see why this is > so important. Can I make an RDF assertion about it? Can I make an XLink to it? Can I bookmark it in a browser? Can I download it in an XSLT file? Can I dictate it to my mom over the phone? Can I put it on the side of a bus? Can I make a Windows "Internet Shortcut" to it? Can I use it as input to wget? Can I link to it from inside a PDF or Powerpoint? Can I report it in an HTTP header? Can I apply an ACL to it? >... > So how do you put the terrorist images in the > query string? Remember you can't pass content > type. You would use POST. > ... > In contrast, the RPC version represents only a > single request and does not force the server into > deciding when it is ok to garbage collect the > images. As I've said a dozen times, you could use POST. It would not be RPC because you aren't setting up a private addressing scheme, you aren't telling the target what to do with a method name. Using POST for non-idempotent things is not a big deal. It is *usually* bad style because it is *usually* a way around giving resources addresses. It is also not cachable. But given the option of doing it in a straightforward way using POST and embedding it in a silly RPC with a method name, it seems obvious that the method name is useless. Paul Prescod
I don't want to start the argument again, but: * Side effects are not the issue. * Addressability is the issue. Using POST for things that have no side effects is USUALLY a waste because USUALLY such things should be addressable and using POST is a way of getting around making them addressable. If there are good reasons not to make them addressable (e.g. it is a huge binary which is not realistically usable as an address) then by all means use POST. Even use FTP. Or UDP. REST is about making things addressable. In most real-world applications this matters. Paul Prescod
> This is really getting old, Alex. Sigh. Mark, let me say now how very sorry > I am for having put you through this, now that I see how it looks from the > other side of the fence. ;-) Heh. Well at least you listened. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > XML-RPC uses POST too. But you deny that it is REST! If you do a POST to do a DELETE, firewalling/caching don't work so good. If a POST is the only way to GET, you can't hyperlink or bookmark or email to friends, etc. If a GET does a DELETE, spiders will walk your site and wreak havoc. Say what you mean and mean what you say. We need to all hang together or we will surely all hang separately.
On Fri, 25 Jan 2002, Paul Prescod wrote: > I don't want to start the argument again, but: > * Side effects are not the issue. > * Addressability is the issue. Ah. Ok. I get it. You want every email message to be available via HTTP --until it is acknowledged or times out-- so you can POST replies to message URLs. You want to check presence via HTTP. all cool. So the issue with RPC is that you are concerned that people will use it to hide query values. This makes sense when the value of the query may change or when the size of the value is larger than the size of the URL! So MIME-RPC conventions are useful either way. I just need to add the following to the spec: When using MIME-RPC over HTTP, implementations SHOULD interpret the query string of GET requests as a MIME body with content type <code>application/x-www-form-urlencoded</code> if it contains an "=" and as a body without content-type otherwise. Implementations should not expose state-changing methods via GET. However, methods exposed via GET should also work via POST. Would that work for everyone? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> PS I am really impressed with how powerful HTTP > persistent connections can be. Thank you for the > insight. Don't thank me, thank John Tigue.
"S. Alexander Jacobson" wrote: > >... > > Ah. Ok. I get it. You want every email message > to be available via HTTP --until it is > acknowledged or times out-- so you can POST > replies to message URLs. You want to check > presence via HTTP. all cool. Right! > So the issue with RPC is that you are concerned > that people will use it to hide query values. Right. > This makes sense when the value of the query may > change or when the size of the value is larger > than the size of the URL! Don't know what you mean by that. > So MIME-RPC conventions are useful either way. Of course. It all comes down to: "MIME-RPC is the most important thing." ;) > ... I > just need to add the following to the spec: > >... > > Would that work for everyone? Well I would deprecate the RPC conventions and change the name but other than that...I guess its fine. Paul Prescod
> Mark Baker wrote: > > > > Ok, how about a new approach. > > > > Let's say you and I each have an SMTP, FTP, and HTTP server on our > > machines. Without any further agreement between us, which one can be > > used to do the most things? > > Well it depends how they are configured. I'd guess it would have to be > wide open to do anything useful. Can you make a strong case that a wide > open HTTP server is more "powerful" than a wide open FTP server? Either > can PUT, GET, DELETE. And FTP servers have directories that you can > append to.... But only in a PUT way, not POST. Anyhow, I was going to get into feature negotiation (Accept-*), response codes, headers like Content-Location and Location, etc.. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Fri, 25 Jan 2002, Paul Prescod wrote: > > I am not an expert either, but I believe that > > with SMTP, the sender keeps trying to SEND until > > it gets an OK from the Reciever. The reciever > > should use the message-id to recognize repeat > > sends and deliver once to the user. > > > > Scanning the SMTP spec, I don't see anything about message ids. The word > "message-id" is never mentioned once. The word "retry" is never > mentioned. I am looking at RFC2821. It has a whole section on "Retry stratgies." Message-id is covered in RFC2822. The spec does not explicitly cover using message-ids in retry context, but SMTP agents may obviously use it for exactly this purpose. > > Does something magical happen when some content > > moves from the body to the url? > > That should be obvious. When you move content to the URL, the compound > URL becomes addressable: > > * http://www.google.com/search?hl=en&q="Paul+Comstock" > > versus > > "Go to http://www.google.com/ Type in Paul Constock. Hit Enter." That is a user interface convention. By that argument, is I urlencoded XML-RPC and passed it in the qu\ery string, it would no longer be RPC. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Mark Baker wrote: > Let's say you and I each have an SMTP, FTP, and HTTP server on our > machines. Without any further agreement between us, which one can be > used to do the most things? I think we send/recieve far more email than we use the web. The volume on this list completely crowds out any time we might spend web surfing :-). (If you are reading your email through the web, you are still relying on SMTP to get it there!) More seriously. If I had to choose whether to be without email or the web, I would choose to be without the web. HTTP as it stands has no way to do relying and I like the option to read my email offline :-). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"AsyncOS is optimized for asynchronous tasks like Internet Messaging. AsyncOS includes a unique new file system, an I/O-driven scheduler, and a revolutionary new threading model." What's an "asynchronous task?" One where the server doesn't send back an answer until later? How would you optimize an operating system for such a task? Paul Prescod
"S. Alexander Jacobson" wrote: > I'm not sure what Plan9 has to do with anything, The point of the Plan 9 anecdote is that it stands as an existance proof invalidating your claim that parameter passing to a procedure cannot be modeled as file IO. Certainly almost anything --- and maybe *anything* --- that can be modeled as parameter passing to a procedure can be modeled as generic stream IO on a file / resource. Plan 9 an example of making various things --- including active "data producing processes" --- look like files. The original idea of UNIX, broken by the introduction of sockets, was to make everything look like a file. Plan 9 was an attempt by most of the original authors of UNIX to go back and push that concept to the limit, unifying everything as resources (files) in a single namespace sharing a single generic stream IO interface. I bring it up because it's a great example of how to do the *kind* of thing we're talking about here, albeit in a different namespace with a different generic interface. It's a *great* case study, though; I didn't really "get" REST until I started thinking about how things are modeled in Plan 9 as an analogy. (Side note: in a private e-mail with Roy Fielding around the time I had my REST gestalt, I pointed out the Plan9 analogy; he claimed that he'd wished he'd been more familiar with / had some citations for it a while back --- he apparently agreed with me and thought the analogy useful and appropriate.) > but I am curious how resource synchornization > works. What happens when two apps try to > write/read the /net/cs file? Is it locked? In Plan 9, every process has a private view of the namespace. For example: 8 1/2, the Plan 9 window system, represents the mouse as /dev/mouse, IIRC. 8 1/2 itself handles synchronization and acts as the multiplexer / demultiplexer for events generated by this device; each process sees its own private version of /dev/mouse; a process which opens and reads this file will read a stream of only those events generated in the window in which the process is running. In other words, mux and sync are generally handled in Plan 9 by whatever "server" presents a given service as a resource, in whatever manner is appropriate for that service. $0.02, jb
"S. Alexander Jacobson" wrote: > Ok. I guess I'm just not getting how posting two > images to a URL is resource modeling. The question isn't what you're posting, it's what you're posting *to.* > Suppose there was another argument, that had one > of two values: isTerrorist | isFed > > Would that make it non-Restful? What makes something RESTful isn't what you're posting, its how you present the service in HTTP / URI-space. > I don't understand why SMTP doesn't do what you > want. This is a *very simple* point. Listen closely. It doesn't do what we want it to so because it doesn't present as resources that can be interacted with via the generic HTTP interface. > HTTP is inherently unreliable. SMTP is only in > practice unreliable because the implementations > suck. This is a red herring at best, wrong at worst. There's no reason to believe SMTP is any more or less reliable than HTTP --- indeed, given the DNS-driven and routed nature of SMTP it's architecturally *more* susceptible to reliability problems than HTTP. > Ok. So the big bonus here is that my email > address is http://i2x.com/~alex rather than > alex@.... GETting this URL would retrieve my > homepage or some form of status information and > POSTing to it would send me an email. > > Interesting, but I guess I just don't see so much > value there. Can't help you there. Keep thinking about it. > They are all fine. What I fail to get is what > exactly you don't like about RPC. It creates new namespaces, and "hides" things that are more usefully exposed. It also compounds complexity and creates tighter coupling between the producer and consumer of some information, service, etc. It's also historically been a bad approach for building vast-scale distributed systems: system built atop CORBA, DCOM, ONC, DCE, etc. have never had the kind of deployment / adoption that the Web has had. Why? The REST hypothesis on this is that it's inherently related to the nature of RPC vs. HTTP. > > I still haven't seen any single point you've raised that addresses Mark > > Baker's fundamental challenge, which is > > > > "Show me an application that I can't do with HTTP." > > I answered this before. Nope. > My answer was show me > an application that you can't do with SMTP. And we did this: the Web. $0.02, jb
"S. Alexander Jacobson" wrote: > > It may be possible to use SOAP with HTTP --- Mark's got a better read on the current > > state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do. > > It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP. > > I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through > > HTTP. > > I don't see what the difference is between XML-RPC > and Mike's solution to the terrorist-or-not.com > problem. I know. Keep thinking about it. If you really work at it, you'll get it. I did and I was *almost* as stubborn about these *same arguments* as you. > XML-RPC uses POST too. But you deny that it is > REST! It's not what method is used, it's HOW its used. jb
"S. Alexander Jacobson" wrote: > I've learned a lot in this discussion, > but I think I am done. Hallelujah! :-) jb
I've heard REST and Linda compared often. I've never learned Linda (or JavaSpaces etc.) so I don't see how the references are relevant. What is the relationship to Linda? How is a "resource" isomporphic to a "tuple space"? How are the HTTP methods isomorphic to Linda out(), in(), rd(), eval()? Historically speaking, was HTTP designed to be "like" Linda? I note the following claim for IBM's TSpaces: * Data is de-coupled from programs. Data can outlive its producer (because once it's produced, it lives in tuple space) and can be produced before the receiver exists. * Communication is anonymous. The sender needn't know about the receiver, and vice-versa. Sender and receiver only need to know about tuple space, which mediates all communication. * Communication is asynchronous. The sender and receiver don't have to rendezvous to communicate; the producer produces when it's ready, and the consumer consumes when it's ready. None of these seem to apply to HTTP to me. I have no doubt that you could build a Linda layer on top of HTTP but I have trouble seeing how it is "already there." Paul Prescod
How ironic... ----- Original Message ----- From: +ADw-postmaster+AEA-mail.hotmail.com+AD4- To: +ADw-mdierken+AEA-hotmail.com+AD4- Sent: Saturday, January 26, 2002 12:32 AM Subject: Delivery Status Notification (Delay) +AD4- This is an automatically generated Delivery Status Notification. +AD4- +AD4- THIS IS A WARNING MESSAGE ONLY. +AD4- +AD4- YOU DO NOT NEED TO RESEND YOUR MESSAGE. +AD4- +AD4- Delivery to the following recipients has been delayed. +AD4- +AD4- rest-discuss+AEA-yahoogroups.com +AD4- +AD4- +AD4- +AD4-
Paul Prescod wrote: > What is the relationship to Linda? It's loose, at best. Some of us have made the claim --- admittedly rather poorly substantiated --- that HTTP forms a kind of "coordination language" similar to Linda in its potential application. We haven't done a particularly good job of explaining what that means and, indeed, the very notion of a "coordination language" is rather underdefined. > How is a "resource" isomporphic to a "tuple space"? Wrong abstractions. If the analogy holds, the resource space is analogous to a tuple space, and a single resource is analogous to a tuple. This is an inexact analogy; most Linda implementations allow associative matching via any permutation of tuple fields; if you imagine resources to be tuples of the form (URI, ...) then the Web only allows matching of tuples via the URI field. > How are the HTTP methods isomorphic to Linda out(), in(), rd(), eval()? NB: the eval() construct appeared in lots of early papers but its semantics proved fairly fuzzy and its implementation difficult. It's usually been dropped or ignored by almost all later Linda and Linda-like systems. For the others, the mapping is pretty straightforward if a bit inexact. out() is like PUT, rd() is like GET, and in() is like an atomic GET+DELETE. It's important to understand that most distributed algorithms using Linda as a coordination paradigm strongly require the latter in() semantics, which are obviously missing in HTTP. > Historically speaking, was HTTP designed to be "like" Linda? AFAIK, it wasn't. > * Communication is asynchronous. The sender and receiver don't have to > rendezvous to communicate; the producer produces when it's ready, and > the consumer consumes when it's ready. This is true. Linda proceeds from a fundamentally asynchronous bias, and builds synchronous protocols atop as-needed. A generative HTTP system would take the reverse approach. > None of these seem to apply to HTTP to me. Data decoupled from process: data artifacts can easily be generated and placed at URI where the persist after the producer is finished. Communication is anonymous, in the sense of producer and consumer don't have to "know" each other, and communication is mediated by the TS: same thing for the Web, all producer and consumer have to "know" about each other is how to address the resource artifacts each produce in the URI space, and HTTP's generic methods and architecture mediates the connection. (Consider that a consumer is actually connecting to a generic server and communicating via a generic protocol with the information space the server maintains --- analogous to most implementations of TS.) The big difference is the asymmetry: producer and consumer use the same interface in Linda systems, while primarily the consumer case is standardized in HTTP. The Web is "read-mostly." > I have no doubt that you > could build a Linda layer on top of HTTP but I have trouble seeing how > it is "already there." It's not. The claim isn't that the Web *is* Linda, it's that the GET, PUT, POST, etc. methods on URI space form a coordination language in the same sense Linda does --- but with different coordination primitives. I like the idea, but it's not clear that the claim is useful. ;-) jb
--- Paul Prescod <paul@...> wrote: > I've heard REST and Linda compared often. I've never learned Linda (or > JavaSpaces etc.) so I don't see how the references are relevant. <snip> > I have no doubt that you > could build a Linda layer on top of HTTP but I have trouble seeing how > it is "already there." RogueWave has "Ruple", a tuple space based on XML and HTTP. Unfortunately the HTTP interface seens to be based on SOAP RPC's. From a cursory glance at their white paper, it doesn't look like anything within the space is given a URI. See http://www.roguewave.com/developer/tac/ruple/. Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
One of the major advantages of REST is that it is designed so that intermediaries understand what is going on and can thus do the right thing. But what if users decide that they do NOT want intermediaries to understand what is going on? What if I don't want AOL to know I'm surfing porn? Paul Prescod
Jeff Bone wrote: > > Paul Prescod wrote: > > > What is the relationship to Linda? > > It's loose, at best. Some of us have made the claim --- admittedly rather > poorly substantiated --- that HTTP forms a kind of "coordination language" > similar to Linda in its potential application. We haven't done a > particularly good job of explaining what that means and, indeed, the very > notion of a "coordination language" is rather underdefined. Ahh. Too bad. I was hoping that Linda was to HTTP as the Lambda Calculus is to Scheme. > > How is a "resource" isomporphic to a "tuple space"? > > Wrong abstractions. Sorry. I meant resource to tuple. >... > For the others, the mapping is pretty straightforward if a bit inexact. > out() is like PUT, rd() is like GET, and in() is like an atomic GET+DELETE. Interesting that there is no POST. POST is the Web's achilles heel in many ways. It isn't obvious that it is necessary but it is also the "most popular" method in that people tend to fall back on it when they are too lazy to figure out the others. > It's important to understand that most distributed algorithms using Linda as > a coordination paradigm strongly require the latter in() semantics, which are > obviously missing in HTTP. Grumble...why couldn't this all map nicely. >... > Data decoupled from process: data artifacts can easily be generated and > placed at URI where the persist after the producer is finished. Sort of. But if the Google guys turn off Google it goes away. There is no big tuplespace in the sky keeping track of every URI ever generated. Thank god! > Communication is anonymous, in the sense of producer and consumer don't have > to "know" each other, and communication is mediated by the TS: same thing > for the Web, all producer and consumer have to "know" about each other is how > to address the resource artifacts each produce in the URI space, and HTTP's > generic methods and architecture mediates the connection. >... > > It's not. The claim isn't that the Web *is* Linda, it's that the GET, PUT, > POST, etc. methods on URI space form a coordination language in the same > sense Linda does --- but with different coordination primitives. Too bad they are different. I guess most CS analysis of Linda will not apply to the Web. > I like the idea, but it's not clear that the claim is useful. ;-) Yep. Paul Prescod
--- Paul Prescod <paul@...> wrote: > One of the major advantages of REST is that it is designed so that > intermediaries understand what is going on and can thus do the right > thing. But what if users decide that they do NOT want intermediaries to > understand what is going on? What if I don't want AOL to know I'm > surfing porn? Use a secure proxy, like http://www.privasec.com. Of course you still have to trust the proxy, but AOL only sees you connection to the proxy site, not the ultimate destination. Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Jim Ancona wrote: > >... > > Use a secure proxy, like http://www.privasec.com. Of course you still have to > trust the proxy, but AOL only sees you connection to the proxy site, not the > ultimate destination. Okay, but if I do this, am I not disabling AOL's proxy? That's my point, if privacy becomes "popular" won't it destroy intermediaries? Paul Prescod
This is a very good thread, btw. :-) Paul Prescod wrote: > Interesting that there is no POST. POST is the Web's achilles heel in > many ways. It isn't obvious that it is necessary but it is also the > "most popular" method in that people tend to fall back on it when they > are too lazy to figure out the others. I suppose that in some vague way POST is analogous to eval(). Eval() always proved problematic in any formalization of Linda semantics, just as POST is rather problematic --- and in both cases . In both, data is put into the information space, evaluated, and results in new information. Interesting to note that in POST --- due to the synchronous nature of HTTP - a single write/read is required, but with eval()/in() a dual write/read is required. Another difference is that eval is a one-shot thing that turns into a single data tuple, while a POSTable resource is a persistent thing that produces successive information without necessarily creating new tuples / resources. More later, jb
Jeff Bone wrote: > This is a very good thread, btw. :-) > > Paul Prescod wrote: > > > Interesting that there is no POST. POST is the Web's achilles heel in > > many ways. It isn't obvious that it is necessary but it is also the > > "most popular" method in that people tend to fall back on it when they > > are too lazy to figure out the others. > > I suppose that in some vague way POST is analogous to eval(). Eval() always proved > problematic in any formalization of Linda semantics, just as POST is rather > problematic --- and in both cases . Woops. In both cases much of the power of the paradigm is in these underdefined operations. :-) jb
--- Paul Prescod <paul@...> wrote: > Jim Ancona wrote: > > Use a secure proxy, like http://www.privasec.com. Of course you still have > to > > trust the proxy, but AOL only sees you connection to the proxy site, not > the > > ultimate destination. > > Okay, but if I do this, am I not disabling AOL's proxy? That's my point, > if privacy becomes "popular" won't it destroy intermediaries? Certainly, but if you don't trust AOL, then disabling their proxy is a feature! Privasec is still proxying your traffic, but you trust them (or you shouldn't be using them). So privacy concerns should cause traffic to migrate from untrusted to trusted intermediaries. Proxying by a trusted intermediary may improve privacy, since connections can't be traced directly to your IP, and your traffic is aggregated with that of other users of the proxy. Whom you should trust is an interesting question. For example, Privasec, nee' Safeweb had the CIA as an investor at one point. Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Lucas Gonze wrote: > >... > > An HTTP request is asymetric with regard to state. Client state is opaque, > except that it must have enough state to interpret a response. Server state is > exposed using HTTP methods. Clients have always been less prone to security > problems than servers, because they expose so much less state. The only client > resource exposed is the state machine that performs the request. For a callback > sink to be no less secure than a client request, the only resource the sink can > expose is a similar state machine. Why do you call this a state machine? Note that as soon as you do a callback you are exposing the fact that you are running software that accepts HTTP connections. I could see that as having security implications if that software is poorly written but there isn't much we can do about that. Paul Prescod
paul said: > Why do you call this a state machine? An HTTP requester has these state transitions: 1) connecting to the server 2) writing the request 3) reading the response #2 assumes #1, #3 assumes #1 and #2. In any callback message, #1 and #2 can't be assumed. Responses happen in the context of specific prior requests and specific prior connections. Designers of a callback scheme have a burden of proof to show that messages can be strongly correlated with earlier requests and connections. For example, Jeff's authentication scheme is intended to meet the requirement for correlation. > Note that as soon as you do a callback you are exposing the fact that > you are running software that accepts HTTP connections. I could see that > as having security implications if that software is poorly written but > there isn't much we can do about that. Yeah, this is why I said that server socket implementations were already necessarily paranoid and that would have to be good enough. But after a few days of mulling over my message about security, your proposal about protocol-level support for callbacks, and my earlier message about application-level support for callbacks, I have changed my mind. I now believe that callback schemes must avoid a requirement that sinks act as HTTP/1.1 servers. Requiring clients to act as HTTP/1.1 servers is a fatal security problem. No competent security admin would let it happen. Saying there isn't much we can do about it is hand waving. If we don't address it, we won't succeed at making a general purpose notification facility available. (I don't mean by "we" that there is something analogous to a WG. I mean "we" in the sense of "the cat herd nibbling away at the problem of HTTP notifications.") - Lucas
> I now believe > that callback schemes must avoid a requirement that sinks act as HTTP/1.1 > servers. There are only a few options that avoid this: (1) held connections ala KN, (2) polling, or a new, as-yet unspecified gender-changing intermediary coupled with (1) or (2). I don't particularly like any of these, do you? > Requiring clients to act as HTTP/1.1 servers is a fatal security problem. Why? Running such on a "client" is no worse than running one on a "server" in the first place. > No > competent security admin would let it happen. Let's design for the application, okay, rather than the admin. Administration is a significant but separate series of concerns. What about server-server callbacks, meaning callbacks from server-class machine to server-class machine, both in actively administered environments, both already running HTTP server software? In this case, you're not really compromising the security of either system, are you? I would suggest that the scope of this effort is to determine how to allow one resource-modeled entity to register an interest in state changes of a second resource and subsequently receive notifications from that second resource. Such a scope presumes that both systems hosting these resources can symmetrically initiate connections and that both systems are secured at an appropriate level by their respective administrators. Asymmetry of connectivity is a separate issue. $0.02...? jb
> > > I now believe > > that callback schemes must avoid a requirement that sinks act as HTTP/1.1 > > servers. > > There are only a few options that avoid this: (1) held connections > ala KN, (2) > polling, or a new, as-yet unspecified gender-changing intermediary > coupled with (1) > or (2). I don't particularly like any of these, do you? ..see following message for detailed comments. > > Requiring clients to act as HTTP/1.1 servers is a fatal security problem. > > Why? Running such on a "client" is no worse than running one on a > "server" in the > first place. Many many reasons. The risks of running public servers are well known. They are administered by skilled specialists and even so are generally outside (or right on) the firewall. The skill and commitment of users is lower. The machine setup is less secure. > > > No > > competent security admin would let it happen. > > Let's design for the application, okay, rather than the admin. > Administration is a > significant but separate series of concerns. For once I am describing admins as competent bots rather than incompetent ones. This doesn't happen often. s/competent security admin/competent userbot/ > > What about server-server callbacks, meaning callbacks from > server-class machine to > server-class machine, both in actively administered environments, both already > running HTTP server software? In this case, you're not really > compromising the > security of either system, are you? > > I would suggest that the scope of this effort is to determine how to allow one > resource-modeled entity to register an interest in state changes of a second > resource and subsequently receive notifications from that second > resource. Such a > scope presumes that both systems hosting these resources can > symmetrically initiate > connections and that both systems are secured at an appropriate level by their > respective administrators. Asymmetry of connectivity is a separate issue. I think that it's a good idea to separate the requirements for callbacks between server-class pairs and between server/client pairs. I think that notifications between server pairs are great functionality. I don't think that the problem will be solved until clients can receive notifications. (More to follow). - Lucas
Lucas Gonze wrote: > Many many reasons. The risks of running public servers are well known. They > are administered by skilled specialists and even so are generally outside (or > right on) the firewall. The skill and commitment of users is lower. The > machine setup is less secure. None of this is unique to HTTP. Essentially you are arguing against any sort of decentralized system where nodes have symmetric connectivity and no fixed client / server roles. You've just given the administrative argument against p2p in any sense. IMO, it's important to recognize that, while security should be considered and dealt with, the *way* it's dealt with today (i.e., network admins who build walls around their castles) imposes severe obstacles to creation and proliferation of new, innovative technologies. It also *dramatically* lowers the value of the network as a whole; since the value rises with the number of possible interconnections between nodes, the fact that most of the nodes in the Web today are clients and cannot be connected *to* is a serious value constraint. Without discounting the need for *security,* it's important to recognize that *network admins* and their administrative practices which cause asymmetric connectivity are in fact damage and must be routed around if we're to get maximum value out of this network-thingie we've built. ;-) jb
In the following proposal I suggest a secure mechanism for event notifications. The purpose of this design is to maximize security. As with all my recent work, e.g. the aREST design for application-level notification support, it is an experiment to explore a particular aspect of the problem space. Many solutions for implementing HTTP notifications use callbacks to a sink-side HTTP server. However running a full featured HTTP server creates very serious security problems. From a security perspective an ideal solution would be only a little less secure than running an HTTP client, and running a full server makes that impossible. The sink must operate a protocol designed for extreme paranoia. I will call this protocol "Paranoid Sink Protocol", or PSP. The goal of PSP is to make HTTP event notifications secure. The name "PSP" is a placeholder -- it may or may not be HTTP. PSP exists exclusively to notify HTTP clients that they should initiate an HTTP request. All risky activities are performed via requests, thus preserving the existing security levels of web clients. DESIGN ======= Here is a sample of a PSP transaction: 1) A client uses HTTP 1.0 or later to request notifications on a resource. The client provides a PSP URI. The client and server construct a secure ticket to identify valid PSP notifications. The ticket might, for example, be a public key or a secret token. The server provides a URI for picking up events once notification has been received. 2) Time passes. 3) The source node emits a PSP notification. The notification contains only enough information to validate the ticket. It does not contain the callback address. It is a fixed length to prevent buffer overflow attacks. 4) The sink validates the ticket and disconnects without a response of any kind. 5) The sink requests the event from the event pickup URI. To prevent port scanning, PSP does not return either a TCP ACK or an HTTP response. However there does exist an ACK in the form of the sink poll in #5 above. A source MUST assume that a #3 notification not followed by a #5 poll has not been received. To prevent buffer overflows and to make TCP unnecessary, PSP uses fixed length messages. 512 bytes should be enough. To protect the sink from malicious parties, notifications MUST be idempotent. The sink need not store any information about the message after transmission. All notifications and polls related to a specific ticket are identical. A single poll picks up all stored messages. IMPLEMENTATION ============== For an implementation of PSP, HTTP 0.9 fits perfectly. It can legally ride over UDP or IP, does not require any response at all, and only supports idempotent operations. Its brutally trivial nature makes implementations orders of magnitude easier to secure than HTTP 1.1 implementations. The security of PSP is dependent on security of the (#1) event subscription and ticket negotiation. Adequate security of #1 is a big what-if. Design of the ticket negotiation is a challenge to be taken seriously. To prevent packet sniffers from spoofing notifications, the ticket should be renegotiated at each (#5) request. Since the request will not be observable before the first notification is sent, and subsequent notifications (spoofs or not) have no effect, sucessful spoofing will have no worse an effect than sending random packets. It is apparent that, due to the requirement that notifications must be followed up with a request, PSP is not designed for performance. The only problem it addresses is security. See http://www.w3.org/Protocols/HTTP/AsImplemented.html for the HTTP 0.9 specification. - Lucas
Lucas Gonze wrote: > >... > > Many solutions for implementing HTTP notifications use callbacks to a sink-side > HTTP server. However running a full featured HTTP server creates very serious > security problems. From a security perspective an ideal solution would be only > a little less secure than running an HTTP client, and running a full server > makes that impossible. Who says you need to run a "full server"? We can explicitly define a minimal profile of HTTP that a callback target must support. The security dudes are going to be unhappy with any system that allows people outside to open connections to people inside. But that's the very nature of a callback. We can "route around" them using persistent connection hacks etc. But first we should design as if we didn't need to do that. > 1) A client uses HTTP 1.0 or later to request notifications on a resource. The > client provides a PSP URI. The client and server construct a secure ticket to > identify valid PSP notifications. The ticket might, for example, be a public > key or a secret token. The server provides a URI for picking up events once > notification has been received. Can't the ticket be embedded in the PSP URI? > 3) The source node emits a PSP notification. The notification contains only > enough information to validate the ticket. It does not contain the callback > address. It is a fixed length to prevent buffer overflow attacks. What is the danger in containing the callback address? We could set up a maximum length on these things of 2048 bytes or something. > 4) The sink validates the ticket and disconnects without a response of any kind. Okay, so this is clearly NOT HTTP. HTTP requires a response. What's dangerous about a formulaic 200 OK response? > 5) The sink requests the event from the event pickup URI. Okay. > To prevent port scanning, PSP does not return either a TCP ACK or an HTTP > response. However there does exist an ACK in the form of the sink poll in #5 > above. A source MUST assume that a #3 notification not followed by a #5 poll > has not been received. What does "followed by" mean? How long does the client have? > To prevent buffer overflows and to make TCP unnecessary, PSP uses fixed length > messages. 512 bytes should be enough. > > To protect the sink from malicious parties, notifications MUST be idempotent. > The sink need not store any information about the message after transmission. > All notifications and polls related to a specific ticket are identical. A > single poll picks up all stored messages. Don't think that single-poll thing is very REST-y. The client and the server should not need to share an understanding about who has what messages. The client should control when it deletes a message on the server. The server can also impose timeout or space usage policies. >... > > For an implementation of PSP, HTTP 0.9 fits perfectly. It can legally ride over > UDP or IP, does not require any response at all, and only supports idempotent > operations. Yes it does! http://www.w3.org/Protocols/HTTP/AsImplemented.html HTTP has always had a response. >... > To prevent packet sniffers from spoofing notifications, the ticket should be > renegotiated at each (#5) request. Why not address packet sniffing (and perhaps all server-authentication) using SSL? "The response to a simple GET request is a message in hypertext mark-up language ( HTML ). This is a byte stream of ASCII characters." Paul Prescod
Sorry, I just can't get behind any solution to this problem that requires asymmetric protocols. This is damaging to the overall value proposition of the Web. While I have complete respect and sympathy for the folks that have to deal with network administration and security --- indeed, they are my customers in my commercial endeavors --- from a pure innovator's perspective this just doesn't cut it. It artificially inhibits the proliferation of new technology. We dealt with this problem ad nauseam at Activerse, where we built the first and AFAIK to date only truly decentralized presence and instant messaging infrastructure. We tried to acquiesce to the needs of the network admin, and ultimately that was our undoing --- we couldn't sell our technology into enterprises because it required an active decision on the part of the network admin, whose job longevity is proportional to their success in preserving the status quo. By requiring the active support and involvement of the network admin, we limited our ability to deploy into the very environment we were attempting to target and build for. We would've been much more successful had we simply (ab)used HTTP, using it in a decentralized way and tunneling HTTP through HTTP itself. "Extending" (i.e., figuring out how to use) HTTP for symmetric and asynchronous application communication patterns is a good idea. Introducing new protocols and new asymmetries is not. Other problems with this suggestion: it doesn't make a whole lot of sense to use HTTP 0.9 as the PSP. The only method supported by HTTP 0.9 IIRC is GET, which doesn't make any sense for a notification. It's not clear what meaningful responses could be returned, either. jb
> None of this is unique to HTTP. This is false in a way that helps illuminate solutions: simplicity leads to security, because fewer lines of code have fewer bugs to exploit. Something simpler than HTTP 1.1 would be more secure.
Lucas Gonze wrote: > > None of this is unique to HTTP. > > This is false in a way that helps illuminate solutions: simplicity leads to > security, because fewer lines of code have fewer bugs to exploit. Something > simpler than HTTP 1.1 would be more secure. You're confusing abstraction with implementation. You're correct in that supporting a full HTTP 1.1 inevitably results in more code than just HTTP 0.9, and the probability of security-compromising bugs is proportional to the amount of code. But nobody said a callback service needs to support the full HTTP 1.1 --- and the MUST part of the spec is a *lot* smaller than the SHOULD and MAY parts. (Though admittedly it is still bigger than 0.9.) The point I was trying to make is that the problems you're talking about have everything to do with problems network admins have with inbound connectivity in general, regardless of the protocol used. They're suspicious of *any* requestable service running on the client machine. If we're going to build any form of callback that we really believe will get deployed, we're going to have to ignore this concern --- simply supporting a smaller protocol with a smaller, verifiable implementation won't suffice to overcome those fears. jb
One way to address security is to differentiate between "ordinary"
callbacks and "secure" callbacks. Ordinary callbacks are like SMTP. No
more or less secure. No paranoia.
"Secure" callbacks are created ONLY on a persistent connection created
from the client to the server, potentially using SSL.
Let's face it, that's corporate America's definition of secure
behind-the-firewall software. Outgoing is secure. Incoming is insecure.
So secure callbacks would work just like MSN messenger or ICQ or
Napster, you turn the thing on, it "calls home" and opens a connection.
Insofar as the client knows what server it has contacted, the security
requirements are much lower. After all, Web browsers have historically
been terribly insecure but the practical damage caused by them is low
because the end-user controls what sites he/she contacts. So
accountability is pretty good ("here's the URL of the site that deleted
my hard drive") and it is really hard to get a million users to come to
your site and download your virus.
The care and thought put into your PSP won't mean squat to a corporate
sysadmin. And on reflection I do think that practically speaking,
unidirectional connections provide more safety than paranoid protocol
implementations. And anyhow, it is pretty easy to set up a single
unidirectional connection to your "event server" on the Web and let it
handle the security crap for you.
Paul Prescod
Jeff said: > You're confusing abstraction with implementation. You're correct in that > supporting a full HTTP 1.1 inevitably results in more code than just HTTP 0.9, > and the probability of security-compromising bugs is proportional to > the amount > of code. But nobody said a callback service needs to support the > full HTTP 1.1 > --- and the MUST part of the spec is a *lot* smaller than the SHOULD and MAY > parts. (Though admittedly it is still bigger than 0.9.) It a _lot_ bigger! > The point I was trying to make is that the problems you're talking about have > everything to do with problems network admins have with inbound > connectivity in > general, regardless of the protocol used. They're suspicious of *any* > requestable service running on the client machine. Right, and it is correct to blow off incompetent adminbots. We should be designing for competent adminbots. They do exist.
Lucas Gonze wrote: > Right, and it is correct to blow off incompetent adminbots. We should be > designing for competent adminbots. They do exist. Go ahead and design for them, Lucas. Give them nobs to twiddle. I've been down that road, and from a technology adoption perspective IMO it's uninteresting. jb
Lucas Gonze wrote: > > > None of this is unique to HTTP. > > This is false in a way that helps illuminate solutions: simplicity leads to > security, because fewer lines of code have fewer bugs to exploit. Something > simpler than HTTP 1.1 would be more secure. I would be open to defining an explicit HTTP 1.1 profile. But by talking about returning nothing, (in violation of the HTTP spec) you're going beyond that. I agree with Jeff that we should design first, as if there were no firewall and then figure out tunnelling later. The tunnelling isn't rocket science and it has the virtue of putting the end-user into ultimate control. it can kill the pipe whenever it wants and the server no longer has a way to get in contact with it. That feels safer to me. When the little "tunnel" icon is gone from my system tray I can know that there is *no way* anybody could be talking to my box because it is invisible to the Web. Paul Prescod
I agree that we should presume regular HTTP and then tunnel for the paranoid sysadmin. They'll prefer tunelling to security-paranoid design anyhow! There could actually be a business model in setting up secure event handlers that do the equivalent of spam and virus filtering. The client would open up a single connection to that service and thus have a trusted client and a trusted filtering intermediary. Rather than ignoring security it could be a virtue of the new model. Through bridges to napster, kazaa, etc., you could get generic peer-to-peer connectivity intermediated by someone who cares about and thinks about security. As I said in another note, if I'm going to bed for the night I feel safer knowing that I'm "disconnected" from the incoming Web than knowing that I am using a protocol that is ostensibly designed to be easy to secure. No matter how easy it is to secure someone may screw up so I'd rather just tunnel to the "event Web" and withdraw when I'm done with it. On an unrelated note, I am curious whether you know who coined the term "resource modelling." I think it is great. REST is the overall web architectural style but resource modelling is what individual application creators do in order to take advantage of the architecture. It is a discipline like object oriented modelling. It will eventually have its own terminology and textual/graphical notations. Perhaps it was coined by Mike D? * http://www.xent.com/pipermail/fork/2001-August/003204.html Paul Prescod
Paul said: > Who says you need to run a "full server"? We can explicitly define a > minimal profile of HTTP that a callback target must support. You bet! That what PSP is! Now, it may take a little while to craft PSP fully, but that's exactly what it'll end up being. > ecurity dudes are going to be unhappy with any system that allows > people outside to open connections to people inside. But that's the very > nature of a callback. We can "route around" them using persistent > connection hacks etc. But first we should design as if we didn't need to > do that. Sorry, no good. Security happens in the design. > Can't the ticket be embedded in the PSP URI? Don't know. Need to design the ticket with extreme care, so I wouldn't even try to answer this yet. > > > 3) The source node emits a PSP notification. The notification contains only > > enough information to validate the ticket. It does not contain the callback > > address. It is a fixed length to prevent buffer overflow attacks. > > What is the danger in containing the callback address? We could set up a > maximum length on these things of 2048 bytes or something. Danger in containing the callback address is that a malicious spoofer could redirect the sink so that it doesn't pickup from the right location. > > 4) The sink validates the ticket and disconnects without a response > of any kind. > > Okay, so this is clearly NOT HTTP. HTTP requires a response. What's > dangerous about a formulaic 200 OK response? Nope. 0.9 does not require a response. It only requires that any response that does happen be HTML. > > To prevent port scanning, PSP does not return either a TCP ACK or an HTTP > > response. However there does exist an ACK in the form of the sink > poll in #5 > > above. A source MUST assume that a #3 notification not followed by > a #5 poll > > has not been received. > > What does "followed by" mean? How long does the client have? Don't know! Good question. This is probably an application dependent variable. > > To prevent buffer overflows and to make TCP unnecessary, PSP uses > fixed length > > messages. 512 bytes should be enough. > > > > To protect the sink from malicious parties, notifications MUST be > idempotent. > > The sink need not store any information about the message after > transmission. > > All notifications and polls related to a specific ticket are identical. A > > single poll picks up all stored messages. > > Don't think that single-poll thing is very REST-y. The client and the > server should not need to share an understanding about who has what > messages. The client should control when it deletes a message on the > server. The server can also impose timeout or space usage policies. Maybe a communication problem here: a notification doesn't say which event arrived, it only says that an event arrived. The purpose is to guarantee that callback servers don't have to expose non-idempotent resources, which eliminates a large family of attacks. I didn't mean to say anything at all about whether a callback deletes messages, deletes em in a bunch, does it one by one, etc! I'd leave that definition to a conversation down the road -- this is just algorithms for now. > > For an implementation of PSP, HTTP 0.9 fits perfectly. It can > legally ride over > > UDP or IP, does not require any response at all, and only supports > idempotent > > operations. > > Yes it does! http://www.w3.org/Protocols/HTTP/AsImplemented.html > > HTTP has always had a response. 0.9 does not require a response. It only requires that any response that does happen be HTML. > > To prevent packet sniffers from spoofing notifications, the ticket should be > > renegotiated at each (#5) request. > > Why not address packet sniffing (and perhaps all server-authentication) > using SSL? > > "The response to a simple GET request is a message in hypertext mark-up > language ( HTML ). This is a byte stream of ASCII characters." SSL might be a good idea, but I'd leave that also for discussion down the road, once algorithms are in place.
I don't understand your point. There _do_ exist real security concerns, though they're not the same as incompetent admins think. > Lucas Gonze wrote: > > > Right, and it is correct to blow off incompetent adminbots. We should be > > designing for competent adminbots. They do exist. > > Go ahead and design for them, Lucas. Give them nobs to twiddle. > I've been down > that road, and from a technology adoption perspective IMO it's uninteresting. > > jb
I note that PSP is, in practice, unidirectional. :) > The care and thought put into your PSP won't mean squat to a corporate > sysadmin. And on reflection I do think that practically speaking, > unidirectional connections provide more safety than paranoid protocol > implementations. And anyhow, it is pretty easy to set up a single > unidirectional connection to your "event server" on the Web and let it > handle the security crap for you. > > Paul Prescod
How, in general, does one get from a resource to its subordinate resources? Must the resource use an entity body in a structured format with HREFs? Is there no "standard" way? If not, why not? What is the relationship (if any) behind the hierarchy expressed through "/", "." and ".." and the subordinate resource hierarchy? I think that there is no explicit relationship. Why do we need two hierarchies? Paul Prescod
Lucas Gonze wrote: > > I note that PSP is, in practice, unidirectional. :) PSP is unidirectional in the wrong way. I presume that's the source of your smiley face. As strongly as you feel about this principle of the client not revealing anything to the server, I feel that a real end-user client should not be running software that accepts TCP connections from unknown parties. So I feel that tunnelling is not only inevitable but a Good Thing. And I think that Joe Firewall is more in line with my view than yours. Paul Prescod
Paul Prescod wrote:
> On an unrelated note, I am curious whether you know who coined the term
> "resource modelling."
I beat him to it by almost two weeks:
http://www.xent.com/pipermail/fork/2001-August/002923.html
It's a curse. I'm a jargon machine. ;-)
jb
First draft for comment, hope the HTML doesn't screw anyone up.
If it does, let me know, I'll resend text-only.
ABSTRACT
The Web is a global information namespace and generic resource
interface superimposed on a degree-one network of nodes which can
connect to each other. Directionality of requests and responses
is today unfortunately intimately entangled with directionality
of connectivity, and due to firewalls connectivity is
asymmetric. This is unfortunate because interesting addressible
resources potentially exist on *all* nodes. The value of the Web
as a whole is therefore seriously and unnecessarily constrained
by the asymmetry of connectivity.
This document ("speclet") is a high-level description of two
architectural additions to the Web which, taken together, provide
a principled solution to the problem of asymmetric connectivity
and therefore allow all nodes in the network to present resources
to all other nodes. The two components are a new intermediary
type called a "semi-proxy" and a new connector type called a
"transparent tunnel." These two components may be used together
in a "switchboard pattern" to provide securable, apparent
universal symmetry of connectivity within the context of the
principled Web architecture.
TERMINOLOGY
Rather than referring to client and server roles, let's describe
the Web as consisting of open and closed nodes. Open nodes are
those that can receive inbound connections from some other nodes
of interest; i.e., they are typically "outside" a firewalled
environment. Closed nodes are those nodes that cannot receive
inbound connections from some other nodes of interest, but can
initiate connections to other nodes of interest; they are
typlically "behind" a firewall. A node's open or closed state is
referred to as its connectivity. It is desirable to consider
connectivity as orthogonal to the role a node may play in
generating or servicing HTTP requests. Any node may therefore
serve as a requestor or respondor. A requestor is a node which
initiates an HTTP 1.1 request. A respondor accepts HTTP requests
and generates HTTP responses.
A note about synchrony: HTTP is a synchronous protocol; each
HTTP request results in a synchronous / immediate response. Many
application communication patterns benefit from asynchrony; this
is usually referred to as "event notification." Overcoming
asymmetry of connectivity is an orthogonal problem to finding
useful ways to do asynchronous communication over the Web. This
document does not address asynchrony beyond simply noting that
the switchboard pattern described here provides a mechanism for
delivery of asynchronous notifications of any kind to any and all
nodes, regardless of their connectivity. It should also be noted
that the switchboard pattern described here does not assume or
anticipate any sort of request queuing mechanism, though neither
does it prevent one from being implemented. The implications of
asynchrony, queuing, and request fan-out are out of scope.
THE SEMI-PROXY
The semi-proxy component is an HTTP 1.1 responder and
intermediary which hosts a hierarchical resource namespace. It
presents a resource model which allows other nodes to "adopt" a
subtree in its resource namespace. This process is called
registration. Once a node has registered a particular subtree,
requests received by the switchboard for resources in that
subtree are "forwarded" to the registered node. The precise
mechanism by which this happens is undefined, however, in the
simplest case a new request is constructed by reformulating the
request URI relative to the registered node and generating a new
HTTP request to the registered node. The reverse path is taken
by the response, from registered node through the semi-proxy to
the original requestor. The only function the semi-proxy
provides that differentiates it from a standard proxy is a
standard transformation between the registered node's address
space and the semi-proxy's address space.
With the exception of transformations on these URI, this
resembles the action of a standard HTTP proxy. The semi-proxy
MAY perform all the same operations as any proxy with respect to
caching, handling idempotent operations, etc. The net effect of
the semi-proxy is to allow some other node to present resources
as if they were in fact resources within the switchboard's own
portion of the global resource namespace.
Note that the relationship between registered nodes and
registered subtrees of the semi-proxy's address space is assumed
for simplicity's sake to be 1-1. Fan-out to multiple registered
nodes is an interesting concept with interesting implications for
various applications, but is beyond the scope of this document.
Addressing such a fan-out begins to verge on event notification,
and is an interesting topic that needs further discussion and
consideration.
A semi-proxy SHOULD have a standard semantics for longevity of a
given registration. The ability of the semi-proxy to route
requests and responses to and from the registered node depends on
its ability to communicate with the registered node. Without
addressing asynchronous communication, this implies that each
registration should be bounded in some fashion, either by the
maintenance of a transparent tunnel connection as discussed below
or by some other heuristic.
TRANSPARENT TUNNELS
A transparent tunnel is new architectural connector type
consisting of a persistent HTTP connection established from a
closed node to some open node. It takes the form of a long-lived
GET request performed on some resource on the open node. This
connection is used to bidirectionally pass HTTP requests and
their responses between closed and open node, irregardless of
directionality of connectivity. Appropriate conventions for
framing and mux / demux of HTTP requests and their responses is
assumed. The closed node end of the tunnel is referred to as the
tail end; the open node end is referred to as the head end.
Requests arriving at the head end of the tunnel are transported
to the tail end of the tunnel, where they may be unpacked and
serviced by any appropriate mechanism. This mechanism could be
embedded in an HTTP responder directly, or could be an adaptor
which turns these requests into standard HTTP requests /
connections to a local or remote HTTP responder.
The tunnel is "transparent" in that what it transports are simply
HTTP requests and responses. A transparent tunnel is thus
securable via any standard security intermediary which is made
aware of the framing and mux / demux conventions used by the
tunnel. With transparent tunneling of HTTP through HTTP, we have
the best of both worlds: intermediaries which are aware of the
tunneling conventions and standard HTTP semantics may filter and
secure these requests as would any secure proxy.
THE SWITCHBOARD PATTERN
By coupling semi-proxies and transparent tunneling we are able to
instantiate a "switchboard pattern" for principled symmetric HTTP
connectivity. Every node - whether closed or open - becomes an
equal participant in the resource namespace. The switchboard
provides the semi-proxy resource model for registering a subtree
of its address space, and a second resource model for
establishing the head-end of the transparent tunnel. It then
routes HTTP requests it receives across the appropriate tunnel
connection, and reverses the route for HTTP responses to those
requests.
The benefits of the switchboard pattern are many. Aside from
simply addressing asymmetry of connectivity, switchboards also
provide a mechanism for dealing with ephemeral naming of edge
machines. A switchboard can provide a persistent (modulo
connectivity) namespace for an edge node's resources, despite the
fact that the edge machine may only temporarily have a particular
DNS name or IP address.
CONCLUSION
The introduction of two new connector types - semi-proxies and
transparent tunnels - to the principled architecture of the Web
enables a much richer resource space and increases the overall
value of the Web. These two connector types may be paired in a
"switchboard pattern" that mitigates the impact of asymmetrical
connectivity on the overall architecture of the Web, and provides
a means of dealing with the ephemeral nature of host naming at
the edges of the network.
Lucas Gonze wrote: > I don't understand your point. There _do_ exist real security concerns, though > they're not the same as incompetent admins think. My point is this: there are two general strategies for dealing with security considerations vis-a-vis new technology that has to cross administrative boundaries. The first strategy is to try to anticipate and a priori build for the security concerns of the admins by giving them all the "knobs" (controllable security features) they think they want and need. From bitter experience, this strategy is a loser; even if you give them every knob you think or they claim they want, that still means they have to buy into *actually* twiddling those knobs in order for your technology to proliferate. And they just won't buy into installing and twiddling new knobs, most of the time. Running a new protocol on a new port is an example of giving them a trivial knob that they'll refuse to twiddle. The second strategy is to subvert the existing security infrastructure in such a way that only onerous administrative security measures can prevent short-term proliferation of your technology. (Ab)using HTTP is the preferred way to do this; they can't shut down all Web access, so they have to block specific hosts. Often this is more trouble than its worth. The more decentralized your system, the better off you are; if they can't shut down particular hosts, then their filtering apparatus has to gain explicit knowledge of your application in order to block it. The mechanism I'm proposing is really the second, but with some sugar thrown in for the competent admin. Tunneling HTTP through HTTP allows security vendors to *eventually* incrementally modify their intermediary products to filter traffic at an application semantic level; the change is incremental because, after all, it's just HTTP. However, it's going to take time for them to develop and deploy that on an application by application basis. Hence the admin function can't adversely impact the network effects that drive rapid takeoff and proliferation of any given new application. jb
> How, in general, does one get from a resource to its subordinate > resources? Assertions. They can take several forms; - query forms - via HTTP headers (e.g. Location on a 201 response) - other assertions - documents that authoritatively declare resource relationships, of which "subordinate" is one type of relationship, such as through a GET > Must the resource use an entity body in a structured format > with HREFs? No. > Is there no "standard" way? If not, why not? Different types of assertions happen in different contexts with different syntaxes. > What is the relationship (if any) behind the hierarchy expressed through > "/", "." and ".." and the subordinate resource hierarchy? "." and ".." only has special meaning when used in a relative URI. "/" can be used for exposing subordinates, but that decision can only be made by the publisher. A third party seeing a /foo/bar URI can't assume that bar is a subordinate of foo. But it's good practice for a publisher to use this structure as a canonical URI when it might be important for the container to be used as a base URI. (that was a sneak peek from my opacity study) > I think that > there is no explicit relationship. Why do we need two hierarchies? What two? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Fri, 25 Jan 2002, S. Mike Dierken wrote: > If you do a POST to do a DELETE, firewalling/caching don't work so good. Can you explain this one? Once you're changing state, you're changing state.... -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 25 Jan 2002, Paul Prescod wrote: > "AsyncOS is optimized for > asynchronous tasks like Internet > Messaging. AsyncOS includes a unique > new file system, an I/O-driven scheduler, > and a revolutionary new threading model." > > What's an "asynchronous task?" One where the server doesn't send back an > answer until later? How would you optimize an operating system for such > a task? Get rid of preemptive threads. Do explicit yields. See: http://www.nightmare.com/~rushing/copython/index.html and http://www.nightmare.com/medusa/medusa.html -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > Get rid of preemptive threads. Do explicit > yields. See: > http://www.nightmare.com/~rushing/copython/index.html > and > http://www.nightmare.com/medusa/medusa.html Python 2.2 adds explicit support for generators with the introduction of the yield statement. [1] A generator looks like and is similar to a function, with some important differences; it is similar in many ways to the concept of a monad from functional languages. They are sort of anti-idempotent: a generator reifies a potentially infinite stream as a function upon which sucessive calls which yield sucessive values from the stream. This is a great language-level feature that makes modeling and using infinite streams much, much easier. The same kind of thing can be achieved with explicit continuations / coroutines, but IMO generators are much simpler and more intuitive. They're also a good step towards unifying a number of related concepts, namely functions, streams, and objects. $0.02, jb [1] http://python.sourceforge.net/peps/pep-0255.html
> As strongly as you feel about this principle of the client not revealing > anything to the server, It's not how I "feel", it's the bedrock of security design. Information leaks are the source of exploits, period. > I feel that a real end-user client should not be > running software that accepts TCP connections from unknown parties. So I > feel that tunnelling is not only inevitable but a Good Thing. And I > think that Joe Firewall is more in line with my view than yours. Uh, we might have a disagreement if you had a point to disagree with. Let's hear it, shorty.
> One way to address security is to differentiate between "ordinary"
> callbacks and "secure" callbacks. Ordinary callbacks are like SMTP. No
> more or less secure. No paranoia.
>
> "Secure" callbacks are created ONLY on a persistent connection created
> from the client to the server, potentially using SSL.
>
> Let's face it, that's corporate America's definition of secure
> behind-the-firewall software. Outgoing is secure. Incoming is insecure.
> So secure callbacks would work just like MSN messenger or ICQ or
> Napster, you turn the thing on, it "calls home" and opens a connection.
Non-secure callbacks via a full HTTP server would quickly lead to a parade of
serious vulnerabilities. If you feel that it wouldn't have to be a full HTTP
server, then you are agreeing with my main point.
SSL callbacks would add complexity, expose the server, increase ability to DoS,
increase the number of possible holes. It completely fails to solve the
problem.
> Insofar as the client knows what server it has contacted, the security
> requirements are much lower.
> After all, Web browsers have historically
> been terribly insecure but the practical damage caused by them is low
> because the end-user controls what sites he/she contacts. So
> accountability is pretty good ("here's the URL of the site that deleted
> my hard drive") and it is really hard to get a million users to come to
> your site and download your virus.
I can see that you didn't put time into understanding what I wrote, because that
is 90% of my point. The PSP algorithms piggybacks notification security on the
existing security of HTTP client requests.
> The care and thought put into your PSP won't mean squat to a corporate
> sysadmin. And on reflection I do think that practically speaking,
> unidirectional connections provide more safety than paranoid protocol
> implementations. And anyhow, it is pretty easy to set up a single
> unidirectional connection to your "event server" on the Web and let it
> handle the security crap for you.
Sorry, you need to explain what you mean by unidirectional. You mean that a
client which wishes to receive events must connect to a presence server a la
KnowNow? That is a non-starter. No chance. The resources are right there on
the client. You mean that if the accounting web server wants to send an event
to Joe the Accountant in the next cube they have to rendezvous at the KN router
in California?
Lucas Gonze wrote: > Sorry, you need to explain what you mean by unidirectional. You mean that a > client which wishes to receive events must connect to a presence server a la > KnowNow? That is a non-starter. No chance. The resources are right there on > the client. You mean that if the accounting web server wants to send an event > to Joe the Accountant in the next cube they have to rendezvous at the KN router > in California? I cannot stress to you strongly enough that any *other* approach --- such as getting administrators to explicitly configure a firewall to allow your new PSP callback protocol through --- is an absolute non-starter. This isn't speculation, this is hard-won experience. We tried it. It did not work. We beat our heads against this at Activerse for a *long* time. Unfortunately, protocol evolution effectively ended with HTTP, and indeed the whole notion of the TCP service <--> port address space is effectively on the way out. Today we have to deal with a single protocol on a single port and we have to deal with asymmetrical connectivity as a result of firewalls. Fortunately, that's okay, because we can (a) build any application we want using HTTP, and (b) address asymmetry though principled and compatible extensions of the REST architecture that simply build on what we've already got. If you want to pursue some other course, feel free to. You may get some uptake in situations where you don't have to deal with firewalls, but in the enterprise you will gain no traction whatsoever if you require the network admins to touch their existing firewall configurations. Ultimately, you're going to have to burrow out through port 80 to something that is effectively a rendezvous server. Having been down the losing path once before, I'm in favor of just skipping that frustrating and fruitless exploration this time around and just figuring out how to tunnel while preserving the end-to-end semantics of HTTP 1.1. jb
Mark Baker wrote: > But it's good practice for > a publisher to use this structure as a canonical URI when it might be > important for the container to be used as a base URI. (that was a > sneak peek from my opacity study) Mark, does your study provide a normative set of conventions that inform the problem of resource modeling? IME, it seems that half the job is naming things, and I've sort of been picking at a kind of grammatical approach to building URI that in turn seems to lead to good resource models. My own work on this isn't very mature at this point, but it would be great if such a set of guidelines existed. :-) When can we see your opus? jb
> I cannot stress to you strongly enough that any *other* approach --- > such as getting > administrators to explicitly configure a firewall to allow your new > PSP callback > protocol through --- is an absolute non-starter. I am not suggesting that approach. Far from it. I have said *nothing* of the kind. And I wish you would work through the implications correctly before attacking implications I have not made. All existing ideas on how to do callbacks have centered on a callback URI. There's a source that has an event to post, to make that happen it sends some bytes to the sink callback URI; the sink is running a server on the callback IP:port. This is exactly the same in PSP as in full scale HTTP 1.1. In fact, neither can pass through the firewall. Firewalls are a completely separate conversation. PSP is merely and only a means of implementing callbacks without introducing new security problems. (Uh, actually there's one tiny difference between UDP and TCP servers for the purposes of breaking into the firewall -- UDP can sometimes pass through NATs. That's a trivial difference that isn't consistently enough available to care about, which is why I didn't mention it.)
And as a general point, I'd appreciate a more collegial atmosphere. It's not a shooting gallery. I'm not selling insurance. I spent a couple days analyzing a big problem created by the standard model (the problem being that using callbacks to post event notifications opens large security holes) and proposed a simple solution. It does no good to say that large security problems don't matter -- they do -- or to snipe at implications like reverse firewall traversal which (1) are based on incorrect understanding and (2) I didn't make.
Lucas Gonze wrote: > I am not suggesting that approach. Far from it. I have said *nothing* of the > kind. And I wish you would work through the implications correctly before > attacking implications I have not made. I have --- I'm not sure you've thought through the implications. ;-) What port is PSP going to run on? How is an event source going to communicate with the callback sink? What happens if the sink is on the other side of the firewall? > All existing ideas on how to do callbacks have centered on a callback URI. > There's a source that has an event to post, to make that happen it sends some > bytes to the sink callback URI; the sink is running a server on the callback > IP:port. This is exactly the same in PSP as in full scale HTTP 1.1. In fact, > neither can pass through the firewall. This is absolutely true. > Firewalls are a completely separate conversation. PSP is merely and only a > means of implementing callbacks without introducing new security problems. I think it solves a non-problem. The only justification for PSP as a separate protocol from HTTP is to put it on another port where it can be separated from and processed independently of HTTP for the purpose of securing administrative boundaries. If not that purpose, there's no point in introducing a separate protocol. > (Uh, actually there's one tiny difference between UDP and TCP servers for the > purposes of breaking into the firewall -- UDP can sometimes pass through NATs. > That's a trivial difference that isn't consistently enough available to care > about, which is why I didn't mention it.) Activerse's event protocol was UDP-based. This was problematic. jb
Lucas Gonze wrote: > And as a general point, I'd appreciate a more collegial atmosphere. It's not a > shooting gallery. I'm not selling insurance. I'm not sure. Think about it. ;-) > I spent a couple days analyzing a > big problem created by the standard model (the problem being that using > callbacks to post event notifications opens large security holes) and proposed a > simple solution. It does no good to say that large security problems don't > matter -- they do -- or to snipe at implications like reverse firewall traversal > which (1) are based on incorrect understanding and (2) I didn't make. Hey, man, we're on the same side. I'm just trying to let you know that the logical conclusion of the path you're currently exploring is a dead-end --- seriously, I'm just trying to save you some frustration. You've thought about these issues for what, a few days? I spent about three years struggling through *specifically* all of this, several years ago, and it seriously cost me some hair. I'm not sniping at implications like reverse firewall traversal --- I'm pointing out a *fundamental problem* with the introduction of any new protocol on any new port that is intended to touch edge machines. It doesn't make sense to run HTTP 0.9 / PSP on port 80, of course, therefore the implication in your PSP suggestion is that you are introducing a new protocol on a new port. That ain't gonna work, bro. :-) Trust me on this one. Regardless of which port it runs on, you've expressed an interest in allowing clients to receive notifications. This *implies* that whatever solution you have needs to cross firewalls. Since PSP doesn't run on port 80, this means you assume you're going to go out and convince all the network admins of the world to open up your PSP port to allow for inbound traffic on your innocuous protocol. Even if it did run on port 80, you've still got to convince them to allow inbound to all your edge machines. Well, that just isn't going to happen. You're designing a solution that cannot be deployed in the environment into which it needs to be deployed. I'm on your side, but I don't think *you've* thought through the practical implications of what you're proposing. It may be a nice, elegant solution to a problem, but an elegant solution that can't be deployed isn't very useful. And it may not be the only or most elegant solution. $0.02, and peace, jb
Lucas' analysis of the security problems with callbacks rests on a fundamental assumption that I think might be flawed. In order to illustrate this, we have to ask: what is a notification? Lucas assumes that a notification is a delayed, asynchronous response to a particular HTTP request. Hence, a sink must expose only as much state to the source as a client would ordinarily expose to a server. That's fine, *iff* you accept that notifications are the continuation of the original request. When we consider notifications this way, what we're doing is fundamentally introducing asynchrony *into* the HTTP request-response cycle. This certainly doesn't seem to be very RESTful, IMHO. (Neither does introducing asymmetric protocols for generating a request and receiving a later response.) That's not the only way to think about asynchrony, though. A more HTTP-friendly way to think about asynchrony is to consider the initial subscription request / response cycle to be related to the establishment of a subscription. That is, it is a request in itself, an entirely valid one which talks about the subscription being established. The response is related to the subscription abstraction as well. Later notifications --- requests to the sink --- are not conceptually the continuation of the original request, but rather subsequent data-providing requests. They are related to but semantically (mostly) independent of the request-response cycle that established the subscription. They do pose a greater security risk than a single, simple client-server request-response cycle. But that's a necessary risk that we have to accept and manage if we are to allow edge machines to publish resources. Any solution, including an asymmetric response protocol, introduces new risks that must be managed. IMO, the latter is the appropriate approach --- asynchrony and the notification abstraction live at the level of abstraction of resources; it's about resources communicating with each other. Resources can communicate asynchronously, without changing the synchronous semantics of HTTP. We can leave that alone, and still build asynchronous communication patterns between resources on top of it. Just a bit more musing on the topic, ciao... jb
Yup. That's why they are using python where they can (and tuning the OS to support). -Alex- On Sun, 27 Jan 2002, Jeff Bone wrote: > > > > "S. Alexander Jacobson" wrote: > > > Get rid of preemptive threads. Do explicit > > yields. See: > > http://www.nightmare.com/~rushing/copython/index.html > > and > > http://www.nightmare.com/medusa/medusa.html > > Python 2.2 adds explicit support for generators with the introduction of the > yield statement. [1] A generator looks like and is similar to a function, > with some important differences; it is similar in many ways to the concept of > a monad from functional languages. They are sort of anti-idempotent: a > generator reifies a potentially infinite stream as a function upon which > sucessive calls which yield sucessive values from the stream. This is a great > language-level feature that makes modeling and using infinite streams much, > much easier. The same kind of thing can be achieved with explicit > continuations / coroutines, but IMO generators are much simpler and more > intuitive. They're also a good step towards unifying a number of related > concepts, namely functions, streams, and objects. > > $0.02, > > jb > > [1] http://python.sourceforge.net/peps/pep-0255.html > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > What's an "asynchronous task?" One where the server doesn't send back an > > answer until later? How would you optimize an operating system for such > > a task? > > Get rid of preemptive threads. Do explicit > yields. See: > http://www.nightmare.com/~rushing/copython/index.html > and > http://www.nightmare.com/medusa/medusa.html So how is this optimization specific to "asynchronous messaging" and not equally applicable to standard web serving (for example). Paul Prescod
On Sun, 27 Jan 2002, Paul Prescod wrote: > So how is this optimization specific to "asynchronous messaging" and not > equally applicable to standard web serving (for example). It may be... e.g the Medusa httpd. However, they are developing mail servers. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Lucas Gonze wrote: > > ... > > Non-secure callbacks via a full HTTP server would quickly lead to a parade of > serious vulnerabilities. I dispute this for two reasons. First, there is no requirement for a full HTTP server. So even if your statement is literally true, I don't think it is applicable. An event handerl only has to accept POSTs to pre-ordained URIs in a pre-ordained format with simple, pre-ordained semantics. They won't generally be running CGIs which is where most HTTP server exploits come from. Second, any piece of software that contains an HTTP client without security flaws can easily contain a mini-HTTP server component with the same characteristic. Most of the code is the same....parsing MIME headers, parsing MIME bodies etc. Most of the vulnerabilities are the same. I don't see how moving the body retrieval to the GET makes much difference. Yes a little, the code for GET may already exist and be tested. But most of it is the same. What vulnerabilities do I see? * Callback scanning is worth considering The "port space" is relatively small. But to find an HTTP server hiding out on a particular URI you need the IP address, the port number, *and* the correct URI, which could have a long secret code in it. So I would say that we could change the spec to allow the HTTP server to ignore requests to non-existent URIs to make hiding out easier. This will make it practically impossible to use a brute-force scanning technique to find a callback. You'll have to search every possible URI on every port on each IP address. * Spoofing and man-in-the-middle is another thing worth consideing. I think that only crypto can prevent this. But there is a price for crypto so it should be optional. This can be done either in the application layer (signing payloads) or the socket layer (SSL). Unless we can agree on the security problem we're trying to solve, I don't think we'll see eye to eye on the solution. So I'll leave it there before getting back into the details of your proposed solution. If you see the vulnerabilities above differently than I do, or want to list others, please do. One more issue: >... > Sorry, you need to explain what you mean by unidirectional. You mean that a > client which wishes to receive events must connect to a presence server a la > KnowNow? That is a non-starter. No chance. The resources are right there on > the client. You mean that if the accounting web server wants to send an event > to Joe the Accountant in the next cube they have to rendezvous at the KN router > in California? Well if they are within a zone of trust, then they might accept connections from each other directly. And if they were on opposite side of one or more firewalls then yes, they would probably each contact a rendezvous machine. That's how IRC works. And how MSN, POP, and netnews. All of these require an intermediary. But unlike IRC or MSN or POP, we will preserve the ability for end-user nodes to connect directly if the hosts trust each other. Paul Prescod
If we are talking about a protocol with no reply defined except OK, isn't that email/SMTP? In which case the obvious solution is just to define a notification mime-type and add a notification handler to your mailcap file. The protocol would be SMTP to some mail server and perhaps POP to the client. The HTTP version looks like this: 1. notifier POSTs email/notification to "mail server" 2. "mail server" replies with 202 Accepted 3. client picks up mail from mail server using GET 4. client processes mail and may initiate new HTTP connections I don't know how you replace the functionality of MX records.... -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Ok. You claim Plan9 modelled everything as files. Since namespaces are private. One could equally claim that Plan9 modelled everything as messages to and from file/device owners. It doesn't sound like a file system. It sounds more like a message system in which the primitives were: * send (aka write) * recieve/check for messages (aka read) The big thing that I don't like about most file APIs is that they are synchronous stopping your process while hardware catches up. It is semantically more elegant to represent all IO using asynch interfaces. It sounds like Plan9 effectively achieved asynchrony because device owners accepted messages from client processes and then handled those messages in a separate process/thread. The clients could then asynchronously check for messages by reading the file. Very nice. But I don't see why this is not the same as sending email to some address and then checking for email from that address. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax On Sat, 26 Jan 2002, Jeff Bone wrote: > The point of the Plan 9 anecdote is that it stands as an existance proof > invalidating your claim that parameter passing to a procedure cannot be modeled as > file IO. Certainly almost anything --- and maybe *anything* --- that can be modeled > as parameter passing to a procedure can be modeled as generic stream IO on a file / > resource. > > Plan 9 an example of making various things --- including active "data producing > processes" --- look like files. The original idea of UNIX, broken by the > introduction of sockets, was to make everything look like a file. Plan 9 was an > attempt by most of the original authors of UNIX to go back and push that concept to > the limit, unifying everything as resources (files) in a single namespace sharing a > single generic stream IO interface. > > I bring it up because it's a great example of how to do the *kind* of thing we're > talking about here, albeit in a different namespace with a different generic > interface. It's a *great* case study, though; I didn't really "get" REST until I > started thinking about how things are modeled in Plan 9 as an analogy. (Side note: > in a private e-mail with Roy Fielding around the time I had my REST gestalt, I > pointed out the Plan9 analogy; he claimed that he'd wished he'd been more familiar > with / had some citations for it a while back --- he apparently agreed with me and > thought the analogy useful and appropriate.) > > > but I am curious how resource synchornization > > works. What happens when two apps try to > > write/read the /net/cs file? Is it locked? > > In Plan 9, every process has a private view of the namespace. For example: 8 1/2, > the Plan 9 window system, represents the mouse as /dev/mouse, IIRC. 8 1/2 itself > handles synchronization and acts as the multiplexer / demultiplexer for events > generated by this device; each process sees its own private version of /dev/mouse; > a process which opens and reads this file will read a stream of only those events > generated in the window in which the process is running. In other words, mux and > sync are generally handled in Plan 9 by whatever "server" presents a given service > as a resource, in whatever manner is appropriate for that service. > > $0.02, > > jb > >
On Sat, 26 Jan 2002, Jeff Bone wrote: > > I don't understand why SMTP doesn't do what you > > want. > > This is a *very simple* point. Listen closely. It doesn't do what we want it to so > because it doesn't present as resources that can be interacted with via the generic HTTP > interface. What are your thoughts on 202 Accepted? Was it a mistake? > > My answer was show me > > an application that you can't do with SMTP. > > And we did this: the Web. You can implement the web with email autoreplies. e.g. href="mailto:pageserver@...?subject=/my/page" -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > Ok. You claim Plan9 modelled everything as files. It did. Check it out. :-) > The big thing that I don't like about most file > APIs is that they are synchronous stopping your > process while hardware catches up. It is > semantically more elegant to represent all > IO using asynch interfaces. Hey, you aren't arguing with me, you're arguing with Dennis Ritchie, Dave Presotta, Rob Pike, Ken Trickey, etc. If you feel up to that, that's your call. > Very nice. But I don't see why this is not the > same as sending email to some address and then > checking for email from that address. I know, I know. Mark and the rest of us have a universal hammer called HTTP, and everything is a nail. You've got a universal hammer called SMTP, and everything is an e-mail. jb
"S. Alexander Jacobson" wrote: > You can implement the web with email autoreplies. > e.g. > href="mailto:pageserver@...?subject=/my/page" I'm actually willing to concede this point; in fact I should've before. The only thing we're proving here is that synchronous communication can be built on top of an asynch substrate and vice versa. This isn't news; check out the raging debates about the generality of the message-passing paradigm circa 1987-1988. Message passing, procedure calling, and dataflow techniques are all Turing complete. Your argument fundamentally rests on the assumption --- your own words --- that it is "semantically more elegant to represent all IO using asynch interfaces." I can't argue with that, it's an aesthetic argument. What I *can* point out is that the Web hosts a greater variety of applications (though less users and probably less messages) than SMTP. jb
"S. Alexander Jacobson" wrote: > It doesn't sound like a file system. ...trust me, it's more like a file system than any file system you've ever seen. > It sounds like Plan9 BTW, instead of just guessing at what it did, and how, and why that might be important, why not go check it out? Various papers can be had at [1]. IMHO, anybody in the business of building distributed systems --- and maybe software in general --- that hasn't read these papers is doing themselves a disservice. Lots of lessons, there. It's *absolutely incredible* how much functionality is packed into such few and simple abstractions and such little code: the entire operating system with all bells and whistles is an order of magnitude smaller than the current X distribution. Special attention is warranted for [2], [3], [4], [5], and [6]. Anybody doing distributed filesystem work specifically or protocol design in general should take a detailed look at the man pages for 9P, the Plan 9 network "file" protocol. [7] Ciao, and happy hunting. jb [1] http://www.cs.bell-labs.com/sys/doc/ [2] http://www.cs.bell-labs.com/sys/doc/9.html [3] http://www.cs.bell-labs.com/sys/doc/names.html [4] http://www.cs.bell-labs.com/sys/doc/net/net.html [5] http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.html [6] http://www.cs.bell-labs.com/sys/doc/plumb.html [7] http://www.cs.bell-labs.com/sys/man/5/INDEX.html
On Mon, 28 Jan 2002, Jeff Bone wrote: > > Ok. You claim Plan9 modelled everything as files. > > It did. Check it out. :-) I know. I did. I just think calling it a "file" interface is a misnomer. One could also argue that it is closer to Linda... > > The big thing that I don't like about most file > > APIs is that they are synchronous stopping your > > process while hardware catches up. It is > > semantically more elegant to represent all > > IO using asynch interfaces. > > Hey, you aren't arguing with me, you're arguing with Dennis Ritchie, Dave Presotta, Rob > Pike, Ken Trickey, etc. If you feel up to that, that's your call. I'm not actually arguing with what they did at the time. I asked Reiser about this issue and he largely agreed, but said it was too late to change. Callbacks allow the OS better to optimize writes and do interesting caching. Think about all the annoying issues with applications that expect a local filesystem and run into issues because NFS is much less reliable. See Gosling on network transparency. Also see the design of O'Haskell http://www.google.com/search?hl=en&q=ohaskell -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Mon, 28 Jan 2002, Jeff Bone wrote: > Your argument fundamentally rests on the assumption --- your own words --- that it is > "semantically more elegant to represent all IO using asynch interfaces." I can't argue with > that, it's an aesthetic argument. What I *can* point out is that the Web hosts a greater > variety of applications (though less users and probably less messages) than SMTP. Gosling's homepage points to good reasons why asynch interfaces are better: http://java.sun.com/people/jag/Fallacies.html What happens with HTTP when you can't reach the server? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > If we are talking about a protocol with no reply > defined except OK, isn't that email/SMTP? Lucas wants no reply. Period. > In which case the obvious solution is just > to define a notification mime-type and add a > notification handler to your mailcap file. > The protocol would be SMTP to some mail server and > perhaps POP to the client. POP is pull. We're trying to do asynch notifications. Paul Prescod
"S. Alexander Jacobson" wrote: > Think about all the annoying issues with > applications that expect a local filesystem and > run into issues because NFS is much less reliable. That's an issue with NFS. > See Gosling on network transparency. > Also see the design of O'Haskell > http://www.google.com/search?hl=en&q=ohaskell Cf. Waldo: http://research.sun.com/techrep/1994/abstract-29.html jb
"S. Alexander Jacobson" wrote: > What happens with HTTP when you can't reach the > server? What happens when SMTP can't deliver the message? Alex, I'm done with this conversation. We're arguing over whether chocolate is better than vanilla, over whether Mighty Mouse can beat up Superman. There's no margin in it. jb
On Mon, 28 Jan 2002, Jeff Bone wrote: > "S. Alexander Jacobson" wrote: > > What happens with HTTP when you can't reach the > > server? > What happens when SMTP can't deliver the message? It keeps trying. There is a whole section in the RFC on Retry. HTTP does not define a retry policy. > Alex, I'm done with this conversation. We're arguing over whether chocolate is better than > vanilla, over whether Mighty Mouse can beat up Superman. There's no margin in it. I'm not so sure. I bought into the zen of loose coupling in REST. I am hoping you will see the bonus in asynch. I think the two are very complimentary. But whatever, I'll drop it if you want. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Jeff Bone wrote: > > "S. Alexander Jacobson" wrote: > > > You can implement the web with email autoreplies. > > e.g. > > href="mailto:pageserver@...?subject=/my/page" > > I'm actually willing to concede this point; in fact I should've before. The only thing we're > proving here is that synchronous communication can be built on top of an asynch substrate and > vice versa. In theory you could build the Web on SMTP. But you would have to implement and deploy SMTP in a radically different way. You would need a way to give messages priority so that results could seem interactive. You would also need to extend SMTP to the desktop to eliminate unncessary remote intermediaries. And of course you would need to layer all of HTTP's semantics on top of SMTP. Paul Prescod
On Mon, 28 Jan 2002, Paul Prescod wrote: > "S. Alexander Jacobson" wrote: > > > > If we are talking about a protocol with no reply > > defined except OK, isn't that email/SMTP? > > Lucas wants no reply. Period. > > > In which case the obvious solution is just > > to define a notification mime-type and add a > > notification handler to your mailcap file. > > The protocol would be SMTP to some mail server and > > perhaps POP to the client. > > POP is pull. We're trying to do asynch notifications. Understood. Jeff's generbending spec and the solution I prosposed at the bottom of my prior email try to reach a compromise. The gist of the compromise is to use HTTP to deliver asynch to a message server. This message server can be secured as much as lucas wants. (Or we can reuse the existing mail server). If the app lives on the mailserver then the notification is handled immediately. If the app lives on a client behind the firewall, then it maintains either a persistent GET or a POP connection to the mailserver and recieves messages when they arrive. (Yes, I know POP is polling, but that is irrelevant in this discussion -- actually it is an argument if favor of persistent GET -- thanks Jeff!). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > Gosling's homepage points to good reasons why > asynch interfaces are better: > http://java.sun.com/people/jag/Fallacies.html He says nothing about asynch. > What happens with HTTP when you can't reach the > server? SMTP is fundamentally synchronous. The client connects to the server. They do some TCP negotiations and then some SMTP negotiations. When they are both happy they quit. I would be more impressed if you compared HTTP to UDP. Paul Prescod
On Mon, 28 Jan 2002, Paul Prescod wrote: > In theory you could build the Web on SMTP. But you would have to > implement and deploy SMTP in a radically different way. You would need a > way to give messages priority so that results could seem interactive. Not a problem mailserver to mailserver. > You would also need to extend SMTP to the desktop to eliminate > unncessary remote intermediaries. That is why I like the idea of using persistent GET on the last hop instead of POP.... However, you could also just use a more pipelined smtp relay implementation to get the appropriate speed. > And of course you would need to layer > all of HTTP's semantics on top of SMTP. Not clear, but I don't need to argue this. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > > > POP is pull. We're trying to do asynch notifications. > >... > The gist of the compromise is to use HTTP to > deliver asynch to a message server. This message > server can be secured as much as lucas wants. > (Or we can reuse the existing mail server). As usual, I don't see what SMTP brings to the table. It doesn't satisfy Lucas' extreme requirements and it doesn't simplify anything. > ... > If the app lives on a client behind the firewall, > then it maintains either a persistent GET or a POP > connection to the mailserver and recieves messages > when they arrive. What does POP supply that HTTP wouldn't? Just a gateway to legacy clients? Paul Prescod
On Mon, 28 Jan 2002, Paul Prescod wrote: > > Gosling's homepage points to good reasons why > > asynch interfaces are better: > > http://java.sun.com/people/jag/Fallacies.html > > He says nothing about asynch. It was waldo, not Gosling. (thanks Jeff again) Also see the Peter Deutch page at the URL above. The point is that synchronous implementations need to block for indeterminate amounts of time to handle network problems. This leads to bad application behavior (think about how the old browsers used to lock up while doing DNS lookup) > > What happens with HTTP when you can't reach the > > server? > > SMTP is fundamentally synchronous. The client connects to the server. > They do some TCP negotiations and then some SMTP negotiations. When they > are both happy they quit. I would be more impressed if you compared HTTP > to UDP. No SMTP is fundametally asynchronous. Applications hand of messages to an SMTP MTA (message transfer agent). The MTA then deals with delivery on its own time and delivers messages back to applications when they arrive. The TCP/UDP issue is orthogonal (about delivery errors -- even on fast connections). -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > The gist of the compromise is to use HTTP to > > deliver asynch to a message server. This message > > server can be secured as much as lucas wants. > > (Or we can reuse the existing mail server). > > As usual, I don't see what SMTP brings to the table. It doesn't satisfy > Lucas' extreme requirements and it doesn't simplify anything. People already maintain secured mail servers. Mail gets past the firewall. Mail looks a lot like Lucas' protocol. > > ... > > If the app lives on a client behind the firewall, > > then it maintains either a persistent GET or a POP > > connection to the mailserver and recieves messages > > when they arrive. > > What does POP supply that HTTP wouldn't? Just a gateway to legacy > clients? As I said, I like the persistent GET better than POP (lower latency and no-polling). I am just making an architectural observation. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > The point is that synchronous implementations need There is a big difference of synchronous implementations and implementations of synchronous protocols. http://www.nightmare.com/medusa/ >... > No SMTP is fundametally asynchronous. > Applications hand of messages to an SMTP MTA > (message transfer agent). That is application architecture. The protocol itself is synchronous. The client can't hang up until the server says OK. As we've discussed at length, you can build a similar application architecture for HTTP easily. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > People already maintain secured mail servers. One of my points to Lucas was that people also already maintain secured HTTP servers. > Mail gets past the firewall. HTTP traffic gets past the firewall (or at least to it). > Mail looks a lot like Lucas' protocol. Not really. ;) And anyhow, his protocol was meant to be used to end-nodes, not to the intermediaries. Paul Prescod
"S. Alexander Jacobson" wrote: > > What happens when SMTP can't deliver the message? > > It keeps trying. Forever? I think not. > There is a whole section in the > RFC on Retry. HTTP does not define a retry > policy. It *doesn't have to.* And btw, RFC821 *does not contain the word "retry" **AT ALL.*** RFC1869, the service extensions, doesn't either. Get your facts straight. > I'm not so sure. I bought into the zen of loose > coupling in REST. I am hoping you will see the > bonus in asynch. I think the two are very > complimentary. Dude! You don't have to sell me on asynch, I'm totally sold --- over five years ago I was trying to explain to everybody that would listen that global-scale event notifications were indeed the next big thing. That was the WHOLE PREMISE behind my last company, Activerse! (Lesson learned: sell applications, not infrastructure.) What you're failing to sell me on is the idea that HTTP applications don't need to communicate asynchronously (in-the-large, i.e. in a macro sense) over HTTP. jb
Paul Prescod wrote: > In theory you could build the Web on SMTP. It can be done. In fact, it *has* been done --- Pierre Omidyar, who went on to found EBay, had a sort of midnight project called "WebMail" that delivered requested Web pages to General Magic handhelds via e-mail. This was contemporary and somewhat competitive with Active Paper's true SMTP / POP e-mail and browser clients that ran on those devices, and it took some convincing to get him to shut it down. ;-) As you point out, the fact that it *can* be done doesn't mean that it's desirable. :-) jb
"S. Alexander Jacobson" wrote: > Gosling's homepage points to good reasons why > asynch interfaces are better: > http://java.sun.com/people/jag/Fallacies.html BTW, while this is Gosling's page, these are Peter Deutsch's utterings. These have been around for a *long* time. I don't know if it was precisely these 8 fallacies, but he's (Peter's) been talking about this stuff at least since the time when I was at Sun, over a decade ago. Let me add a big lesson that most people fail to take away from those fallacies: * Disconnection is the edge case of latency At some fundamental level, almost all distributed applications assume that two parties in an interaction are going to be online at the same time; this is a safe assumption only for applications where it's acceptable for the interaction to not occur at all if this doesn't happen. We pretend that most applications are like that, but indeed many applications would be more useful if this wasn't the case, if I could *eventually* get the results I want regardless of the connected status of the participants at any given time. As our world becomes more mobile, people and devices become disconnected more frequently. Despite the drive to ubiquitous connectivity, it's safe to assume that the extreme edges of the network will *always* be much lower bandwidth and much higher latency than the central parts, with the extreme case approaching 0 and infinity respectively. It's a shame that more people don't build distributed systems that recognize this fact, degrade gracefully as bandwidth drops and latency increases, and allow participants to continue when disconnected with a guarantee of eventual consistency upon reconnection. (This is particularly a beef of mine with most distributed filesystems.) This distinction from typical distributed systems is so important that back in the early 90s I started calling such systems "dispersed systems" or "dispersed computing." That's one piece of bonejargon that never really took; hey, even Babe Ruth never batted 1000. ;-) There are some Google hits, but they're rather semantically unrelated. ---- This need for looser coupling in time and with respect to instantaneous connectivity would seem to argue for asynchrony in a very strong sense --- and it does. Alex will interpret this to mean that SMTP is better or more powerful in some sense than HTTP --- but he's wrong. ;-) SMTP is a *synchronous* protocol, just like HTTP. The asynchronous, store-and-forward behavior of SMTP arises at the architectural and application level. Each transmission of a message between one party and another results from a TCP connection between the parties over which a synchronous protocol is run to pass the message in question (request) and get back a response. It's even more synchronous than HTTP in many ways; a single message requires a stateful series of synchronous command-response interactions. Certainly more chatty, more stateful, more difficult to implement, more bletcherous on many levels. SMTP's asynchrony --- and that's not even really the right word, at an application level it's unidirectional in the success case --- arises as application-level semantics from a series of synchronous interactions between entities that are tightly coupled in time. There's no reason whatsoever why SMTP as a protocol is better than HTTP as a protocol for this purpose; the primary advantage is that SMTP servers already understand routing and store-and-forward and have infrastructure in place to support this. ---- More musings... jb
----- Original Message ----- From: "Paul Prescod" <paul@...> > How, in general, does one get from a resource to its subordinate > resources? Must the resource use an entity body in a structured format > with HREFs? Is there no "standard" way? If not, why not? I believe that is the Way of ReST. The relationship is declarative rather than algorithmic. Highly flexible but requires constant interpretation (of entity bodies). This is similar to the earlier notification approach of using the response header of Subscription: to identify the URI of the subscription resource rather than algorithmically/assume to know where it is. > > What is the relationship (if any) behind the hierarchy expressed through > "/", "." and ".." and the subordinate resource hierarchy? I think that > there is no explicit relationship. Why do we need two hierarchies? > (Do you mean 'no implicit relationship'?) Applications can coordinate on a shared understanding of what '..' and '/' mean, but it isn't transferable in general. It is very powerful, but also very easy to unconciously attempt to bypass - we are used to knowing how to communicate with our own servers. I find it difficult to avoid using .. and / to programmatically navigate my application model. Using a response entity with explicit locations is a somewhat new tool for me - using response headers is even 'more newer'.
On Mon, 28 Jan 2002, Paul Prescod wrote: > > No SMTP is fundametally asynchronous. > > Applications hand of messages to an SMTP MTA > > (message transfer agent). > > That is application architecture. The protocol itself is synchronous. > The client can't hang up until the server says OK. As we've discussed at > length, you can build a similar application architecture for HTTP > easily. You need a retry protocol. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul, I think we are having a miscommunication. I am not advocating SMTP/POP here. I am suggesting HTTP replacements for the SMTP/POP architecture with which people are already comfortable. In particular HTTP notification to the secured "mail server" (the mail server is actually an HTTP server handling notifation relay), and then persistent GET between the clients behind the firewall and the relay server. -Alex- On Mon, 28 Jan 2002, Paul Prescod wrote: > "S. Alexander Jacobson" wrote: > > > >... > > > > People already maintain secured mail servers. > > One of my points to Lucas was that people also already maintain secured > HTTP servers. > > > Mail gets past the firewall. > > HTTP traffic gets past the firewall (or at least to it). > > > Mail looks a lot like Lucas' protocol. > > Not really. ;) And anyhow, his protocol was meant to be used to > end-nodes, not to the intermediaries. > > Paul Prescod > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Mon, 28 Jan 2002, Jeff Bone wrote: > > > What happens when SMTP can't deliver the message? > > > > It keeps trying. > > Forever? I think not. It would help if you read the section in the RFC on retries. Obviously delivery CAN fail in either protocol. The difference is tolerance for transient network outages. > > There is a whole section in the > > RFC on Retry. HTTP does not define a retry > > policy. > > It *doesn't have to.* And btw, RFC821 *does not contain the word "retry" **AT ALL.*** RFC1869, > the service extensions, doesn't either. Get your facts straight. Uhm. The current RFC is 2821. > > I'm not so sure. I bought into the zen of loose > > coupling in REST. I am hoping you will see the > > bonus in asynch. I think the two are very > > complimentary. > > Dude! You don't have to sell me on asynch, I'm totally sold --- over five years ago I was trying > to explain to everybody that would listen that global-scale event notifications were indeed the > next big thing. That was the WHOLE PREMISE behind my last company, Activerse! (Lesson learned: > sell applications, not infrastructure.) What you're failing to sell me on is the idea that HTTP > applications don't need to communicate asynchronously (in-the-large, i.e. in a macro sense) over > HTTP. Oh. Ok. Then we are largely on the same page. I only arguing that HTTP asynch should provide all the services I now get from SMTP. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Mon, 28 Jan 2002, Jeff Bone wrote: > SMTP's asynchrony --- and that's not even really the right word, at an application level it's > unidirectional in the success case --- arises as application-level semantics from a series of > synchronous interactions between entities that are tightly coupled in time. There's no reason > whatsoever why SMTP as a protocol is better than HTTP as a protocol for this purpose; the primary > advantage is that SMTP servers already understand routing and store-and-forward and have > infrastructure in place to support this. It comes down to the fact that SMTP also specifies retry and relay behavior. That each handoff is synchronous is irrelevant. The upshot is that SMTP allows endpoints to communicate that are NEVER online at the same time If you want to use HTTP for handoffs instead of SMTP. You need to specify retry and relay behavior and define a notion of desination address distinct from the relay agent URL. In other words you need to define a protocol that rides on top of HTTP in the same way that HTTP rides on top of TCP/IP. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > Paul, > > I think we are having a miscommunication. I am > not advocating SMTP/POP here. I am suggesting > HTTP replacements for the SMTP/POP architecture > with which people are already comfortable. Okay, I think that's what I'm suggesting too. End of miscommunication! Paul Prescod
"S. Alexander Jacobson" wrote: > Uhm. The current RFC is 2821. Yup, sorry. But two things to note: 2821 is from 2001; 821 is from 1982. SMTP went 19 years without formalizing its retry strategy. Does this suggest anything to you? Like perhaps particular retry strategies are out-of-scope for the protocol specification? Like perhaps they are *higher level semantics* in some sense? Also note that 4.5.4 of 2821 is about retry *STRATEGIES* and consists of a set of conventions and constraints. It's not possible to construct a canonical state machine for the overall behavior of SMTP with *a* single, canonical retry semantics. > Oh. Ok. Then we are largely on the same page. > I only arguing that HTTP asynch should provide all > the services I now get from SMTP. Ok, I'm cool with that --- assuming by HTTP asynch you mean a store-and-forward message delivery application built atop HTTP. jb
On Mon, 28 Jan 2002, Jeff Bone wrote: > > Oh. Ok. Then we are largely on the same page. > > I only arguing that HTTP asynch should provide all > > the services I now get from SMTP. > > Ok, I'm cool with that --- assuming by HTTP asynch you mean a store-and-forward message delivery > application built atop HTTP. Yes. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "Jeff Bone" <jbone@...> > > Lucas' analysis of the security problems with callbacks rests on > a fundamental assumption that I think might be flawed. In order > to illustrate this, we have to ask: what is a notification? > Ahh, lovely question, that. In my idyllic world, notifications are messages 'about' resources - typically about changes to resources. They are also not intended by the sender to perform some action on the receiver - there is no response other than delivery acknowledgement, the status would be '200 Ok, yeah, whatever'.
David Ascher wrote: > > it feels like an ideal testbed for your async HTTP thang. Send me email > (or an HTTP call, or a .NET Alert?) when any page in such and such a > wiki changes. That's a good idea. Our radical idea is that for applications that do not already have a client UI, you could just use HTTP itself for the events. But a bridge to SMTP and .NET alert makes sense for legacy reasons. Paul Prescod
Paul Prescod wrote: > > David Ascher wrote: > > > > it feels like an ideal testbed for your async HTTP thang. Send me email > > (or an HTTP call, or a .NET Alert?) when any page in such and such a > > wiki changes. > > That's a good idea. Our radical idea is that for applications that do > not already have a client UI, you could just use HTTP itself for the > events. But a bridge to SMTP and .NET alert makes sense for legacy > reasons. I understand that. But I believe that radical ideas don't amount to a hill of beans in this world of ours without prototypes, rough drafts and working code =). One of the software efforts I was involved with involved radical ideas clashing against legacy systems. While working for Brown University's IT department, we had a 'grand vision' of a campus wide PKI focused around Kerberos (not sure why -- I think it mostly had to do with legal liability concerns). What it boiled down to on a daily basis was adding Kerberos support to NNTP, SMTP, Gopher and other clients. We were supposed to add this support to all the widely used "open source" (this is before the term =) clients on campus. T'was hell, and it was a failure. Kerberos logins ended up being used only for manipulating contact info in the central database through special-purpose clients, but we never could get enough clients converted, and the world wasn't standing still. Moral of that story? Not sure yet -- I'm still ramping up on REST and HTTP events =). --david PS: Possibly silly question -- HTTP is allowed through firewalls over port 80 in many organizations, which is why it's a good idea for things like WebDAV. However, many of the applications for HTTP Events that I can think of are _personal_, and in the radical vision I'd expect my personal computer to have several apps listening to and sending HTTP events. How do you envision port allocations to work? Would I run a "main event dispatcher" on my port 80, and the apps would register with it? Put concisely, how do you deal with the "Port 80 already in use" problem?
David Ascher wrote: > >... > > I understand that. But I believe that radical ideas don't amount to a > hill of beans in this world of ours without prototypes, rough drafts and > working code =). Yeah, yeah, yeah. We're getting there. First we have to figure out what we're prototyping. >... > T'was hell, and it was a failure. Kerberos logins ended up being used > only for manipulating contact info in the central database through > special-purpose clients, but we never could get enough clients > converted, and the world wasn't standing still. The focus has to be on problems that aren't solved yet. e.g. B2B or web content syndication. >... > PS: Possibly silly question -- HTTP is allowed through firewalls over > port 80 in many organizations, which is why it's a good idea for things > like WebDAV. However, many of the applications for HTTP Events that I > can think of are _personal_, and in the radical vision I'd expect my > personal computer to have several apps listening to and sending HTTP > events. We're talking utopian here. "Personal HTTP Events" is not high on my priority list. I'm thinking more about web services stuff. But here's my Utopian view of personal HTTP events. Your identity will be something like ascher.com/~david There is no need to have different identities for different protocols (email, ftp, http, .NET). You'll have one HTTP-addressable identity. However, portions of the address space can be used for different applications (email versus IM versus web serving). On the other hand, we may find that these different applications are not Your desktop is likely to be either behind a firewall or mobile or distributed between home and work. So like IMAP, I would say that events TO YOU go to this reliable, trusted address, maintained by professionals (or yourself, if you are up to it). Transiant machines you happen to be using can sync parts of that space when you connect to them -- just like IMAP. You can have policies for when things are deleted on either the client or the server. To punch through a firewall you make a single persistent HTTP request to that machine. This request is a fake. It serves the role of a VPN from the server to you. Now you and the server can use plain HTTP events to have it route messages to you in realtime over this pipe. The different apps on your desktop will register themselves with the different portions of the namespace. Probably each of them will set up their own fake HTTP request tunnel. If it gets timed out they can easily re-establish it. The VPN-work-alike hack is necessary because many firewalls will not allow connectivity IN, only OUT. So just like VPN or MSN, you will type in your identity (a URI) and your password and it will contact the intermediary. Unlike MSN (or .NET in general) the outside intermediary is not a big central machine in the sky. It's something run by your ISP or your BSD box at home. The nice thing is that if you turn off an app, you can be confident that your local device isn't still getting barraged by events (e.g. hack attacks) from the outside. Nobody even knows the device exists except your intermediary box. The intermediary box could do spam and virus filtering. Paul Prescod
Paul Prescod wrote: > Yeah, yeah, yeah. We're getting there. First we have to figure out what > we're prototyping. Hence my suggestion of the moinmoin publish & subscribe. =) > The focus has to be on problems that aren't solved yet. e.g. B2B or web > content syndication. Hmm. I'm very much still ramping up on REST, which I see as a minor meme competing for mindshare among the big honkin meme of "XML Web Services", SOAP, etc. Web Services as a whole suffer from (IMO) a lack of down-to-earth-appeal. What are Web Services going to do for me? In what way is the _programmability_ of the web going to change my life/the way I do business? A very small fraction of the world is visionary about WS and "gets it", and those are the people being heard right now. Most of the rest of us are somewhat puzzled and baffled by the acronym soup, the _complexity_ of the solution. Now, REST is intriguing to me for a very simple reason -- it's technologically already there. The part that's left to do is purely a matter of coming up with the bright idea, setting up the social agreement, schemas, partnerships, etc. So REST, inasmuch as it relates to Web Services, can leapfrog the SOAP meme by very quickly retrofitting existing technology and _demonstrating_ _real_ applications. My suggestion: a new page on the Wiki called RealWorldApplications, which provides people pointers to the Meerkats, Magi, KnowKnow, Zope? and the like, and discussions of how they are RESTful. Preferably a compact REST-oriented description of the app would save the readers some digging on corporate sites =). Most importantly, describing how the RESTful nature is an asset. For something like Zope, I think it's relatively easy to get the benefit of the addressability-through-URLs of objects. For Magi, it's not at all obvious without taking a lot of time to dig in. I'd appreciate some pointers. Side question: how does one put Unicode characters in URLs? --david ascher
On Mon, Jan 28, 2002 at 09:17:46PM -0800, David Ascher wrote: > Side question: how does one put Unicode characters in URLs? here's one idea of how to do it; http://search.ietf.org/internet-drafts/draft-masinter-url-i18n-08.txt -- Mark Nottingham http://www.mnot.net/
----- Original Message ----- From: "Paul Prescod" <paul@...> > >... > > PS: Possibly silly question -- HTTP is allowed through firewalls over > > port 80 in many organizations, which is why it's a good idea for things > > like WebDAV. However, many of the applications for HTTP Events that I > > can think of are _personal_, and in the radical vision I'd expect my > > personal computer to have several apps listening to and sending HTTP > > events. > > We're talking utopian here. "Personal HTTP Events" is not high on my > priority list. I'm thinking more about web services stuff. But here's my > Utopian view of personal HTTP events. Nifty. This is what I called 'Appster' - local apps listening to messages on a client (and dealing with firewalled nodes). But rather than a classical server that handles the events by returning data, these events drive UI. The code, framework, APIs etc. can still come from the HTTP server world - essentially take Apache and some useful mods to deal with security, dispatching, etc and add inter-process messages to get to those 'registered apps'. I had hacked up Apache a bit to start this and was working on the COM interface for registering and receiving events - not too difficult. If anybody is interested in starting this up with Apache as the base let me know - I've got a domain we can use to host it... groovier.net Mike
On Mon, 28 Jan 2002, David Ascher wrote: > Side question: how does one put Unicode characters in URLs? URLEncoded. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > On Fri, 25 Jan 2002, S. Mike Dierken wrote: > > > I just took a look at the two knownow demos... > > > If you are talking about the knownow web clients, > > > they don't open a peristent GET, they just make > > > repeated requests, (polling the server). > > They use a persistent response. If the connection is closed, they re-open > > it. That might be where the 'repeated requests' are coming from. Those are > > very infrequent. > > What is a persisent response? I think they may do > keep-alive my repeatedly asking the server "any > messages, any messages,....", but that is still > polling and it is still ugly (a waste of resources > and bandwidth). > They don't repeatedly ask the server "any messages..." Heres what happens: 1) The client does a GET. 2) The server responds with content that is a series of messages. 3) The response stays open. 4) As new message arrive at the server, they slide down the connection to the client. 5) If the connection is dropped, the client re-establishes the connection. That's what I meant by 'persistent response'. It isn't keep-alive (multiple request/response with one tcp/ip connection), it is a long-lived response, it looks like a really big document. The browser parses this in a streaming fashion and calls back into javascript as it encounters it in the stream. > > > > > > If you are talking about the knownow event > > > routers, it sounds like they are implementing > > > listservs. If they are sending out 10k concurrent > > > email messages, that is very nice. If they are > > > sending out only 100-1000 concurrent messages and > > > just claim a max of 10k listeners, that is > > > incredibly unimpressive. > > Oh. Remember, I don't have real numbers as I do not work there > > If you don't have real numbers then lets drop > knownow. Ok. If it makes you uncomfortable. > > > > Either way, this has little to do with persistent > > > GET and the merits of HTTP for presence > > > applications. The main point is that HTTP is > > > suboptimal for this application (but you may need > > > it if the client is a web browser). > > If the client were another server, would http be sufficient? > > Not if you only want to send messages when the > client is "available." > > > > Yeah. Me too. How many chat clients can your web server support? > > 10,000. Like I said, the KN server can handle 10k concurrent browser clients > > per cluster node. > > Ok. Great. What is the polling frequency? There isn't any polling. Just like a TCP/IP connection, you re-open it if the connection is dropped. Not on an interval basis. > My point is that whatever the number, a server > that allows clients to hold open connections for > long periods of time will perform orders of > magnitude better. That is true. That is why that company has a server that allows clients to hold open connections for long periods of time. > > You could implement with HTTP if the server chunk > encoded delivery of messages and the client held > the connection open long enough, but as you noted > this is a serious abuse of HTTP and as I noted, > most servers and intermediaries aren't happy to > let an HTTP connection stay silent for too long. > > > > Even if your server could handle higher capacity > > > the bandwidth of handling large numbers of pings > > > will also eventually overwhelm you. > > > > > > Alternatively, you could also document a > > > more scalable protocol like Jabber, IRC, or Kazaa, > > > give away the source, get the same hackers to > > > work on it, and perhaps get bought by AOL! > > Or examine your assumptions. > > > > Nobody here is suggesting polling is the preferred way to go. A server that > > transparently handled polling for backward compatibility would help in many > > situations, as long as the scalability/traffic problems don't surface. > > The issue is that HTTP requires polling to > establish presence. I don't understand what you mean. > > Let me ask it all another way, do you want to use > HTTP instead of telnet/ssh (to interact with the > shell)? Yes.
On Mon, 28 Jan 2002, Paul Prescod wrote: > Your identity will be something like > > ascher.com/~david > > There is no need to have different identities for different protocols > (email, ftp, http, .NET). You'll have one HTTP-addressable identity. Why not lett that identity continue to be e.g. david@...? On most browsers, typing in http://david@... results in ther header: host: david@... It is up to the server implementation to know that david@... is distinct from john@.... Since servers MUST pay attention to host headers anyway, this seems like the way to go.... -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
The portion before the '@' in the authority is 'userinfo', which in HTTP is used for authentication. So, http://david@.../ would result in a host header Host: ascher.com and a challenge to the user for the password for 'david'. Cheers, On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote: > On Mon, 28 Jan 2002, Paul Prescod wrote: > > Your identity will be something like > > > > ascher.com/~david > > > > There is no need to have different identities for different protocols > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity. > > Why not lett that identity continue to be e.g. > david@...? > > On most browsers, typing in > http://david@... results in ther header: > > host: david@... > > It is up to the server implementation to know that > david@... is distinct from john@.... > Since servers MUST pay attention to host headers > anyway, this seems like the way to go.... > > -Alex- > ___________________________________________________________________ > S. Alexander Jacobson i2x Media > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
On Tue, 29 Jan 2002, Mark Nottingham wrote: > The portion before the '@' in the authority is 'userinfo', > which in HTTP is used for authentication. So, > http://david@.../ > would result in a host header > Host: ascher.com > and a challenge to the user for the password for 'david'. Only if the resource requires authentication. The spec does not _require_ that a POST to david@... requires authentication. Moreover, the issue of authentication is really handled in a separate header. Moreover, there is no reason to think that a POST to david@... is equivalent to a POST to john@.... So it seems like we can keep using email addresses even if we switch to HTTP delivery mechanisms. That being said, I am not sure how to replace the functionality of MX records and relays in HTTP. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax > > On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote: > > On Mon, 28 Jan 2002, Paul Prescod wrote: > > > Your identity will be something like > > > > > > ascher.com/~david > > > > > > There is no need to have different identities for different protocols > > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity. > > > > Why not lett that identity continue to be e.g. > > david@...? > > > > On most browsers, typing in > > http://david@... results in ther header: > > > > host: david@... > > > > It is up to the server implementation to know that > > david@... is distinct from john@.... > > Since servers MUST pay attention to host headers > > anyway, this seems like the way to go.... > > > > -Alex- > > ___________________________________________________________________ > > S. Alexander Jacobson i2x Media > > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > -- > Mark Nottingham > http://www.mnot.net/ > >
If the server doesn't require authentication, the username will be lost; the request-line for http://david@.../ will look like GET / Host: ascher.com On Tue, Jan 29, 2002 at 04:13:56PM -0500, S. Alexander Jacobson wrote: > On Tue, 29 Jan 2002, Mark Nottingham wrote: > > The portion before the '@' in the authority is 'userinfo', > > which in HTTP is used for authentication. So, > > http://david@.../ > > would result in a host header > > Host: ascher.com > > and a challenge to the user for the password for 'david'. > > Only if the resource requires authentication. > The spec does not _require_ that a POST to > david@... requires authentication. > Moreover, the issue of authentication is really > handled in a separate header. > > Moreover, there is no reason to think that a POST > to david@... is equivalent to a POST to > john@.... > > So it seems like we can keep using email addresses > even if we switch to HTTP delivery mechanisms. > > That being said, I am not sure how to replace the > functionality of MX records and relays in HTTP. > > -Alex- > > > ___________________________________________________________________ > S. Alexander Jacobson i2x Media > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > > On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote: > > > On Mon, 28 Jan 2002, Paul Prescod wrote: > > > > Your identity will be something like > > > > > > > > ascher.com/~david > > > > > > > > There is no need to have different identities for different protocols > > > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity. > > > > > > Why not lett that identity continue to be e.g. > > > david@...? > > > > > > On most browsers, typing in > > > http://david@... results in ther header: > > > > > > host: david@... > > > > > > It is up to the server implementation to know that > > > david@... is distinct from john@.... > > > Since servers MUST pay attention to host headers > > > anyway, this seems like the way to go.... > > > > > > -Alex- > > > ___________________________________________________________________ > > > S. Alexander Jacobson i2x Media > > > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > -- Mark Nottingham http://www.mnot.net/
On Tue, 29 Jan 2002, Mark Nottingham wrote: > If the server doesn't require authentication, the username will be > lost; the request-line for http://david@.../ will look like > GET / > Host: ascher.com That doesn't make sense. The client does not know in advance that the server requires authentication. All browsers I've used (including IE and lynx) send: Host: david@... They may also send an Authorization: or Cookie: header, but that is a separate issue. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax > > > > On Tue, Jan 29, 2002 at 04:13:56PM -0500, S. Alexander Jacobson wrote: > > On Tue, 29 Jan 2002, Mark Nottingham wrote: > > > The portion before the '@' in the authority is 'userinfo', > > > which in HTTP is used for authentication. So, > > > http://david@.../ > > > would result in a host header > > > Host: ascher.com > > > and a challenge to the user for the password for 'david'. > > > > Only if the resource requires authentication. > > The spec does not _require_ that a POST to > > david@... requires authentication. > > Moreover, the issue of authentication is really > > handled in a separate header. > > > > Moreover, there is no reason to think that a POST > > to david@... is equivalent to a POST to > > john@.... > > > > So it seems like we can keep using email addresses > > even if we switch to HTTP delivery mechanisms. > > > > That being said, I am not sure how to replace the > > functionality of MX records and relays in HTTP. > > > > -Alex- > > > > > > ___________________________________________________________________ > > S. Alexander Jacobson i2x Media > > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > > > > > > On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote: > > > > On Mon, 28 Jan 2002, Paul Prescod wrote: > > > > > Your identity will be something like > > > > > > > > > > ascher.com/~david > > > > > > > > > > There is no need to have different identities for different protocols > > > > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity. > > > > > > > > Why not lett that identity continue to be e.g. > > > > david@...? > > > > > > > > On most browsers, typing in > > > > http://david@... results in ther header: > > > > > > > > host: david@... > > > > > > > > It is up to the server implementation to know that > > > > david@... is distinct from john@.... > > > > Since servers MUST pay attention to host headers > > > > anyway, this seems like the way to go.... > > > > > > > > -Alex- > > > > ___________________________________________________________________ > > > > S. Alexander Jacobson i2x Media > > > > 1-212-787-1914 voice 1-603-288-1280 fax > > > > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > -- > > > Mark Nottingham > > > http://www.mnot.net/ > > > > > > > > > > > > -- > Mark Nottingham > http://www.mnot.net/ > >
This is a bizarre discussion. The "Host" header specifies a *host*. If we're going to start putting email addresses there, why not use the Cache-Control or Expires headers (or any other header not named From)? None of them support email addresses either. This isn't the "abuse-rest-discuss" list. Let's first discuss how REST, HTTP, and URIs can do it *without extension or additional a priori agreement*. If that fails, then we can consider extensions, abuse, or both. > That doesn't make sense. The client does not know > in advance that the server requires > authentication. All browsers I've used > (including IE and lynx) send: > > Host: david@... > > They may also send an Authorization: or Cookie: > header, but that is a separate issue. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Tue, 29 Jan 2002, Mark Baker wrote: > This is a bizarre discussion. The "Host" header specifies a *host*. RFC2616 does not define host except to say that: The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. SMTP is more extreme. Mail to david@... is handled by the MX record for ascher.com not by any host named ascher.com. > If we're going to start putting email addresses there, why not use the > Cache-Control or Expires headers (or any other header not named From)? > None of them support email addresses either. The expires field value is required to be a date. Cache control has similar, though more complex restrictions and does not seem to support the behavior described. Since this host header behavior seems to be implemented universally and is consistent with the meaning of the spec, I don't see a problem. If it is, why does everything seem to implement this behavior? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax > > This isn't the "abuse-rest-discuss" list. Let's first discuss how REST, > HTTP, and URIs can do it *without extension or additional a priori > agreement*. If that fails, then we can consider extensions, abuse, > or both. > > > That doesn't make sense. The client does not know > > in advance that the server requires > > authentication. All browsers I've used > > (including IE and lynx) send: > > > > Host: david@... > > > > They may also send an Authorization: or Cookie: > > header, but that is a separate issue. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com >
"S. Alexander Jacobson" wrote: > On Tue, 29 Jan 2002, Mark Baker wrote: > > This is a bizarre discussion. The "Host" header specifies a *host*. > > RFC2616 does not define host That's because, while RFCs strive to be comprehensive, the authors of 2616 (and many other RFCs) never in their wildest dreams ever imagined that anyone in this day and age and this context could be obtuse enough to interpret "host" to mean "an abstract pairing of a user name and a domain naming authority, intended to be named by and messageable via SMTP." ;-) > SMTP is more extreme. Mail to david@... > is handled by the MX record for ascher.com not by > any host named ascher.com. Yeah, THAT'S always been a good idea, hasn't it? :-/ > The expires field value is required to be a date. And the host field is required to be a... host? Who'd'a thunk it? Oh, we want to use it for other purposes? Ok, let's just redefine it --- if we call "joe@..." a "host" then we can use that wherever "host" is used! (Sorry, couldn't resist. But seriously, folks...) jb
On Tue, 29 Jan 2002, Jeff Bone wrote: > > SMTP is more extreme. Mail to david@... > > is handled by the MX record for ascher.com not by > > any host named ascher.com. > > Yeah, THAT'S always been a good idea, hasn't it? Actually I think it has. SMTP provides a nice way of failing over when a machine goes down (or is too busy). Do you think the variety of ugly HTTP load balancing schemes are better? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > On Tue, 29 Jan 2002, Jeff Bone wrote: > > > SMTP is more extreme. Mail to david@... > > > is handled by the MX record for ascher.com not by > > > any host named ascher.com. > > > > Yeah, THAT'S always been a good idea, hasn't it? > > Actually I think it has. SMTP provides a nice way > of failing over when a machine goes down (or is > too busy). Do you think the variety of ugly HTTP > load balancing schemes are better? Irrelevant. The issue here is that SMTP routing behavior is defined and configured by an out-of-band mechanism, DNS --- that's bad enough by itself, and made worse still by some of the unpleasant specifics of DNS and its use. DNS is (still) relatively rigid, non-dynamic, unidirectional, slow-changing, and brittle. (Indeed, you can think of DHCP as a response in part to DNS's unidirectional and slow-changing / difficult-to-change characteristics.) SMTP's correct behavior unfortunately depends on correct DNS configuration, availability, etc; DNS is a thorn in the side of SMTP, and at the same time SMTP support has long been a conceptual and architectural tumor growing on / in DNS. SMTP inherits a lot of its bletcherousness from its intimate and unseemly relationship with DNS, and IMO that alone is a good enough reason to begin thinking about its replacement. The dependency is a Bad Thing (tm) any way you look at it. This was all fine in a world of tens to hundreds of hosts and tens to hundreds of thousands of users, with smart, technical guys running the show administratively, where "churn" was minimal because most of the folks involved were academics who didn't "move around a lot." The assumptions are no longer valid --- we live in a world with tens of millions of hosts, hundreds of millions of users, increasing ephemerality of connection, high rates of user<->host and topological churn. Clay Shirky and many others have noted that DNS is collapsing under its own weight and architectural limitations. Alex, I agree with you that the Web needs its own naming and routing mechanisms --- but we *certainly* shouldn't base our solutions on the very same fallacious assumptions that created the problems in the first place! jb PS - I have in the past floated the idea (the "metaweb") of using verifiable naming and HTTP's own 3xx response as a routing primitive in combination to make the Web self-naming and self-routing, independent of DNS and free from many of its current, unpleasant and unnecessary administrative constraints. This is probably do-able with minimal impact on the existing Web architecture. There's a large amount of current work going on along these lines relative to distributed filesystems, filesharing, p2p and decentralized systems. It would be nice to see a principled design for such functionality available for general use within the Web community.
I always thought the www.foo.com ftp.foo.com convention was a wart on DNS for not providing MX equivalents for other services. I don't think that DHCP has anything to do with DNS! > PS - I have in the past floated the idea (the "metaweb") of using > verifiable naming and HTTP's own 3xx response as a routing primitive in > combination to make the Web self-naming and self-routing, independent of > DNS and free from many of its current, unpleasant and unnecessary > administrative constraints. This is probably do-able with minimal > impact on the existing Web architecture. Hmm. Interesting. Can you expand on that? Does it solve the problem of failover servers/load balancing? > There's a large amount of > current work going on along these lines relative to distributed > filesystems, filesharing, p2p and decentralized systems. It would be > nice to see a principled design for such functionality available for > general use within the Web community. Yes thats true, but it seems to focus on identifying documents not resources. These are different. The most obvious replacement for names is google's "I feel lucky", but I don't think it is really what you want in a protocol. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > > > "S. Alexander Jacobson" wrote: > > > On Tue, 29 Jan 2002, Jeff Bone wrote: > > > > SMTP is more extreme. Mail to david@... > > > > is handled by the MX record for ascher.com not by > > > > any host named ascher.com. > > > > > > Yeah, THAT'S always been a good idea, hasn't it? > > > > Actually I think it has. SMTP provides a nice way > > of failing over when a machine goes down (or is > > too busy). Do you think the variety of ugly HTTP > > load balancing schemes are better? > > Irrelevant. The issue here is that SMTP routing behavior is defined and > configured by an out-of-band mechanism, DNS --- that's bad enough by > itself, and made worse still by some of the unpleasant specifics of DNS > and its use. DNS is (still) relatively rigid, non-dynamic, > unidirectional, slow-changing, and brittle. (Indeed, you can think of > DHCP as a response in part to DNS's unidirectional and slow-changing / > difficult-to-change characteristics.) SMTP's correct behavior > unfortunately depends on correct DNS configuration, availability, etc; > DNS is a thorn in the side of SMTP, and at the same time SMTP support > has long been a conceptual and architectural tumor growing on / in DNS. > SMTP inherits a lot of its bletcherousness from its intimate and > unseemly relationship with DNS, and IMO that alone is a good enough > reason to begin thinking about its replacement. The dependency is a Bad > Thing (tm) any way you look at it. > > This was all fine in a world of tens to hundreds of hosts and tens to > hundreds of thousands of users, with smart, technical guys running the > show administratively, where "churn" was minimal because most of the > folks involved were academics who didn't "move around a lot." The > assumptions are no longer valid --- we live in a world with tens of > millions of hosts, hundreds of millions of users, increasing > ephemerality of connection, high rates of user<->host and topological > churn. > > Clay Shirky and many others have noted that DNS is collapsing under its > own weight and architectural limitations. Alex, I agree with you that > the Web needs its own naming and routing mechanisms --- but we > *certainly* shouldn't base our solutions on the very same fallacious > assumptions that created the problems in the first place! > > jb > > PS - I have in the past floated the idea (the "metaweb") of using > verifiable naming and HTTP's own 3xx response as a routing primitive in > combination to make the Web self-naming and self-routing, independent of > DNS and free from many of its current, unpleasant and unnecessary > administrative constraints. This is probably do-able with minimal > impact on the existing Web architecture. There's a large amount of > current work going on along these lines relative to distributed > filesystems, filesharing, p2p and decentralized systems. It would be > nice to see a principled design for such functionality available for > general use within the Web community. > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Mark Baker" <distobj@...> > > This isn't the "abuse-rest-discuss" list. You are correct - this is: http://groups.yahoo.com/group/abuse-rest-discuss/
Oopsie on that last one. > PS - I have in the past floated the idea (the "metaweb") of using > verifiable naming and HTTP's own 3xx response as a routing primitive in > combination to make the Web self-naming and self-routing, independent of > DNS and free from many of its current, unpleasant and unnecessary > administrative constraints. This is probably do-able with minimal > impact on the existing Web architecture. There's a large amount of > current work going on along these lines relative to distributed > filesystems, filesharing, p2p and decentralized systems. It would be > nice to see a principled design for such functionality available for > general use within the Web community. Yup. You can do this without redirection too. If you think about it, any intermediary along a path is a potential new context in which a URI can be interpreted and which can be forwarded on without redirecting back to the initiator. I recall a very old (pre-Bone) FoRK post in which Rohit suggested that in order for naming to decentralize, we have to move to relative names such as "Rohit's Adam", which may be URIfied as; http://[rohit's pgp key]/adam MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > I always thought the www.foo.com ftp.foo.com > convention was a wart on DNS for not providing MX > equivalents for other services. Ugh. (BTW, of course www.xxx.yyy and ftp.xxx.yyy don't have any actual semantic signficance.) It's hard enough maintaining MX records in DNS, why in the world do we want equivalents for other services? Yuck. > I don't think that DHCP has anything to do with > DNS! No, of course it doesn't. I was trying to draw an architectural distinction, not claim that they solve the same problem in different ways. (If you squint while you read it, you'll see the point I was making rather badly. ;-) > > PS - I have in the past floated the idea (the "metaweb") of using > > verifiable naming and HTTP's own 3xx response as a routing primitive in > > combination to make the Web self-naming and self-routing, independent of > > DNS and free from many of its current, unpleasant and unnecessary > > administrative constraints. This is probably do-able with minimal > > impact on the existing Web architecture. > > Hmm. Interesting. Can you expand on that? Probably beyond the scope of this discussion, but this area has been a research focus of mine for about 18 months, now. Still trying to sort out how much is public vs. how much is entangled with my current company, but at some point I hope be able to freely discuss this in some detail. (Focus as the current play evolved has shifted / narrowed somewhat from our original effort in this area, so I'm optimistic about being able to open it up.) > Does > it solve the problem of failover servers/load > balancing? Not by itself, but it provides potential support for such solutions. > > There's a large amount of > > current work going on along these lines relative to distributed > > filesystems, filesharing, p2p and decentralized systems. It would be > > nice to see a principled design for such functionality available for > > general use within the Web community. > > Yes thats true, but it seems to focus on > identifying documents not resources. These are > different. A key thing to understand is that there's a fundamental difference between semantic names and identifiers. Semantic name resolution maps a name to a set, potentially of order 1. Identifier resolution maps an identifier which uniquely identifies a single object onto that object. (Punt on the issue of whether "identified" objects are required to be immutable.) There're some interesting mathematical games you can play with the distinction between these things. ;-) The big difference is that while moving, caching, replicating, etc. static documents is trivial and can be safely assumed, the same cannot be said for resources in general. > The most obvious replacement for names is google's > "I feel lucky", but I don't think it is really > what you want in a protocol. We're always going to need three kinds of names: semantic names that map to sets of objects of arbitrary size, semantic names that map to a set of objects guaranteed to be of order 1, and names that map to a specific object i.e. are "self-verifying." For the first two kinds of naming, name resolution does indeed have to be a service. The idea is to find ways to make this service as decentralized, as dynamic, and as local in administrative scope as possible. $0.02, jb
On Tue, 29 Jan 2002, Mark Baker wrote: > I recall a very old (pre-Bone) FoRK post in which Rohit suggested > that in order for naming to decentralize, we have to move to > relative names such as "Rohit's Adam", which may be URIfied as; > > http://[rohit's pgp key]/adam And you were complaining about MY abuse of HTTP! Btw, this would suck as rohit's pgp key got compromised. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
One for the "spatial metaphors don't apply in bitspace" file,
Brandon Gillespie has an article on biological network security
that's perhaps of some interest, particularly given the
discussion over the weekend about security. (I know, you read
Slashdot, too... just pointing out the article. :-)
http://www.securityfocus.com/guest/10094
jb
In my recent post on a quasi-protocol named Paranoid Sink Protocol, I articulated a design for secure callbacks based on the HTTP 0.9 protocol. A part of that design that has stuck in my mind is the idea that callbacks would be idempotent. This message articulates related thoughts. Other recent related conversations in rest-discuss, e.g. my own aREST document and Paul Prescod's HTTP Notifications document, built event notifications using the POST method. POST was necessary because the event notifications contained the content of the event. The sink was expected to store the new content, and if the sink stores incoming data then the sink state has changed. In my PSP post I articulated a different type of event notification. This event notification is nothing but a notification that state had changed; the notification does not contain any information about the new state. If the sink wants a detailed update it has to perform a follow-up request. This approach has the useful feature that notifications from source to sink are idempotent, because any N notifications where N > 1 have the same effect on state at the sink. Because it is idempotent it may use the GET method. Constrast a GET notification to a POST notification. The POST notification needs to say what about the state changed. This opens the pandora's box of version control. Groove takes this approach -- a steady stream of state change messages that include information to reconstruct the new state. And Paul's proposal also used it, in that it included modifiers to describe a number of types of state changes, each of which needed to be combined with the notification payload and the existing copy of the state to create an up to date copy. A POST message is not only a notification, it is also an update. Idempotent notifications leave all such issues to ride over the top, as application issues. This has the primary advantage of better separation between infrastructure and application and the secondary advantages of simpler implementation and greater security. If there is no need to handle conflict resolution at the notification level, notification can be one specialist part of the web infrastructure and version control another. If a badly administered local web server doesn't have to expose non-idempotent APIs, it has better security. Everything has it's place, and clearly there are advantages to non-idempotent notifications. Idempotent notifications do not allow a sink to know about states that happen between the time the event is emitted and the time the follow-up request from the sink is received. Only non-idempotent notifications allow a sink the keep track of all changes. Applications for which every tick counts, like scientific applications that need extremely fine grained data points, have to have non-idempotent notifications. Real time stock data is invariably transmitted as a stream of states, not a stream of notifications. (Are there other applications that have to have non-idempotent notifications? Don't know.) But I wouldn't call these notifications, I would call them push updates. So POST implies updates, while GET implies notifications. - Lucas
> On Tue, 29 Jan 2002, Mark Baker wrote: > > I recall a very old (pre-Bone) FoRK post in which Rohit suggested > > that in order for naming to decentralize, we have to move to > > relative names such as "Rohit's Adam", which may be URIfied as; > > > > http://[rohit's pgp key]/adam > > And you were complaining about MY abuse of HTTP! > Btw, this would suck as rohit's pgp key got > compromised. It may require a new URI scheme to deploy, but hopefully not. And it's far from an abuse. The part after the "//" is an authority, and a public key is a perfectly valid authority. When you decentralize, you do sacrifice some advantages of centralization, granted. But I'd personally be willing to make the "rent a DNS address" versus "own a public key" tradeoff if I could. Also, nothing prevents Verisign from trying to push PKI here and suggesting that all key holders need them as a CA. Naming is as much a trust issue as it is anything else. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Tue, 29 Jan 2002, Mark Baker wrote: > > On Tue, 29 Jan 2002, Mark Baker wrote: > > > I recall a very old (pre-Bone) FoRK post in which Rohit suggested > > > that in order for naming to decentralize, we have to move to > > > relative names such as "Rohit's Adam", which may be URIfied as; > > > > > > http://[rohit's pgp key]/adam > > > > And you were complaining about MY abuse of HTTP! > > Btw, this would suck as rohit's pgp key got > > compromised. > > It may require a new URI scheme to deploy, but hopefully not. And it's > far from an abuse. The part after the "//" is an authority, and a > public key is a perfectly valid authority. How is this less of an abuse than using email address? distobj@... is also an authorty... > When you decentralize, you do sacrifice some advantages of > centralization, granted. But I'd personally be willing to make the > "rent a DNS address" versus "own a public key" tradeoff if I could. > Also, nothing prevents Verisign from trying to push PKI here and > suggesting that all key holders need them as a CA. Naming is as > much a trust issue as it is anything else. Ok, but onces you invoke a CA you are talking about something different: http://[rohit's CA id]/adam The CA then certifies a particular public key as being under the control of the entity represented by this ID. To me this all sounds like DNS with SSL certificates. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > It may require a new URI scheme to deploy, but hopefully not. And it's > > far from an abuse. The part after the "//" is an authority, and a > > public key is a perfectly valid authority. > > How is this less of an abuse than using email > address? distobj@... is also an authorty... I didn't say it wasn't. It's just tied to DNS too (MX records or A records, doesn't matter), so has the same icky dependancy. You can only rent those names, not own them. > Ok, but onces you invoke a CA you are talking > about something different: > > http://[rohit's CA id]/adam > > The CA then certifies a particular public key as > being under the control of the entity represented > by this ID. To me this all sounds like DNS with > SSL certificates. Well, sorta. I'm not saying that a CA is required, only that Verisign could play it this way (I wonder if they knew what they were getting into when they acquired Netsol?). Plus, though a CA centralizes one part of the system (trust), you still *own* your key. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Tue, 29 Jan 2002, Mark Baker wrote: > Well, sorta. I'm not saying that a CA is required, only that Verisign > could play it this way (I wonder if they knew what they were getting > into when they acquired Netsol?). Plus, though a CA centralizes one > part of the system (trust), you still *own* your key. Owning your own key is irrelevant. What matters is the mapping from the key to the id and you necessarily rent that. As a whole, I would suggest that you own your name more than you own your cert. Verisign can mess with cert requirements any time it wants -- making it difficult to renew. Your claim to ownership of an id is a bit stronger. You just have to pay to retain it. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > Your claim to ownership of an id is a bit > stronger. You just have to pay to retain it. Nonononono --- id's don't have to be rented, sold, etc. What *is* an id, anyway? Online, it's just a guarantee of continuity of some kind. I.e., the person doing this thing today is the same person who did it yesterday. In order to prove that continuity, all that's needed is a persistent secret that only the principal in question knows, which can be used in a zero-knowledge fashion. This can easily be done with 2 parties and relatively mild crypto. Tying that in any useful way to the "real world" notion of identities is probably unnecessary for most or all applications, and often undesirable. And that tying is the only reason for a trust relationship with a third-party authentication / cert agent. jb
> This approach has the useful feature that notifications from source to sink are > idempotent, because any N notifications where N > 1 have the same effect on > state at the sink. Because it is idempotent it may use the GET method. Not true. By definition, the resource identified by the callback URI changes state when notified of an event (call it a "mailbox" or whatever). That means that there are side-effects, and therefore GET is not appropriate. > A POST message is not only a notification, it is also an update. It need not be. The body could just be a URI, for example. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > > This approach has the useful feature that notifications from source to sink are > > idempotent, because any N notifications where N > 1 have the same effect on > > state at the sink. Because it is idempotent it may use the GET method. > > Not true. By definition, the resource identified by the callback URI > changes state when notified of an event (call it a "mailbox" or > whatever). That means that there are side-effects, and therefore GET is > not appropriate. > > > A POST message is not only a notification, it is also an update. > > It need not be. The body could just be a URI, for example. You might noticed an apparent contradiction there. I was assuming that by "update" you meant that the POST body was used in determining how the state of the callback resource was modified. This may not be the case, because it's possible that all that resource needs to know to make a state change is *that* a POST was invoked, not the contents of the POST body. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
The issue with id's is handling key compromise/revocation etc. The CA just guarantees continuity accross keys. This guarantee may or may not involve the real world. In particular, verisign server certs don't actually involve the real world at all. Instead they involve the world of corporate documents and providing bona-fides as a business. Note: Versign actually guarantees something weaker than what I describe above. If company A buys a domain name from Company B and then obtains a cert, you are not actually guaranteed that there is continuity of identity. Note: The economic function of a CA is to insure against key compromise. One could think of CA costs as insurance premiums rather than rents. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax On Wed, 30 Jan 2002, Jeff Bone wrote: > > "S. Alexander Jacobson" wrote: > > > Your claim to ownership of an id is a bit > > stronger. You just have to pay to retain it. > > Nonononono --- id's don't have to be rented, sold, etc. What *is* an id, > anyway? Online, it's just a guarantee of continuity of some kind. I.e., the > person doing this thing today is the same person who did it yesterday. In > order to prove that continuity, all that's needed is a persistent secret that > only the principal in question knows, which can be used in a zero-knowledge > fashion. This can easily be done with 2 parties and relatively mild crypto. > > Tying that in any useful way to the "real world" notion of identities is > probably unnecessary for most or all applications, and often undesirable. > And that tying is the only reason for a trust relationship with a third-party > authentication / cert agent. > > jb > >
> > > A POST message is not only a notification, it is also an update. > > > > It need not be. The body could just be a URI, for example. > > You might noticed an apparent contradiction there. I was assuming that > by "update" you meant that the POST body was used in determining how > the state of the callback resource was modified. This may not be the > case, because it's possible that all that resource needs to know to > make a state change is *that* a POST was invoked, not the contents of > the POST body. > > MB I did. It left me mightly confused. :) The case that boolean notifications are idempotent is that they are flags with identical meaning. So when a sink receives 2 of them it has the same effect on state as when it receives one, and therefore it is not true that the resource identified by the callback URI necessarily changes state. On a more literal level I defer to RFC 2616: 9.1.2 Idempotent Methods Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. 0 boolean notifications are not the same as 1 notification, but any N > 0 notifications have the same effect as 1 notification. Now, there _is_ an error in my thoughts from this morning, which is that boolean notifications overwrite whatever the previous state of the flag (as held on the sink). So the proper method is PUT, not GET. - Lucas
It should be asked what constitutes a change of state sufficient to trigger a notification. A solid working definition is that an idempotent query would have different results. It is self evident that non-idempotent queries can't be used for watch expressions, because otherwise the act of performing a watch changes the result. Though this is a trivial observation, I am personally happy to have any little bit of solid ground.
A recurring theme is requests about requests. For example, a watch request needs to express the request to watch, a store-and-forward request needs to enclose the request to store-and-forward within a request to perform the store-and-forward, an update request needs to state the parameters of the callback POST request. This creates a couple problems. One, enclosed requests are objects rather than streams, so are inconsistent with persistent connections. Two, there are problems with opacity, since intermediaries have practical reasons to need to do some rewriting, and since the two requests may be mixed in together. For example a store-and-forward CGI needs to rewrite the Host: header to a Via: header, or even rewrite the target URI to change to host. An example of how tricky this gets is accept headers in a store-and-forward chain: the originating host may accept a type that an intermediary doesn't. Streaming audio, for example. There may always be clever ways to avoid having to solve the RIR problem, I don't know. This post is just to recognize that it exists, since that sometimes helps break through on an issue.
> I did. It left me mightly confused. :) 8-) > notifications overwrite whatever the previous state of the flag (as held on the > sink). So the proper method is PUT, not GET. Agreed, for boolean notifications. However, not all notifications are boolean, the same way that not all resources are boolean. Sometimes a subscription is created for more than just knowing *when* state changes. Sometimes it's created to know *how* state changes. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> It should be asked what constitutes a change of state sufficient to trigger a > notification. In general, that should be up to the resource. Encapsulation, and all that jazz. > A solid working definition is that an idempotent query would have > different results. It is self evident that non-idempotent queries can't be used > for watch expressions, because otherwise the act of performing a watch changes > the result. Well, so far we've been talking about invoking the WATCH method on URIs. Non-idempotent queries, if I understand you correctly, would be done over POST and therefore not identifiable with a URI. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> There may always be clever ways to avoid having to solve the RIR problem, I > don't know. This post is just to recognize that it exists, since that sometimes > helps break through on an issue. In all the funky stuff I've done with HTTP, I've *never* had to encapsulate an HTTP message. Given that, I think it's probably safe to say that if you're doing it, either you're doing something wrong, or you've got some really bizarre situation (like the one Mike described recently). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Lucas Gonze" <lucas@...> > It should be asked what constitutes a change of state sufficient to trigger a > notification. A solid working definition is that an idempotent query would have > different results. > It is self evident that non-idempotent queries can't be used > for watch expressions, because otherwise the act of performing a watch changes > the result. Do you mean 'non-idempotent HTTP requests can't be used to create a subscription'? Or do you mean 'the evaluation of whether a subscription matches a particular occurrance must not cause a non-idempotent request to be sent to the resource that is subscribed'? BTW - I still maintain that http-based subscriptions and notifications should be described in terms of any and all possible http methods upon a resource, regardless of status (success, error, etc.). A subscription should be able to specify all three : resource, method and status. A notification should identify all three. This is difficult to describe with the existing http because the method and status never appear outside the first line of request or response - there is no current situation where a header holds either of these values (as far as I know).
Mark Baker wrote: > > ... > > Agreed, for boolean notifications. However, not all notifications are > boolean, the same way that not all resources are boolean. Sometimes a > subscription is created for more than just knowing *when* state changes. > Sometimes it's created to know *how* state changes. We *could* model our resources such that all notifications are boolean. For instance you would get a notification that a thousand page document has changed. Then the client uses some WebDAV/DeltaV magic to get a diff from the version it has to the version the server has. I like the idea of idempotent notifications because it means that the listener could go off the network for seven hours and get "back in sync" on the very first notification it gets, or even before it gets a notification. So for instance if we were in a chat session and I get cut off then my chat client could miss a bunch change notifications but sync up whenever it wanted to. Loose coupling. So I would say that if an "event" is important enough that a client wants to know WHAT changed, not just WHEN it changed then the event should be reified in the server as a resource and persist for some number of hours or days, unless deleted. As an *optimization*, it may make sense to have message bodies with "diffs". But if you detected that you had missed one it would be no big deal because you could just sync up. Can you describe an application that is better modeled with non-idempotent notifications? Paul Prescod
"S. Mike Dierken" wrote: > >... > > BTW - I still maintain that http-based subscriptions and notifications > should be described in terms of any and all possible http methods upon a > resource, regardless of status (success, error, etc.). A subscription should > be able to specify all three : resource, method and status. A notification > should identify all three. This is difficult to describe with the existing > http because the method and status never appear outside the first line of > request or response - there is no current situation where a header holds > either of these values (as far as I know). I'm starting to buy Lucas' point that any information in the notification other than "something happened" must be considered "advisory" and must be available somewhere on the server. Otherwise if you miss a single message you get out of sync and I think we're all sick of systems like that. So to model a chat application, there would be a resource representing the transcript (perhaps segmented as it began to get big). If you ever missed a notification there should be an easy way to get back into sync. If you joined the chat mid-stream you could actually see what went on before you got there. There would never be any doubt about whether someone got a particular message or not because they would all be available as part of the resource (or as independent resources). Paul Prescod
I'm not sure idempotency applies to notifications. I thought it only applied to request/response message exchanges. A notification is not a request to cause something to happen at the receiver. It might be an 'http request' message format, but I'm not sure its a 'conceptual' request. What is the effect of more than 1 identical notification messages? If a receiver kept a count of messages, this count would be 'inaccurate' - but that (hit counts) is not a case we consider for idempotency anyway. If a receiver waited for a particular event - threshold crossed, etc - and then deleted itself (stopped listening before/without deleting the subscription) the next event probably would result in a 404 or something (listener not found). Is this 'allowable' if notifications are idempotent? (it'd be like two PUTs or two GETs returned an error on the second request /because/ of the first request). Also what is sent in a notification? a) after a POST post(body1)+nostate=response(success,reply1)+state1 notify(??) post(body1)+state1=response(success,reply2)+state2 notify(??) post(body1)+state2=response(success,reply3)+state3 notify(??) b) after a PUT put(body1)+nostate=response(success,reply1)+state1 notify(??) put(body1)+stateX=response(success,reply1)+state1 notify(??) c) after a DELETE delete()+stateX=response(success,body1)+nostate notify(??) delete()+nostate=response(error)+nostate notify(??) d) after a GET get()+state1=response(success,body1)+state1 notify(??) get()+state1=response(success,body1)+state1 notify(??) option a) Use body - notify(post,success,body1) option b) Use state - notify(post,success,state1) Mike
----- Original Message ----- From: "Paul Prescod" <paul@...> > > I'm starting to buy Lucas' point that any information in the > notification other than "something happened" must be considered > "advisory" and must be available somewhere on the server. Otherwise if > you miss a single message you get out of sync and I think we're all sick > of systems like that. Don't send deltas (you need sequence and reliable delivery to stay in synch). If you watch a resource that is a collection, either send a snapshot of the collection (which could be big - so you fragment via hyper-links like you mentioned) or don't send any details. But what is the 'non-delta details' that get sent - the result of applying the original http request, or a replay of the original http request?
http://www.prescod.net/whyhttp.html
Why is HTTP (1.1) Special?
People learning REST will probably have the reaction that all of us did
at first, why are these people trying to make HTTP (1.1) into some kind
of universal protocol? Let's start by saying that we aren't quite that
crazy. HTTP is not going to be replacing UDP for gaming or DNS for
naming etc. For legacy reasons it isn't even going to replace SMTP or
POP soon, even though it could do those jobs easily.
HTTP is general
Still, we suggest that it makes sense to build a wide range of
applications using HTTP, whether they be asynchronous, peer-to-peer,
etc. At first, you may think our HTTP-fixation is an arbitrary fetish
like a fondness for cats over dogs. This is not so. HTTP really is a
better protocol than SMTP or POP or IMAP in a very concrete sense.
HTTP fits into a class of protocols that are designed to general
purpose. Linda is a famous one. The various RPC protocols are also very
general purpose. Linda bills itself a "coordination language" -- used
for coordinating multiple software processes. Until I have a precise
definition of that term I can't say for sure whether RPC protocols and
HTTP are also coordination languages but the term seems to apply to
them. They are protocols for coordinating multiple independent software
components.
Definitions aside, the point remains: in terms of generality, HTTP has
more in common with SOAP than with SMTP. It is not just about moving
HTML pages from servers to clients.
General purpose protocol
I don't think that I can "prove" that HTTP is more general than other
protocols in a mathematically rigorous way. But I can nevertheless give
you a feeling for the generality of HTTP.
The most basic computational device is a Turing machine. A Turing
machine is driven by a program expressed as a set of states and a tape.
The tape represents some kind of storage. In the more advanced forms of
the Turing machine, you can read and write to the storage and address
the storage locations by numeric ID.
HTTP is similar. HTTP allows you to read from the storage with GET,
write to it with PUT and the addresses are URIs. Because disk space in
the real world is limited, HTTP also has DELETE. And because multiple
people will be using the system at once, there is a need for a method
that will create guaranteed-new "storage locations". This is POST. POST
is so incredibly general that you can use it for other things. But you
only absolutely need POST to deal with situations where there might be
race conditions. These primitives allow HTTP to be used as a
coordination language.
Instead of a state machine, of course, we write our HTTP programs in
general purpose programming languages like Python or C++. The web server
can act as state for the computation (though it may also do much more).
This may not seem immediately interesting because most people have grown
accustomed to using RAM and hard disks for their state. But HTTP allows
us to build distributed applications that share state through HTTP
servers. SMTP lacks equivalent "methods". POP lacks equivalent
"methods".
FTP is the closest protocol to HTTP conceptually. But really the gap
between FTP and HTTP is huge. FTP lacks the POST method. It lacks
content negotation. It lacks well-defined caching semantics. More
important, though, FTP's semantics do not allow the server to be an
active participant in the computation. HTTP very precisely defines how
the server can do complicated computations by itself. It is not just a
holder of bits -- it can embody a complex service! The web as we know it
demonstrates the extent to which it has succeeded. The Web is an
excellent, scalable, sophisticated e-commerce platform and this is
largely due to smart usage of HTTP by e-commerce providers.
HTTP is also very extensible through new headers, new methods, new URIs
and new content types. Let's concentrate on the extension of the four
main methods (GET, PUT, POST, DELETE). HTTP 1.1 defines some others.
Extensions to HTTP also define new ones (such as WebDAV). Although the
four methods are "sufficient", it is nice to have other ones for
efficiency and modeling simplicity. For instance WebDAV has a LOCK
method which could be modeled as a POST of a LOCk object. In theory the
LOCK method may be a bit more efficient and a little bit simpler to
implement.
Modeling applications in HTTP
It is possible to compose these methods into an infinite variety of
applcations. In some trivial sense you could run the web on top of SMTP
by using it as a tunnel for HTTP. But in a much more concrete sense you
could model SMTP as a series of HTTP POSTs, GETs and PUTs. The resulting
protocol would be no more complicated than SOAP and probably about as
efficient. Most people are probably more comfortable with POP (which
they probably use every day) than with SMTP, so I'll use that as an
example.
What if your "mailbox" were just a password-protected section of your
website. It would store a bunch of resources with various content types
(mostly text/plain). Your various mail clients would GET from it when
they want to update your client view. When they want to remove a message
they DELETE it. When they want to send a message they POST it to the
mailbox on someone else's server. If the other server wasn't available
then you would instead POST it to queuing intermediary. If you wanted to
update a message in the queue before it was sent you could PUT to it.
You can see how this modeling process works. You think about the things
you want to work with as resources and you apply HTTP methods to them.
One day I hope and expect that Web resource modeling will be as widely
understood as object oriented modeling.
If you were away from a proper mail client you would just browse your
mailbox using a standard web browser. Content negotation would ensure
that your mailbox "looks like" a web page when you access it from a
browser. Every mail server could easily have the functionality of
HoTMaiL (which is, after all, just an HTTP-based user interface).
Unlike SMTP, POP, FTP etc., HTTP is a protocol that you can directly
model applications in terms of. We can model all of the features of
SMTP, POP, FTP etc. in HTTP. The interesting thing is that it usually
isn't much of a conceptual stretch to do so. Just as it is typically
easy to map any data format into XML (once you get the hang of it), it
is easy to map any protocol into HTTP (once you get the hang of it).
Just as any reasonable person will ask, when they see a new data
interchange syntax: "Why couldn't you have done that as XMl", a person
could ask of a new protocol, "Why didn't you do that as HTTP." Think of
HTTP as the emerging default, quasi-universal syntax for TCP-based
protocols, as XML is the default, quasi-universal syntax for structured
data.
I say "quasi-universal" because there are limits. Just as XML isn't
really great for binary media, HTTP isn't really great for streaming
real-time media. So for those applications you should use something
else. But if your application is within HTTP's purview (i.e. structured
messaging), then you should think twice before inventing Yet Another Way
to manage connections, and manage content-negotiation and manage the
header/body split and invent yet another namespace, and figure out a new
way to handle caching etc. There are huge economies of scale in figuring
out all of these things just once for HTTP.
Versus Other Generic Protocols
So HTTP is not properly compared with most of the other Internet
protocols. It is in a totally different class of generality. It might
more relevant to compare it with Tuple-space models (Linda, JavaSpaces,
Tspaces etc.) and the RPC protocols (DCOM, SOAP RPC, etc.). How does it
compare?
Well, the tuple-space models seem to (as per the name!) require some
kind of shared environment called the tuple space. I don't see how this
can scale up to an application the size of the Web. Maybe I
misunderstand something.
HTTP's big advantage over RPC protocols (and this is another advantage
over FTP) is that its whole model is organized around addresses.
Ubiquitous, powerful, direct and indirect addressing is what made the
Web so incredibly powerful. RPC protocols hide the "addresses" of
objects in parameters. When you pass a UUID to access a UDDI TModel, you
are really addressing the thing, but because the address is hidden in a
method, you can't address that thing anywhere, such as in an XSLT
stylesheet, or an RDF assertion, or a web browser bookmark, or the
URL-line of a browser, or ...
RPC divides the world up into self-contained address spaces. This is the
antithesis of the unviversal naming used on the Web. This will cause so
many problems that I am confident predicting that RPC protocols will
fail.
HTTP Limitations
There is no doubt that HTTP has its limitations. For one thing there is
not much software out there that knows how to deal with HTTP in a
peer-to-peer or asychronous fashion. There is a lot of software out
there that claims to use HTTP but is well behind the HTTP specification.
Also, HTTP is not going to take over the universe from established
protocols with large software bases. Rather it will capture new markets
that have not yet been tapped.
Finally, there is a lot of work to do in order to standarize HTTP
solutions to common problems. For instance WebDAV isa standardization of
content management solutions in the HTTP framework. HTTPEvents is a
standardization of HTTP notifications ("asynch", "callbacks" whatever
you want to call it). There are also proposals for making HTTP more
reliable in the sense that every message gets delivered once and only
once.
"S. Mike Dierken" wrote: > > I'm not sure idempotency applies to notifications. > I thought it only applied to request/response message exchanges. > A notification is not a request to cause something to happen at the > receiver. It might be an 'http request' message format, but I'm not sure its > a 'conceptual' request. Well if each notification is a "diff" then the requrest is to please update your local copy so you are in sync with the rest of us. My point is that a) getting the same notification twice should be harmless b) it should always be possible for a client to build up the same internal state by looking at the resource and its subordinates that it would have gotten by collecting notifications > What is the effect of more than 1 identical notification messages? > If a receiver kept a count of messages, this count would be 'inaccurate' - > but that (hit counts) is not a case we consider for idempotency anyway. > If a receiver waited for a particular event - threshold crossed, etc - and > then deleted itself (stopped listening before/without deleting the > subscription) the next event probably would result in a 404 or something > (listener not found). Is this 'allowable' if notifications are idempotent? > (it'd be like two PUTs or two GETs returned an error on the second request > /because/ of the first request). That's borderline. But the subscriber is acting on behalf of a Client and so I feel it has more leeway for funny behaviour than a Server. When I say that notifications are idempotent I just mean the two things I said above. > Also what is sent in a notification? I claim, basically nothing. Even less than the HttpEvents spec says. I claim it should contain: 1. the HTTP method (Lucas suggests PUT) 2. the subscriber URI 3. the subscription URI (in case you want to unsubscribe) 4. the URI that changed (in case you want to get into sync) As an *optimization* it could also include information that would help the client to keep up without constantly pulling extra information from the server. For instance it could include a "diff" from a previous labelled version -- but the cient could discard that if it wanted and go "back to the source." It could also say "what happened" in some HTTP sense (PUT, GET, DELETE, POST) but again it could figure that stuff out just by looking at the resource. If a resource is huge and/or composite (like a website) then for the purposes of notification, another resource should be generated like a "changelog". Then you would watch just the changelog. When it changed you would look at it to see what individual web page had changed. Paul Prescod
"S. Mike Dierken" wrote: > >... > > Don't send deltas (you need sequence and reliable delivery to stay in > synch). If you watch a resource that is a collection, either send a snapshot > of the collection (which could be big - so you fragment via hyper-links like > you mentioned) or don't send any details. Sending deltas as an *optimization* sounds okay to me...they could be deltas against a once-a-day golden version so that you can miss several messages without running into problems. But the point is that you could always discard the deltas and really sync up properly if you want. > But what is the 'non-delta details' that get sent - the result of applying > the original http request, or a replay of the original http request? You have this notion of the "original http request" that I am trying to wean you from. If I fire up vi through an ssh connection to edit a document, there is no original HTTP request. There is just a change. The details that get sent would be up to the application. My only requirements on them would be that a) the client can ignore them and not lose out on anything other than performance and b) the client can receive them twice without worrying about corrupting its internal state (another problem with deltas if you aren't intelligent about saying WHAT you are applying the delta to). Paul Prescod
> > It is self evident that non-idempotent queries can't be used > > for watch expressions, because otherwise the act of performing a watch > changes > > the result. > Do you mean 'non-idempotent HTTP requests can't be used to create a > subscription'? No. > Or do you mean 'the evaluation of whether a subscription matches a > particular occurrance must not cause a non-idempotent request to be sent to > the resource that is subscribed'? Yes.
As an example of a really bizarre situation: There is a store-and-forward gateway. It has an interface for receiving messages to forward. The interface includes authentication. It is able to forward messages to recipients whose interface also includes authentication. > From: Mark Baker [mailto:distobj@...] ... > In all the funky stuff I've done with HTTP, I've *never* had to > encapsulate an HTTP message. Given that, I think it's probably safe to > say that if you're doing it, either you're doing something wrong, or > you've got some really bizarre situation (like the one Mike described > recently). > > MB
> > notifications overwrite whatever the previous state of the flag (as > held on the > > sink). So the proper method is PUT, not GET. > > Agreed, for boolean notifications. However, not all notifications are > boolean, the same way that not all resources are boolean. Sometimes a > subscription is created for more than just knowing *when* state changes. > Sometimes it's created to know *how* state changes. > > MB I'd make the argument that messages about "how" are updates, not notifications. The reason to make a distinction is just to enable divide-and-conquer -- it may be that you can solve the when and how problems more easily separately than together. ...the "how" problem, for example, might be best tackled as a version control issue. - Lucas
If notifications contain updates then they must be POSTs. This seems ugly. The agent requesting notification supplied a notification URI. It is the responsibility of the subscriber to know to what resources that notification URI corresponds. Unless we are prepared to specify a subsciption management protocol, there is no need to require that the subsciption resource be in the notification. If we care about synchronization, we should specify other HTTP methods for version management. These would be useful regardless of subscription. I think some are in WebDAV. I don't think any of the existing HTTP methods communicate what notifcation communicates. I think there are basically 3 messages, all of which have NO message bodies. CREATED /notification/path HTTP/1.1 (allowing the ability to watch for the creation of certain types of resources) CHANGED /notification/path HTTP/1.1 DELETED /notifiation/path HTTP/1.1 when there will be no more changes and there is now no accessible info about the resource. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax On Thu, 31 Jan 2002, Paul Prescod wrote: > "S. Mike Dierken" wrote: > > > > I'm not sure idempotency applies to notifications. > > I thought it only applied to request/response message exchanges. > > A notification is not a request to cause something to happen at the > > receiver. It might be an 'http request' message format, but I'm not sure its > > a 'conceptual' request. > > Well if each notification is a "diff" then the requrest is to please > update your local copy so you are in sync with the rest of us. > > My point is that > > a) getting the same notification twice should be harmless > > b) it should always be possible for a client to build up the same > internal state by looking at the resource and its subordinates that it > would have gotten by collecting notifications > > > What is the effect of more than 1 identical notification messages? > > If a receiver kept a count of messages, this count would be 'inaccurate' - > > but that (hit counts) is not a case we consider for idempotency anyway. > > If a receiver waited for a particular event - threshold crossed, etc - and > > then deleted itself (stopped listening before/without deleting the > > subscription) the next event probably would result in a 404 or something > > (listener not found). Is this 'allowable' if notifications are idempotent? > > (it'd be like two PUTs or two GETs returned an error on the second request > > /because/ of the first request). > > That's borderline. But the subscriber is acting on behalf of a Client > and so I feel it has more leeway for funny behaviour than a Server. When > I say that notifications are idempotent I just mean the two things I > said above. > > > Also what is sent in a notification? > > I claim, basically nothing. Even less than the HttpEvents spec says. I > claim it should contain: > > 1. the HTTP method (Lucas suggests PUT) > > 2. the subscriber URI > > 3. the subscription URI (in case you want to unsubscribe) > > 4. the URI that changed (in case you want to get into sync) > > As an *optimization* it could also include information that would help > the client to keep up without constantly pulling extra information from > the server. For instance it could include a "diff" from a previous > labelled version -- but the cient could discard that if it wanted and go > "back to the source." It could also say "what happened" in some HTTP > sense (PUT, GET, DELETE, POST) but again it could figure that stuff out > just by looking at the resource. > > If a resource is huge and/or composite (like a website) then for the > purposes of notification, another resource should be generated like a > "changelog". Then you would watch just the changelog. When it changed > you would look at it to see what individual web page had changed. > > Paul Prescod >
> We *could* model our resources such that all notifications are boolean. > For instance you would get a notification that a thousand page document > has changed. Then the client uses some WebDAV/DeltaV magic to get a diff > from the version it has to the version the server has. > > I like the idea of idempotent notifications because it means that the > listener could go off the network for seven hours and get "back in sync" > on the very first notification it gets, or even before it gets a > notification. So for instance if we were in a chat session and I get cut > off then my chat client could miss a bunch change notifications but sync > up whenever it wanted to. Loose coupling. Sure, but you're placing an obligation on the server and the network to ensure that the notification arrives in order to go do your "catching up". That's quite a burden. An alternative would be that the client requests a resynch when it comes back online. This would be done with a GET. Part of the request could include the last message id retrieved, and the server could then send all messages on the GET response that would get the client up to date. > So I would say that if an "event" is important enough that a client > wants to know WHAT changed, not just WHEN it changed then the event > should be reified in the server as a resource and persist for some > number of hours or days, unless deleted. How's that networking adage go? "Send as much as you can, as soon as you can". > As an *optimization*, it may make sense to have message bodies with > "diffs". But if you detected that you had missed one it would be no big > deal because you could just sync up. Right. > Can you describe an application that is better modeled with > non-idempotent notifications? All of them? 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > > We *could* model our resources such that all notifications are boolean. > > For instance you would get a notification that a thousand page document > > has changed. Then the client uses some WebDAV/DeltaV magic to get a diff > > from the version it has to the version the server has. > > > > I like the idea of idempotent notifications because it means that the > > listener could go off the network for seven hours and get "back in sync" > > on the very first notification it gets, or even before it gets a > > notification. So for instance if we were in a chat session and I get cut > > off then my chat client could miss a bunch change notifications but sync > > up whenever it wanted to. Loose coupling. > > Sure, but you're placing an obligation on the server and the network > to ensure that the notification arrives in order to go do your > "catching up". That's quite a burden. > > An alternative would be that the client requests a resynch when it > comes back online. Right, I mentioned that point: "even before it gets a notification" > ... This would be done with a GET. Part of the > request could include the last message id retrieved, and the > server could then send all messages on the GET response that > would get the client up to date. If notifications have IDs then they *are* idempotent. The client will just discard a notification with a message ID that it has already seen. > > So I would say that if an "event" is important enough that a client > > wants to know WHAT changed, not just WHEN it changed then the event > > should be reified in the server as a resource and persist for some > > number of hours or days, unless deleted. > > How's that networking adage go? "Send as much as you can, as soon as > you can". As long as it is an optimization. Paul Prescod
> If notifications have IDs then they *are* idempotent. The client will > just discard a notification with a message ID that it has already seen. Right. I thought by "idempotent" you meant in the sense of the method being used. In this case, the server only needs to use POST, not M-POST, because the client provides the context (the callback URI) in which idempotence (or lack thereof) is determined. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > > If notifications have IDs then they *are* idempotent. The client will > > just discard a notification with a message ID that it has already seen. > > Right. I thought by "idempotent" you meant in the sense of the method > being used. If the events are *logically* idempotent then why wouldn't you want to use an idempotent method? > In this case, the server only needs to use POST, not M-POST, because > the client provides the context (the callback URI) in which idempotence > (or lack thereof) is determined. M-POST, isn't that a SOAP thing? I would say PUT would be the right method. You are "PUT"ting the binary notification that "something changed". As an optimization you may include a diff of what changed. But the core semantic content of the message is idempotent. If you get it twice, ignore the second. Paul Prescod
"S. Alexander Jacobson" wrote: > > If notifications contain updates then they must be > POSTs. This seems ugly. I agree. In recent mails I've been suggesting PUT. > The agent requesting notification supplied a > notification URI. It is the responsibility of > the subscriber to know to what resources that > notification URI corresponds. Orthogonal issue. There is very little no cost in having a header with the notification URI and it might be useful for simplifying client-side state management. > Unless we are prepared to specify a subsciption > management protocol, there is no need to require > that the subsciption resource be in the > notification. We are doing somewhat of a subscription management protocol. The latest spec (from yesterday) incorporates Jeff Bone's ideas about: 1. Expiry 2. Acknowledgment from the client that it really wants to be subscribed Plus we have always said that a client may unsubscribe by DELETEing a subscription resource. > If we care about synchronization, we should > specify other HTTP methods for version management. > These would be useful regardless of subscription. > I think some are in WebDAV. Agreed. > I don't think any of the existing HTTP methods > communicate what notifcation communicates. I > think there are basically 3 messages, all of which > have NO message bodies. The message body is an important and useful *optimization*. Sending diffs is really important for performance. They just have to be set up so that even if one is "dropped" you can resync easily by going back to the subscription resource. > CREATED /notification/path HTTP/1.1 > (allowing the ability to watch for the creation of > certain types of resources) > > CHANGED /notification/path HTTP/1.1 > > DELETED /notifiation/path HTTP/1.1 > when there will be no more changes > and there is now no accessible info about the > resource. I no longer think it is important to say which of these things happened. You notify the resource of the change. Maybe you have a body that says what changed. Maybe you don't. If you don't, or it is useless because of some message that was lost earlier, then you re-sync from the data source. You say CREATED is important because if allows you the ability to watch for the creation of certain types of resources. But you could also model this as a WATCH on a query. "The list of all stock symbols." I think that a subscription could outlive a DELETEion. If the resource goes away and them comes back and then goes away, why not keep delivering notifications? Paul Prescod
On Thu, 31 Jan 2002, Paul Prescod wrote:
> > The agent requesting notification supplied a
> > notification URI. It is the responsibility of
> > the subscriber to know to what resources that
> > notification URI corresponds.
>
> Orthogonal issue. There is very little no cost in having a header with
> the notification URI and it might be useful for simplifying client-side
> state management.
The client has to do some form of state management
anyway. If the client needs the URI, it can
encode that in the notification URL.
The problem for the server is that multiple URIs
may map to the same resource. Those different
URIs may be used by different clients for various
purposes. If the server has to send a URI, it
also has to know which URI the client used to
request notification about the Resource.
That is really ugly.
> > Unless we are prepared to specify a subsciption
> > management protocol, there is no need to require
> > that the subsciption resource be in the
> > notification.
>
> We are doing somewhat of a subscription management protocol. The latest
> spec (from yesterday) incorporates Jeff Bone's ideas about:
The subscription URL should be delivered in the
response to notification. It is a huge waste to
deliver it with each notification.
Again, if the client really want it, the client
could encode it in the notification URL.
> 1. Expiry
> 2. Acknowledgment from the client that it really wants to be subscribed
>
> Plus we have always said that a client may unsubscribe by DELETEing a
> subscription resource.
The client should be able to do subscription
modifications in reply to a notification request.
In particular, some set of 40x responses to a
notification should be the equivalent of
unsubscription. e.g. if the response to a
notification is 403 FORBIDDEN, that is a strong
hint that you don't want the subscription anymore.
> > I don't think any of the existing HTTP methods
> > communicate what notifcation communicates. I
> > think there are basically 3 messages, all of which
> > have NO message bodies.
>
> The message body is an important and useful *optimization*. Sending
> diffs is really important for performance. They just have to be set up
> so that even if one is "dropped" you can resync easily by going back to
> the subscription resource.
So the notion is that the notification message may
optionally include a last update. If the content
is optional, I don't think you should really be
using PUT. Because a series of empty PUT bodies
doesn't mean that nothing has changed, only that
the server decided not to send it.
> > CREATED /notification/path HTTP/1.1
> > (allowing the ability to watch for the creation of
> > certain types of resources)
> >
> > CHANGED /notification/path HTTP/1.1
> >
> > DELETED /notifiation/path HTTP/1.1
> > when there will be no more changes
> > and there is now no accessible info about the
> > resource.
>
> I no longer think it is important to say which of these things happened.
> You notify the resource of the change. Maybe you have a body that says
> what changed. Maybe you don't. If you don't, or it is useless because of
> some message that was lost earlier, then you re-sync from the data
> source.
I think there is a difference between having an
empty body and having a NULL body.
> You say CREATED is important because if allows you the ability to watch
> for the creation of certain types of resources. But you could also model
> this as a WATCH on a query. "The list of all stock symbols."
No because then you can't watch a particular
resource.
Suppose that you are modeling the set of seats in
a theater. Suppose you want to watch the seat
next to yours:
CREATED: someone sat down in the seat (you can't
invite a friend to sit next to you)
CHANGED: the person took off her coat
CHANGED: the person she took off her shoes
DELETED: she got up and left and the seat is
now available again
(This example does not include the possibility
that the person could have no mass (be an empty
body), but other applications have that
possibility)
> I think that a subscription could outlive a DELETEion. If the resource
> goes away and them comes back and then goes away, why not keep
> delivering notifications?
ok. but I think you still want deletion.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > The client has to do some form of state management > anyway. If the client needs the URI, it can > encode that in the notification URL. I'm trying to preserve the ability for the notification URL to be mailto:paul@... . > The problem for the server is that multiple URIs > may map to the same resource. Those different > URIs may be used by different clients for various > purposes. If the server has to send a URI, it > also has to know which URI the client used to > request notification about the Resource. > That is really ugly. Does it? Or does it just need to send *a* URI? As long as the client can retrieve the changed state from the URI, maybe it doesn't care if it is "the same" URI. I have to think that through more when I have time. >... > The subscription URL should be delivered in the > response to notification. It is a huge waste to > deliver it with each notification. Same reasoning as above. Let's say you notice you're getting random, annoying notifications from some service. Maybe all else has failed and it is up to a human being to cancel the notifications. The header is equivalent to this: > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > Again, if the client really want it, the client > could encode it in the notification URL. That' going to be one really ugly URL! Anyhow, my three concerns are as above: 1. The software may not ask for it but after it gets accidentally uninstalled, whoever needs to turn off the notifications needs it. 2. The subscriber may be just be an email address in which case it isn't possible to arbitrarily munge the subscriber URI. >... > The client should be able to do subscription > modifications in reply to a notification request. > > In particular, some set of 40x responses to a > notification should be the equivalent of > unsubscription. e.g. if the response to a > notification is 403 FORBIDDEN, that is a strong > hint that you don't want the subscription anymore. Actually, right now it works the opposite way. If the subscriber doesn't respond: "Yes, please keep sending me crap" then the sender must quit. Maybe that obviates point "1" above. >... > So the notion is that the notification message may > optionally include a last update. If the content > is optional, I don't think you should really be > using PUT. My point is that the semantic content of the message is merely: "something changed". It is a PUT of a boolean. Everything else is up to the application and should be JUST optimization. > ... Because a series of empty PUT bodies > doesn't mean that nothing has changed, only that > the server decided not to send it. I think any particular application would either ALWAYS send a diff (or a message indicating why it didn't send a diff) or NEVER send a diff. The body is optional at the notification spec level. Some apps may bother with diffs and some may not. >... > I think there is a difference between having an > empty body and having a NULL body. I want to leave the structure of the body entirely up to the application, as HTTP does. I would just put constraints on its semantics (as HTTP does). 1. A notification should not send information that cannot be retrieved otherwise (everything other than the boolean is considered "optimization"). 2. It must not be possible for a client to get confused if it misses a message or gets one twice. >... > Suppose that you are modeling the set of seats in > a theater. Suppose you want to watch the seat > next to yours: > > CREATED: someone sat down in the seat (you can't > invite a friend to sit next to you) > CHANGED: the person took off her coat > CHANGED: the person she took off her shoes > DELETED: she got up and left and the seat is > now available again My model is that you get a notification that something happened in the seat next to you. You look. If there is someone there and there wasn't before, then it was CREATEd. If there was someone there before and there isn't now, it was DELETEd. If the value changed it was CHANGED. If it is vital to know that someone sat down and THEN they took off their coat and THEN they took off their shoes and THEN they left then you reify that on the server. http://www.myseat.com/seat/11213/event_1 = CREATED http://www.myseat.com/seat/11213/event_2 = CHANGED http://www.myseat.com/seat/11213/event_3 = CHANGED http://www.myseat.com/seat/11213/event_4 = DELETED The list of all such events is available at: http://www.myseat.com/seat/11213/events If a customer want the detailed events, they can watch this. If you don't care about the order of events, you just watch the seat. If there are twenty people who care about this seat and some of them are off the network for a time then they can all get back in sync by looking at that URI. Because it is necessary to handle this circumstance where clients go offine and come back on, it is necessary that messages be essentially irrelevant except for their timing. That's why I don't want to standardize any indication of HOW something changed. A particular application can do this *as an optimization* for clients who happen to have always-on connections. Paul Prescod
> If the events are *logically* idempotent then why wouldn't you want to > use an idempotent method? An idempotent POST != an idempotent PUT. This goes back to the meaning of PUT vs. POST. If you assume that these notifications carry no information, which I believe you've been doing, then I could understand why you'd see them as equivalent. But if you accept my "optimization" mentioned earlier, that the body should carry some representation of the change, then those representations mean different things when done with PUT or POST. > > In this case, the server only needs to use POST, not M-POST, because > > the client provides the context (the callback URI) in which idempotence > > (or lack thereof) is determined. > > M-POST, isn't that a SOAP thing? No, it's from RFC 2774. It's what you were trying to do with RPOST earlier. > I would say PUT would be the right method. You are "PUT"ting the binary > notification that "something changed". As an optimization you may > include a diff of what changed. But the core semantic content of the > message is idempotent. If you get it twice, ignore the second. PUT is *a* right method, but so is POST. It depends on the app, and on what the subscriber wants. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > I don't think any of the existing HTTP methods > communicate what notifcation communicates. I > think there are basically 3 messages, all of which > have NO message bodies. > > CREATED /notification/path HTTP/1.1 > (allowing the ability to watch for the creation of > certain types of resources) > > CHANGED /notification/path HTTP/1.1 > > DELETED /notifiation/path HTTP/1.1 > when there will be no more changes > and there is now no accessible info about the > resource. > I see six possible messages - only some of which might make sense with Web REST. They are: create, read, update, delete, add and remove. The last two - add and remove - apply to collections. At first I thought 'create' might only apply to a type-based or class-based system, but with the Web, you can reference instances outside the scope of their lifetime (which is wicked cool). So watching for the create of a particular resource does make sense. If you want to do type-based stuff - like watching for a new resource of a certain type - you would model the type as a collection of all instances and look for 'add'. So... I concur with Alex about notification messages identifying the type of change made - but I would like all six noted here. Paul wants only 'changed', but I see little extra cost to identifying the type of change and I do see cost using further messages to identify the type of change. I'm thinking of pub/sub with many many listeners - you'd get an 'implosion' of 'was that change a delete or not?' If listeners almost never care or try to find out, then it's not as big a deal. Another thing, while I'm up here in the ivory tower, since I would like a notification for 'read', that wouldn't make sense via a 'change' notification. (The reason I want a 'read' is that when coupled with a response status of 'security error' you can detect security issues and stuff. And I know that non-http based modifications don't have these concepts, but they can be mapped.)
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > The problem for the server is that multiple URIs > may map to the same resource. Those different > URIs may be used by different clients for various > purposes. If the server has to send a URI, it > also has to know which URI the client used to > request notification about the Resource. > That is really ugly. > Multiple URI mappings is a very important situation and any notification spec should describe the expected behavior. I doubt that mandating that all URI mappings receive the event will fly - but that would be the easiest for the clients.
Mark Baker wrote: > >...[M-POST] > > No, it's from RFC 2774. It's what you were trying to do with RPOST > earlier. Not according to grep. http://www.ietf.org/rfc/rfc2774.txt But anyhow, I get your point. M-POST is some kind of reliable post with a message ID. >... > PUT is *a* right method, but so is POST. It depends on the app, and > on what the subscriber wants. Are you deliberately avoiding examples? Would you also say that some times DELETE is an appropriate notification? Is the right method chosen at the application level or should the client TELL the server what it wants the server to do in a standardized way? Paul Prescod
"S. Mike Dierken" wrote: > > ... > > So... I concur with Alex about notification messages identifying the type of > change made - but I would like all six noted here. > Paul wants only 'changed', but I see little extra cost to identifying the > type of change and I do see cost using further messages to identify the type > of change. I'm thinking of pub/sub with many many listeners - you'd get an > 'implosion' of 'was that change a delete or not?' Fine. So you admit that it is an optimization. All I want to do is leave the precise details of the optimization to the application. If it wants to send Unix-format diffs, then it can. If it wants to have six event types, then it can. If it wants twenty event types, then it can. All I ask is that the information about what happened also exist in some form on the web server so that people who miss a message can get caught up. > ... If listeners almost never > care or try to find out, then it's not as big a deal. > Another thing, while I'm up here in the ivory tower, since I would like a > notification for 'read', that wouldn't make sense via a 'change' > notification. (The reason I want a 'read' is that when coupled with a > response status of 'security error' you can detect security issues and > stuff. And I know that non-http based modifications don't have these > concepts, but they can be mapped.) You could do a regular CHANGE watch on the file that logs READs. Then if you miss a notification you can always get caught up by reading the READ-logfile. If the only place that information is stored is in the notification then one lost notification and you won't know that some hacker broke into your system. As an optimization, notifications about the logfile could of course include a summary of what happened. The client would only resynch from the actual logfile resource if it realized that it missed a notification. Paul Prescod
> So... I concur with Alex about notification messages identifying the type of > change made - but I would like all six noted here. > Paul wants only 'changed', but I see little extra cost to identifying the My objection to communicating the type of change is that it's counter to what WATCH means. WATCH means "Watch for change of state". There are *many* ways in which state may change, and none of those should matter for WATCH. All that matters is what the change is. Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE. CREATE and DELETE can be determined by subscribing to a CHANGE of the container of the resource in question. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > ... > > Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE. CREATE > and DELETE can be determined by subscribing to a CHANGE of the > container of the resource in question. Would you not say that the deletion of an object is a change of the object? Before it returned 200 and a message body, now it returns 404 and an error report? And vice versa? Paul Prescod
> > > > No, it's from RFC 2774. It's what you were trying to do with RPOST > > earlier. > > Not according to grep. http://www.ietf.org/rfc/rfc2774.txt That's because it defines the "M-" prefix that can be used with any HTTP method. > But anyhow, I get your point. M-POST is some kind of reliable post with > a message ID. Not exactly, but it doesn't matter here. > > PUT is *a* right method, but so is POST. It depends on the app, and > > on what the subscriber wants. > > Are you deliberately avoiding examples? Yes, because they're a pain in the ass to describe. Ok, so without going into detail... Consider two stock quote services. One pumps out absolute values, and the other pumps out deltas. The former could notify with PUT, and the latter could notify with POST. > Would you also say that some times DELETE is an appropriate > notification? If that's the way the subscriber wants to know about something, I suppose so. But there's no body, and a successful notification can only happen once. I can't think of a case where I'd need to use it. > Is the right method chosen at the application level or should the client > TELL the server what it wants the server to do in a standardized way? Not sure what the former means, but the latter is what I had in mind (and what we've implemented). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE. CREATE > > and DELETE can be determined by subscribing to a CHANGE of the > > container of the resource in question. > > Would you not say that the deletion of an object is a change of the > object? This is one of those "axiom of choice" things. You can see the world that way, or you can use the container view. Personally, we've gone with the container view (for the most part). We don't have enough experience with it yet to know if that's the right thing or not, but I have confidence in it. So no, we don't count the deletion of a resource as a change of state of that resource. But when the client goes to catch up on state, it will find out. Until then, it will just notice that the state hasn't updated in a while (like a stale cache). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Thu, 31 Jan 2002, S. Mike Dierken wrote: > of change. I'm thinking of pub/sub with many many listeners - you'd get an > 'implosion' of 'was that change a delete or not?' If listeners almost never > care or try to find out, then it's not as big a deal. Good point! It also means there is a tradeoff between message size and callbacks. In particular, it would be nice if the notifier can asssign different clients different URLs at which to review the current state of the resource. But, it is really an optimization. The spec. should allow but not require the notification agent to send "preemptive redirects" -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 31 Jan 2002, Paul Prescod wrote: > > The client has to do some form of state management > > anyway. If the client needs the URI, it can > > encode that in the notification URL. > > I'm trying to preserve the ability for the notification URL to be > mailto:paul@... . !!??? NOT USE HTTP!? If you're doing that then you should use the existing standards for listservs. I don't know the standard, but I do know that Pine says that mail from Yahoo contains "List Management Information" and that if I click on it, I get the opportunity to click on an UNSUB URL. > > The problem for the server is that multiple URIs > > may map to the same resource. Those different > > URIs may be used by different clients for various > > purposes. If the server has to send a URI, it > > also has to know which URI the client used to > > request notification about the Resource. > > That is really ugly. > > Does it? Or does it just need to send *a* URI? As long as the client can > retrieve the changed state from the URI, maybe it doesn't care if it is > "the same" URI. I have to think that through more when I have time. It matters because the resource may have different access protections when accessed from different URIs or suppose that the client subscribed to an HTTP URI, but the notifier supplies an HTTPS URI and the client can't do HTTPS. > > The subscription URL should be delivered in the > > response to notification. It is a huge waste to > > deliver it with each notification. > > Same reasoning as above. Let's say you notice you're getting random, > annoying notifications from some service. Maybe all else has failed and > it is up to a human being to cancel the notifications. The header is > equivalent to this: > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com See above re the listserv standard. But, I think for this standard, if you are using an asynch protocol, the client should just be required to refresh subscription periodically. > > Again, if the client really want it, the client > > could encode it in the notification URL. > > That' going to be one really ugly URL! Its up to the client! The client could just maintain a private map from notification URLs to a resource and subscription URLs. It would be prettier but would require more client side state. > Anyhow, my three concerns are as > above: > > 1. The software may not ask for it but after it gets accidentally > uninstalled, whoever needs to turn off the notifications needs it. Then, it should be optional. In high frequency notifications, you don't need it in every message. > 2. The subscriber may be just be an email address in which case it > isn't possible to arbitrarily munge the subscriber URI. * The subscriber can generate 1 email address per notification URL * The convention for email notification should be different. In particular, the URI that changed should appear in the subject: header * Email should include a reply-to/from address... > > The client should be able to do subscription > > modifications in reply to a notification request. > > > > In particular, some set of 40x responses to a > > notification should be the equivalent of > > unsubscription. e.g. if the response to a > > notification is 403 FORBIDDEN, that is a strong > > hint that you don't want the subscription anymore. > > Actually, right now it works the opposite way. If the subscriber doesn't > respond: "Yes, please keep sending me crap" then the sender must quit. > Maybe that obviates point "1" above. That won't work well for email unless you require the recipient to reply to each email. > > ... Because a series of empty PUT bodies > > doesn't mean that nothing has changed, only that > > the server decided not to send it. > > I think any particular application would either ALWAYS send a diff (or a > message indicating why it didn't send a diff) or NEVER send a diff. The > body is optional at the notification spec level. Some apps may bother > with diffs and some may not. But you need to require that at the protocol level which is just wierd. > Because it is necessary to handle this circumstance where clients go > offine and come back on, it is necessary that messages be essentially > irrelevant except for their timing. That's why I don't want to > standardize any indication of HOW something changed. A particular > application can do this *as an optimization* for clients who happen to > have always-on connections. Ok. 1. You can require that HTTP messages always represent change since the last successful delivery. (the server then need to track when the last successful delivery was) 2. use an email like protocol and have every message contain the date at which the message was sent. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul, good stuff. Some comments; > The various RPC protocols are also very > general purpose. This is like saying that Ethernet is general purpose. It's true, but not too useful. RPC is a lower layer than HTTP because it defines no application semantics, leaving them for the "API" to define. Linda, like HTTP and FTP and NNTP, defines the methods. So you've got an application layer contract - a coordination language - between endpoints a priori. > Linda bills itself a "coordination language" -- used > for coordinating multiple software processes. Until I have a precise > definition of that term I can't say for sure whether RPC protocols and > HTTP are also coordination languages but the term seems to apply to > them. "RPC" in general isn't. But any coordination language can be built on top with RPC methods. HTTP is a coordination language. > Definitions aside, the point remains: in terms of generality, HTTP has > more in common with SOAP than with SMTP. It is not just about moving > HTML pages from servers to clients. I'd say it's the other way around. SMTP "DATA" has a precise meaning, not unlike POST. SOAP defines no meanings; you can either build them on top (RPC), or you can inherit them from the underlying protocol. > HTTP is similar. HTTP allows you to read from the storage with GET, > write to it with PUT and the addresses are URIs. Because disk space in > the real world is limited, HTTP also has DELETE. And because multiple > people will be using the system at once, there is a need for a method > that will create guaranteed-new "storage locations". I'd say that POST was the movement of the tape. PUT creates new locations. > FTP is the closest protocol to HTTP conceptually. But really the gap I think NNTP is probably closest. It has POST (that's where HTTP's POST came from), a basic get (ARTICLE), and a very specific type of put (for setting read messages). > important, though, FTP's semantics do not allow the server to be an > active participant in the computation. HTTP very precisely defines how > the server can do complicated computations by itself. It is not just a > holder of bits -- it can embody a complex service! You mean the app here I guess. You should distinguish between the web server and the web app. > efficiency and modeling simplicity. For instance WebDAV has a LOCK > method which could be modeled as a POST of a LOCk object. In theory the PUT actually, since it is defined absolutely. > You can see how this modeling process works. You think about the things > you want to work with as resources and you apply HTTP methods to them. > One day I hope and expect that Web resource modeling will be as widely > understood as object oriented modeling. Indeed, they are already closely related. Component based modelling is even closer because you work from a generic containment based API. > I say "quasi-universal" because there are limits. Just as XML isn't > really great for binary media, HTTP isn't really great for streaming > real-time media. So for those applications you should use something > else. (though perhaps with HTTP's application semantics) > There is no doubt that HTTP has its limitations. For one thing there is > not much software out there that knows how to deal with HTTP in a > peer-to-peer or asychronous fashion. I don't know what that means. > There is a lot of software out > there that claims to use HTTP but is well behind the HTTP specification. > Also, HTTP is not going to take over the universe from established > protocols with large software bases ... anytime soon. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Thu, 31 Jan 2002, Mark Baker wrote: > > Would you not say that the deletion of an object is a change of the > > object? > > This is one of those "axiom of choice" things. You can see the world > that way, or you can use the container view. But, suppose I just want to watch the seat to my right. I don't want to watch the whole theater for people sitting and filter it to find the seat to my right. I just want to watch the seat to my right. How do I do that in the container view? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul, You refer to IMAP at the beginning of the article but don't explain why it is better than HTTP. IMAP has lots of features that HTTP lacks. It has methods that correspond to GET, POST, PUT. It has a better representation of the notion of containers. It has search. ODBC/SQL is also nice from the perspective you give. The problem is that it does not specify a way of passing the types of objects!!!!! Regarding universality. I would say that much of the universality of a communication protocol is a shared ontology aka a shared list of MIME content-types. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax On Thu, 31 Jan 2002, Mark Baker wrote: > Paul, good stuff. Some comments; > > > The various RPC protocols are also very > > general purpose. > > This is like saying that Ethernet is general purpose. It's true, but > not too useful. RPC is a lower layer than HTTP because it defines no > application semantics, leaving them for the "API" to define. > > Linda, like HTTP and FTP and NNTP, defines the methods. So you've > got an application layer contract - a coordination language - > between endpoints a priori. > > > Linda bills itself a "coordination language" -- used > > for coordinating multiple software processes. Until I have a precise > > definition of that term I can't say for sure whether RPC protocols and > > HTTP are also coordination languages but the term seems to apply to > > them. > > "RPC" in general isn't. But any coordination language can be built > on top with RPC methods. HTTP is a coordination language. > > > Definitions aside, the point remains: in terms of generality, HTTP has > > more in common with SOAP than with SMTP. It is not just about moving > > HTML pages from servers to clients. > > I'd say it's the other way around. SMTP "DATA" has a precise > meaning, not unlike POST. SOAP defines no meanings; you can either > build them on top (RPC), or you can inherit them from the underlying > protocol. > > > HTTP is similar. HTTP allows you to read from the storage with GET, > > write to it with PUT and the addresses are URIs. Because disk space in > > the real world is limited, HTTP also has DELETE. And because multiple > > people will be using the system at once, there is a need for a method > > that will create guaranteed-new "storage locations". > > I'd say that POST was the movement of the tape. PUT creates new > locations. > > > FTP is the closest protocol to HTTP conceptually. But really the gap > > I think NNTP is probably closest. It has POST (that's where HTTP's > POST came from), a basic get (ARTICLE), and a very specific type of > put (for setting read messages). > > > important, though, FTP's semantics do not allow the server to be an > > active participant in the computation. HTTP very precisely defines how > > the server can do complicated computations by itself. It is not just a > > holder of bits -- it can embody a complex service! > > You mean the app here I guess. You should distinguish between the > web server and the web app. > > > efficiency and modeling simplicity. For instance WebDAV has a LOCK > > method which could be modeled as a POST of a LOCk object. In theory the > > PUT actually, since it is defined absolutely. > > > You can see how this modeling process works. You think about the things > > you want to work with as resources and you apply HTTP methods to them. > > One day I hope and expect that Web resource modeling will be as widely > > understood as object oriented modeling. > > Indeed, they are already closely related. Component based modelling is > even closer because you work from a generic containment based API. > > > I say "quasi-universal" because there are limits. Just as XML isn't > > really great for binary media, HTTP isn't really great for streaming > > real-time media. So for those applications you should use something > > else. > > (though perhaps with HTTP's application semantics) > > > There is no doubt that HTTP has its limitations. For one thing there is > > not much software out there that knows how to deal with HTTP in a > > peer-to-peer or asychronous fashion. > > I don't know what that means. > > > There is a lot of software out > > there that claims to use HTTP but is well behind the HTTP specification. > > Also, HTTP is not going to take over the universe from established > > protocols with large software bases > > ... anytime soon. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com >
"S. Alexander Jacobson" wrote: > > Paul, > > You refer to IMAP at the beginning of the article > but don't explain why it is better than HTTP. > > IMAP has lots of features that HTTP lacks. It has > methods that correspond to GET, POST, PUT. It has > a better representation of the notion of > containers. It has search. Okay, but how much work would it be to define a protocol with all of IMAPs features that conforms to the HTTP syntax and model versus vice versa? Adding "search" to HTTP would be trivial. Would adding URI handling and content-negotiation to IMAP be similarly trivial? > ODBC/SQL is also nice from the perspective you > give. The problem is that it does not specify a > way of passing the types of objects!!!!! Also not very well geared for large scale, loosely coupled computing. > Regarding universality. I would say that much of > the universality of a communication protocol is a > shared ontology aka a shared list of MIME > content-types. I agree that this is necessary for an application. But I wouldn't say that it is a benefit of the protocol itself. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > "S. Mike Dierken" wrote: > > > > ... > > > > So... I concur with Alex about notification messages identifying the type of > > change made - but I would like all six noted here. > > Paul wants only 'changed', but I see little extra cost to identifying the > > type of change and I do see cost using further messages to identify the type > > of change. I'm thinking of pub/sub with many many listeners - you'd get an > > 'implosion' of 'was that change a delete or not?' > > Fine. So you admit that it is an optimization. All I want to do is leave > the precise details of the optimization to the application. If it wants > to send Unix-format diffs, then it can. If it wants to have six event > types, then it can. If it wants twenty event types, then it can. All I > ask is that the information about what happened also exist in some form > on the web server so that people who miss a message can get caught up. > I don't mean the details in the body, I mean (from Alex's example) the method used for the notification. Even with no details about the current or changed values of the the resource, I would like to know what type of operation occurred. "Having information about what happened on the web server" - the web server would have the results of applying what happned, but it wouldn't have a record of what happened. It wouldn't (in general) have an audit trail - like 'paul edited this file at 12:00am with vi'. It would have 'the file says "hello world"'. Also, I don't want 'twenty event types', I only want HTTP referenceable 'event types' - a mapping of what occurred into http state transition operations. Having 'twenty event types' is analagous to having twenty http methods. Yes, I know the resource could have been changed through some other means than http - but the subscription and notifications are expressed in terms of http, so the notification should be /fully/ expresed in terms of http. > > ... If listeners almost never > > care or try to find out, then it's not as big a deal. > > Another thing, while I'm up here in the ivory tower, since I would like a > > notification for 'read', that wouldn't make sense via a 'change' > > notification. (The reason I want a 'read' is that when coupled with a > > response status of 'security error' you can detect security issues and > > stuff. And I know that non-http based modifications don't have these > > concepts, but they can be mapped.) > > You could do a regular CHANGE watch on the file that logs READs. Then if > you miss a notification you can always get caught up by reading the > READ-logfile. If the only place that information is stored is in the > notification then one lost notification and you won't know that some > hacker broke into your system. If you don't have 'reliable' delivery. Watching a file that contains READ occurrances is fine - but I would like to declare that in the subscription in a standardized way (WATCH /foo/logins method=READ) rather than a URI up to application definition (WATCH /foo/logins/all_reads).
"S. Mike Dierken" wrote: > >... > I don't mean the details in the body, I mean (from Alex's example) the > method used for the notification. I think that there are strong backwards-compatibility forces that argue in favour of using standard HTTP methods. But actually I'm willing to allow the application to use whatever methods (standard or extension) it wants. > Even with no details about the current or changed values of the the > resource, I would like to know what type of operation occurred. You *might* like to know. But is it worth complicating the specification? > "Having information about what happened on the web server" - the web server > would have the results of applying what happned, but it wouldn't have a > record of what happened. It wouldn't (in general) have an audit trail - like > 'paul edited this file at 12:00am with vi'. It would have 'the file says > "hello world"'. If the audit trail is important then the server should have a resource representing the audit trail. If the audit trail is NOT important then why do notification clients care about it? I'm a hardliner on this principle that there should be nothing in the notification that is not just a summary of information available on the site. > Also, I don't want 'twenty event types', I only want HTTP referenceable > 'event types' - a mapping of what occurred into http state transition > operations. Having 'twenty event types' is analagous to having twenty http > methods. I am not convinced that the basic HTTP methods are automatically the set of event types all applications would like. >... > If you don't have 'reliable' delivery. I think that part of the genius of HTTP is loose binding. And part of that is presuming that you don't have anything more reliable than TCP. > Watching a file that contains READ occurrances is fine - but I would like to > declare that in the subscription in a standardized way (WATCH /foo/logins > method=READ) rather than a URI up to application definition (WATCH > /foo/logins/all_reads). And some other user is going to want to watch READ occurrences FROM a particular range of IP addresses. We either need to define a really hairy, Turing-complete filter language or we need to leave it up to the application. I claim that the "HTTP solution" is to leave it up to the application to do with resource modeling. Now why is your seemingly reasonable request any different in kind, not just degree, from the guy who wants to filter by IP address or time of day or content-type or ... That content-type example is particularly interesting because it is purely in the domain of HTTP so it falls into the same category as the method. Should people be able to filter on content-type as well as method? What about filtering on Host:. etc. etc. Just do it with the URI and be done with it! Reformulating queries and filters as URIs is one of the most brilliant things about the Web and I want to emulate it. Paul Prescod
I've unfortunately had to tune out the last couple of days due to "real" work, looks like there's been a significant amount of consensus building. Would someone (Paul, Alex, Mike, anyone?) mind summarizing the current state-of-consensus? This would probably be useful anyway to ensure everyone's on the same page, always a challenge. ;-) jb
Mostly we talk about the things that we don't have consensus on.
I've done some major cleanups on the spec at
* http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents
Alex has almost talked me into removing the "Watched-URI" and
"Subscription-URI" headers.
Lucas more or less talked me into removing the Events header.
Mike still likes something like the Events header but I'm convinced it
is just extra junk.
Mark convinced me that the notification should be done using whatever
METHOD the application wants. POST most of the time, PUT occasionally,
maybe NOTIFY if they want to be very explicit...
I added a variants of your ideas on Expiration and Subscription
cancellation.
It occurs to me now that there is nothing to prevent man-in-the-middle
attacks ("Here's your stock price Mr. Gates!") but I don't think that's
our responsibility. They can use signing and SSL.
I've borrowed Lucas' philosophy on the idempotency of notifications.
(see the spec)
Somebody needs to think through the SMTP and the Query param bindings.
I've clarified my thoughts on how to handle notifications for
collections. Collections are just documents that happen to contain URIs
to other documents. Just hang a WATCH on that document.
I've also clarified my thoughts on message bodies. A notification's only
responsibility is to report that something changed. It is totally about
temporality. It's the secret spy-code where the phone rings twice with
no message.
The message body is ONLY a HINT about what changed. It isn't the
"payload" in any sense. If it is important (e.g. a msg in a chat
session) then it should be a first class resource on the SERVER so that
disconnected clients can "get caught up" even if they missed one or all
of the messages. I hate using services where you have to ask people
"what did I miss while my connection was down." I think that's totally
against REST. On the other hand, there are important optimizations you
can do if you allow message bodies so it is allowed only as an
optimization.
Paul Prescod
I have gone through the language regarding watch expiration and have
the following comments.
* Dates may not be the only, or even the most, important semantic for
expirations. The most obvious exception is a request for one single
notification. A usecase for one-shot notifications is a user
requesting a resource that is not yet available. Another possible
exception is a pay-per-use magazine subscription, where a user buys
twelve monthly updates. I suggest that "Requested-Expiration" be
renamed "Requested-Expiration-Date" and second expiration header named
"Requested-Expiration-Count" be added. Finally, there is a third
possible semantic that is probably the default case: "do this watch
for as long as you feel like".
* The prefix "Requested-" is redundant. Better wording would be
"Expiration-Date" and "Expiration-Count".
* If a publisher rejects a watch request because of an unsupported expiration
setting (such as a date too far in the future or a count beyond what has been
paid for), the requester should be able to diagnose the problem. There should
be a return status code for "Invalid value for requested expiration". Because
new global HTTP status codes are undesirable, possible candidates from existing
status codes are:
"417" ; Section 10.4.18: Expectation Failed
"412" ; Section 10.4.13: Precondition Failed
"409" ; Section 10.4.10: Conflict
None of these is ideal. However, 417 brings up the possibility of
_not_ using a new header dedicated to expiration, because an expect
header already exists to support the need:
Expect: Expiration;date=Jan 1, 2003
Expect: Expiration;count=12
Expect: Expiration;adhoc
Unfortunately the 417 status code indicates that the expiration
header is not supported rather than that the expiration value was
unacceptable. Are there solutions within RFC 2616?
The 412 status code is a fairly good match, though I don't quite
understand it. Here is the definition:
10.4.13 412 Precondition Failed
The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This response
code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended.
Placing preconditions sounds like just the right thing, but the
problem in this case would have nothing to do with getting the wrong
resource.
The 409 status code is IMO the best match:
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict
and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required. Conflicts are most likely to occur
in response to a PUT request. For
example, if versioning were being used and the entity being PUT
included changes to a resource which conflict with those made by an
earlier (third-party) request, the server might use the 409 response
to indicate that it can't complete the request. In this case, the
response entity would likely contain a list of the differences
between the two versions in a format defined by the response
Content-Type.
This is a fairly good match, so I would adopt it.
* The "subscription-expiration" header is required. Since it
is reasonable that many requests will be on a "good enough" basis
("do the watch for as long as is feasible"), I suggest that this be
the default value. If there is a default value then there is no need
to have an expiration request header be a MUST.
* I believe that this language overspecifies: "The client MAY renew
the subscription before this time. If it does not, the server MAY stop
sending notifications after that time. The server MAY also remove the
Subscription URI." This behavior should be left to the implementation.
* There is no need to assume that the above list of types of expiration is
exhaustive. The specification should allow for extension.
Putting all the above together, I propose that the following text:
"Expiration: The response to the Subscription MUST include a header
called "Subscription-Expiration". This indicates the time that the
subscription expires. The client MAY renew the subscription before
this time. If it does not, the server MAY stop sending notifications
after that time. The server MAY also remove the Subscription URI."
Be changed to the following:
Expiration: The response to the Subscription MAY include a header
called "Subscription-Expiration". The expiration may take any of the
following forms:
Expect: Expiration;date=Jan 1, 2003
Expect: Expiration;count=12
Expect: Expiration;adhoc
Expect: Expiration;extension-field
extension-field = token [ "=" ( token | quoted-string ) ]
In the case of Expiration;date, the field value is an HTTP-date, as
described in section 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
In the case of Expiration;count, the field value is an unsigned
integer.
In the case of Expiration;adhoc, the server may cease performing the
watch at any time. If the request does not specify an expiration, a
server MUST use an expiration setting equivalent to Expiration;adhoc.
It is expected that servers will continue performing an
Expiration;adhoc watch for as long as is practically feasible.
All responses to the watch request that are rejected for reasons of
unacceptable expiration field values MUST use status code 409 (Conflict).
- Lucas
Paul Prescod wrote:
> I've done some major cleanups on the spec at
>
> * http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents
Even better. Taking a look now.
> Alex has almost talked me into removing the "Watched-URI" and
> "Subscription-URI" headers.
So what takes their place? Do we reify subscriptions or not? (Looking at
the spec now, answer's probably in there.)
> It occurs to me now that there is nothing to prevent man-in-the-middle
> attacks ("Here's your stock price Mr. Gates!") but I don't think that's
> our responsibility. They can use signing and SSL.
I think end-to-end security has to be the application's responsibility.
jb
Thanks for your comments and ideas. Overall I think they are good.
Lucas Gonze wrote:
>
> I have gone through the language regarding watch expiration and have
> the following comments.
>
> * Dates may not be the only, or even the most, important semantic for
> expirations. The most obvious exception is a request for one single
> notification. A usecase for one-shot notifications is a user
> requesting a resource that is not yet available. Another possible
> exception is a pay-per-use magazine subscription, where a user buys
> twelve monthly updates. I suggest that "Requested-Expiration" be
> renamed "Requested-Expiration-Date" and second expiration header named
> "Requested-Expiration-Count" be added. Finally, there is a third
> possible semantic that is probably the default case: "do this watch
> for as long as you feel like".
Okay, of course expiration counts should go both ways. The client should
request one and the server should say what it decided upon.
> * The prefix "Requested-" is redundant. Better wording would be
> "Expiration-Date" and "Expiration-Count".
But it is really just a request (or expectation). Your idea of using
Expect: is good.
> * If a publisher rejects a watch request because of an unsupported expiration
> setting (such as a date too far in the future or a count beyond what has been
> paid for), the requester should be able to diagnose the problem.
My sense was that it wouldn't be an exception, the server would just
substitute what it really had. Like if you ask to read() 1000 bytes but
there are only 500 left, I get 500 back.
I'm worried about negotiation round trips. "Gimme this. No! Okay this.
No! Okay this. No!" Why not just have the server tell the client what it
can have. The client can cancel it if it isn't happy.
Plus, HTTP (surprisingly!) doesn't really standardize how to report
which expectation wasn't met. So how would you figure it out.
Is there anything seriously wrong with failing silently? The client can
check what it got against what it requested and puke if it wants or else
just take what it got.
Maybe there should be a Prefer: header that has the same syntax as
Expect:.
>...
> The 409 status code is IMO the best match:
I think that we need to figure out the issue above before we choose a
response code.
I didn't really understand why you disliked 417, though:
> Unfortunately the 417 status code indicates that the expiration
> header is not supported rather than that the expiration value was
> unacceptable.
I think you misunderstood 14.20: " The server MUST respond with a 417
(Expectation Failed) status if any of the expectations cannot be met
..."
That seems perfect.
>...
> * The "subscription-expiration" header is required. Since it
> is reasonable that many requests will be on a "good enough" basis
> ("do the watch for as long as is feasible"), I suggest that this be
> the default value. If there is a default value then there is no need
> to have an expiration request header be a MUST.
It isn't a MUST. It's a MAY in the spec as it is:
"The message MAY contain a header called "Requested-Expiration"."
> * I believe that this language overspecifies: "The client MAY renew
> the subscription before this time. If it does not, the server MAY stop
> sending notifications after that time. The server MAY also remove the
> Subscription URI." This behavior should be left to the implementation.
Debatable...what's the point of standardizing the headers if we don't
standardize the associated behaviour?
>...
> Expiration: The response to the Subscription MAY include a header
> called "Subscription-Expiration".
Just one? I might want a year or twelve issues. Whichever comes first.
>...
> In the case of Expiration;adhoc, the server may cease performing the
> watch at any time.
I would say that the Server needs to report its policy in the response.
i.e. One Month, 12 requests, etc. Otherwise, how will the client know
when it is time to renew?
Paul Prescod
Jeff Bone wrote: > > ... > > > Alex has almost talked me into removing the "Watched-URI" and > > "Subscription-URI" headers. > > So what takes their place? Do we reify subscriptions or not? (Looking at > the spec now, answer's probably in there.) I think we always intended to reify subscriptions. The question is whether we redundantly inform the client in notifications: a) what URI it is being notified about b) what subscription caused the notification He has some good arguments why we don't have to do that. The client can have a mapping from subscriber URIs to watches and subscriptions. It could also munge them into the subscriber URI itself. So the extra bytes are kind of a waste. Plus they are redundant and could be confusing if the client subscribed under one URI and gets a notification about an alternate URI for the same resource. But at a deep level I hate the idea of inscrutable bytes arriving from some remote source without telling me WHY they are arriving or HOW I would stop them. That's why I wanted headers that would make the message self describing. You would just click (literally or metaphorically) on the "unsubscribe URI" and the messages would stop arriving.... Still undecided what's most important. Maybe it is an issue for negotiation: a Verbose: header which defaults to True. Yeah, I kind of like that idea. Paul Prescod
Much of your response I need to digest for a few days. The following are only
those responses that seem solid:
> Okay, of course expiration counts should go both ways. The client should
> request one and the server should say what it decided upon.
Short of having a bid/counterbid/countercounterbid process, which is too hard to
implement, my suggestion was that we just have
bid/reject/bid-1/reject/bid-N/accept.
> Plus, HTTP (surprisingly!) doesn't really standardize how to report
> which expectation wasn't met. So how would you figure it out.
yup! way! Extension status-codes are legal... What is the cost of a new
status code? It seems completely reasonable to assume that a client which has
initiated a WATCH transaction would know how to understand related status codes.
A 4xx code is the expected extension code, given that the 417 expectation
implies that.
> I think you misunderstood 14.20: " The server MUST respond with a 417
> (Expectation Failed) status if any of the expectations cannot be met
> .."
Very possible. I find rfc 2616 not unlike ancient runes/nostradamus.
> > * The "subscription-expiration" header is required. Since it
> > is reasonable that many requests will be on a "good enough" basis
> > ("do the watch for as long as is feasible"), I suggest that this be
> > the default value. If there is a default value then there is no need
> > to have an expiration request header be a MUST.
>
> It isn't a MUST. It's a MAY in the spec as it is:
>
> "The message MAY contain a header called "Requested-Expiration"."
Sorry, no. I have reloaded the page several times and it still says MUST.
> > * I believe that this language overspecifies: "The client MAY renew
> > the subscription before this time. If it does not, the server MAY stop
> > sending notifications after that time. The server MAY also remove the
> > Subscription URI." This behavior should be left to the implementation.
>
> Debatable...what's the point of standardizing the headers if we don't
> standardize the associated behaviour?
There is no point in either. :)
Standards are not a goal in themselves, and I am not convinced that
canonicalization is constructive at this early stage. My feeling is that
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents is part of an ongoing
series of thought experiments regarding asynchronous design patterns in HTTP.
Specification is always destructive in that it reduces the available range of
expression. Overspecifying is not a service.
> > Expiration: The response to the Subscription MAY include a header
> > called "Subscription-Expiration".
>
> Just one? I might want a year or twelve issues. Whichever comes first.
hmm.... a relative date? a compound expression? need to mull this over. I
would prefer to avoid this kind of negotiation, which leads inevitably to yet
another programming language.
> > In the case of Expiration;adhoc, the server may cease performing the
> > watch at any time.
>
> I would say that the Server needs to report its policy in the response.
> i.e. One Month, 12 requests, etc. Otherwise, how will the client know
> when it is time to renew?
For the most part it's not important. Servers currently return 404 whenever it
pleases them. For the same reasons watches should be assumed to go until they
stop.
- Lucas
Great stuff, Paul! :-) (1) I think we should go all the way with the "subscription" terminology. Instead of "watchable resource" and "Watched-URI," "subscribable resource" and "Subscribed-URI". Instead of just "Location," "Subscription-Location." Etc. (2) Kill "Event." The semantics of change are application-dependent. For most things, the notification of a state change is sufficient; HTTP already provides a mechanism for then retreiving the new state representation. (The one caveat being a change to a resource with lots of subscriptions could generate a GET storm, but the application designer should anticipate this.) For anything other than simple change notificatins, applications should define their own change-representation notification schemes. (3) The language about message ordering is IMO dangerous. Requiring a publisher to deliver messages in order implies something about the server-side state that is perhaps best left to individual applications. Instead, if (from the server / HTTP perspective) notifications do not carry state but are simply notifications of state change, then message ordering becomes unimportant. (4) It might be useful to require an appropriate validator (entity tag or last-modified header) in every notification. In a sense, clients are simply caches for particular representations, and the HttpEvents "protocol" is just a push-based cache invalidation protocol. We should reuse the appropriate pieces of HTTP in this capacity. (5) I'm still uncomfortable talking about the mail binding at this time. That's not to say it's not important to have one, just that IMO it's best left to a separate specification.
On Thu, 31 Jan 2002, Paul Prescod wrote: > Okay, but how much work would it be to define a protocol with all of > IMAPs features that conforms to the HTTP syntax and model versus vice > versa? Adding "search" to HTTP would be trivial. Would adding URI > handling and content-negotiation to IMAP be similarly trivial? Re URI handling, do you mean RFC2192? Re content negotiation, do you mean: Content-type: multipart/alternative > > ODBC/SQL is also nice from the perspective you > > give. The problem is that it does not specify a > > way of passing the types of objects!!!!! > > Also not very well geared for large scale, loosely coupled computing. Why? > > Regarding universality. I would say that much of > > the universality of a communication protocol is a > > shared ontology aka a shared list of MIME > > content-types. > > I agree that this is necessary for an application. But I wouldn't say > that it is a benefit of the protocol itself. I think it is the main benefit of the protocol and the big problem with most RPC protocols. They don't provide a standard way of representing all types. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 31 Jan 2002, Paul Prescod wrote: > But at a deep level I hate the idea of inscrutable bytes arriving from > some remote source without telling me WHY they are arriving or HOW I > would stop them. I get that all the time on the various sites I have run. Various software and other websites incorrectly requesting stuff that used to exist or stuff that NEVER existed on my web server. I think it is part of life when you expose a public web server. Since the client can request a secret URL, the notifier would be getting a 404 and would then stop sending. If it keeps sending it is just behaving badly. > That's why I wanted headers that would make the message > self describing. You would just click (literally or metaphorically) on > the "unsubscribe URI" and the messages would stop arriving.... As you noted before. Unless the notification URL says to continue, notification stops. So this isn't an issue. > Still undecided what's most important. Maybe it is an issue for > negotiation: a Verbose: header which defaults to True. Yeah, I kind of > like that idea. You are making the spec too complex. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > On Thu, 31 Jan 2002, Paul Prescod wrote: > > But at a deep level I hate the idea of inscrutable bytes arriving from > > some remote source without telling me WHY they are arriving or HOW I > > would stop them. > > I get that all the time on the various sites I > have run. Various software and other websites > incorrectly requesting stuff that used to exist or > stuff that NEVER existed on my web server. I found a case that is greatly simplified if notifications contain URIs. If you set up a new intermediary such as the one I'm starting to describe at NotificationQueuing, then you need to communicate all of the URI->(watched-URI, subscription-URI) mappings to the intermediary. It is much better if the notifications are just self-describing so that lest advance coordination is necessary. NotificationQueuing = http://internet.conveyor.com/RESTwiki/moin.cgi/NotificationQueuing Paul Prescod
Jeff Bone wrote: > > Great stuff, Paul! :-) > > (1) I think we should go all the way with the "subscription" > terminology. Instead of "watchable resource" and "Watched-URI," > "subscribable resource" and "Subscribed-URI". Instead of just > "Location," "Subscription-Location." Etc. Not bad...I wonder if we'll regret using pub/sub terminology if people think it is too unlike pub/sub. When you subscribe to Playboy you don't get a once a month notification that there is a new edition available. You get a *magazine*. So our model is somewhat different. As you said, it is almost cache invalidation. If you don't think it is a problem want to go through and unify terminology while you are studying it, that's okay with me. > (2) Kill "Event." The semantics of change are > application-dependent. For most things, the notification of a > state change is sufficient; HTTP already provides a mechanism for > then retreiving the new state representation. (The one caveat > being a change to a resource with lots of subscriptions could > generate a GET storm, but the application designer should > anticipate this.) For anything other than simple change > notificatins, applications should define their own > change-representation notification schemes. That's what I've been saying. The application designer can use the body for hints that avoid GET storms. > (3) The language about message ordering is IMO dangerous. > Requiring a publisher to deliver messages in order implies > something about the server-side state that is perhaps best left > to individual applications. Instead, if (from the server / HTTP > perspective) notifications do not carry state but are simply > notifications of state change, then message ordering becomes > unimportant. I guess I'll take it out and see if a need for it arises. My main concern is that while you are retrying one event you don't want to build up a larger and larger queue of events you are retrying for the same missing subscriber until you start to interfere with network performance. > (4) It might be useful to require an appropriate validator > (entity tag or last-modified header) in every notification. Require is a little strong. Remember that part of the genious of HTTP is that basic implementations are so simple. MUST's start raising the bar. Maybe it is a feature that clients may ask for along with minimized notification bodies and whatever else we come up with. > ... In a > sense, clients are simply caches for particular representations, > and the HttpEvents "protocol" is just a push-based cache > invalidation protocol. We should reuse the appropriate pieces of > HTTP in this capacity. One reason that I'm not happy with it yet as a cache invalidation protocol is that it is not good at replicating collections. It's easy to watch a document that represents a collection. But you can only replicate the sub-resources if you understand the syntax of the container. HTTP should have a "give me this resource's children" method or something... > (5) I'm still uncomfortable talking about the mail binding at > this time. That's not to say it's not important to have one, > just that IMO it's best left to a separate specification. Doesn't make much difference to me. What is important is the architectural decision of whether we allow mailto: URIs to be subscription targets or always require a proxying intermediary. Paul Prescod
Lucas Gonze wrote: > > Much of your response I need to digest for a few days. The following are only > those responses that seem solid: > > > Okay, of course expiration counts should go both ways. The client should > > request one and the server should say what it decided upon. > > Short of having a bid/counterbid/countercounterbid process, which is too hard to > implement, my suggestion was that we just have > bid/reject/bid-1/reject/bid-N/accept. I don't see the benefit of bidding and counter-bidding. It isn't haggling. The subscriber should say what it wants. The publisher is boss. It should say what it offers. That's it. The question in my mind is whether the publisher should throw an error when the client asks for too much or whether it should just say: "The best I could do is X. If you want to delete the subscription, go ahead." > > "The message MAY contain a header called "Requested-Expiration"." > > Sorry, no. I have reloaded the page several times and it still says MUST. There are two different relevant parts: > The message MAY contain a header called "Requested-Expiration". > The response to the Subscription MUST include a header called "Subscription-Expiration". The spec is still working on the "you tell me what I want I'll tell you what I decided" model. >... > Standards are not a goal in themselves, and I am not convinced that > canonicalization is constructive at this early stage. Standards are not the end-goal but clients and servers (subscribers and publishers) that work together without negotiation is a goal and it takes standards. Even if only six people ever make software that works together and we are all on this list, the point is that we can only make software that works together with standards. >... > Specification is always destructive in that it reduces the available range of > expression. Overspecifying is not a service. You're going meta on me. I left a lot of freedom to the implementation: > > "The client MAY renew > > the subscription before this time. If it does not, the server MAY stop > > sending notifications after that time. The server MAY also remove the > > Subscription URI." This behavior should be left to the implementation. All that is standardized is that the server is "within its rights" to stop delivering notifications to the client and forget about it after the expiry time. The point is the server shouldn't just decide to stop delivering notifications whenever it feels like. It made a commitment. >... > hmm.... a relative date? a compound expression? need to mull this over. I > would prefer to avoid this kind of negotiation, which leads inevitably to yet > another programming language. I understand, but you wedged the door a little bit by going beyond my purely temporal expirations. The nice thing about temporal expirations is that you know how long you have to renew. >... > For the most part it's not important. Servers currently return 404 whenever it > pleases them. For the same reasons watches should be assumed to go until they > stop. How will you even know that's happened? I think that the server should make a commitment. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > Re URI handling, do you mean RFC2192? The protocol doesn't know anything about RFC2192, does it? > Re content negotiation, do you mean: > Content-type: multipart/alternative Don't know what you mean. Can IMAP do content-negotiation so that I can ask for a particular message in different content-types depending on the client? Anyhow, what makes IMAP particularly weak compared to HTTP is that it isn't designed to allow the server to do arbitrary computation in the generation of responses. It accepts data and moves data but it can't generate it without warping the protocol. > > > ODBC/SQL is also nice from the perspective you > > > give. The problem is that it does not specify a > > > way of passing the types of objects!!!!! > > > > Also not very well geared for large scale, loosely coupled computing. > > Why? Exposing your relational database schema to the world is not good encapsulation! >... > I think it is the main benefit of the protocol and > the big problem with most RPC protocols. They > don't provide a standard way of representing > all types. We'll have to agree to disagree. The list of MIME types are part of the Internet. Any protocol can easily adopt the relevant ones. Paul Prescod
On Thu, 31 Jan 2002, Paul Prescod wrote: > I found a case that is greatly simplified if notifications contain URIs. > If you set up a new intermediary such as the one I'm starting to > describe at NotificationQueuing, then you need to communicate all of > the URI->(watched-URI, subscription-URI) mappings to the intermediary. > It is much better if the notifications are just self-describing so that > lest advance coordination is necessary. I don't think NotificationQueuing makes sense. Why not just have an offline client ask for the access log of its relay server? Either way, if the intermediary just stores the URIs requested the client can do mapping whenever it likes. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Thu, 31 Jan 2002, Paul Prescod wrote: > That's what I've been saying. The application designer can use the body > for hints that avoid GET storms. Ugh. If you are doing this, then you should allow notification messages to specify alternative servers (preemptive redirect). > I guess I'll take it out and see if a need for it arises. My main > concern is that while you are retrying one event you don't want to build > up a larger and larger queue of events you are retrying for the same > missing subscriber until you start to interfere with network > performance. If the client misses notifications, that is OK. Why not just drop them? > > (4) It might be useful to require an appropriate validator > > (entity tag or last-modified header) in every notification. > > Require is a little strong. Remember that part of the genious of HTTP is > that basic implementations are so simple. MUST's start raising the bar. > > Maybe it is a feature that clients may ask for along with minimized > notification bodies and whatever else we come up with. Paul, this thing should be really easy to implement. The pure URI version with message dropping allowed means that each time a watched resource is changed it just iterates through a notification list issuing ___ requests with no content. I think this gets you almost everything you want. Adding all sorts of negotiation seems annoying. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > On Thu, 31 Jan 2002, Paul Prescod wrote: > > That's what I've been saying. The application designer can use the body > > for hints that avoid GET storms. > > Ugh. If you are doing this, then you should allow > notification messages to specify alternative > servers (preemptive redirect). I may do that but it is also easy to do that at the application layer...anyhow, I call it "watched-URI". You call it preemptive-redirect. It's a URI where you can get the resource. > > I guess I'll take it out and see if a need for it arises. My main > > concern is that while you are retrying one event you don't want to build > > up a larger and larger queue of events you are retrying for the same > > missing subscriber until you start to interfere with network > > performance. > > If the client misses notifications, that is OK. > Why not just drop them? What if the notification is for an important email that just arrived? Late is better than never. Retry is just a MAY. If a publisher doesn't want to implement it, they don't have to. Depends on the mission-criticality of the application. >... > > Paul, this thing should be really easy to > implement. > The pure URI version with message dropping allowed > means that each time a watched resource is changed > it just iterates through a notification list > issuing ___ requests with no content. Versus tagging each URI with "Watched-URI: $uri \nSubscription-URI: $sub_base?$uri". It's not hard either way. > I think this gets you almost everything you want. > > Adding all sorts of negotiation seems annoying. A few flags are not a major deal. We're talking about implementing in two hours or three! Paul Prescod
On Fri, 1 Feb 2002, Paul Prescod wrote: > > Re URI handling, do you mean RFC2192? > The protocol doesn't know anything about RFC2192, does it? Does it need to? What are you trying to accomplish? > > Re content negotiation, do you mean: > > Content-type: multipart/alternative > > Don't know what you mean. Can IMAP do content-negotiation so that I can > ask for a particular message in different content-types depending on the > client? That is the purpose of multipart/alternative. See RFC2046 sec. 5.1.4: Systems should recognize that the content of the various parts are interchangeable. Systems should choose the "best" type based on the local environment and references, in some cases even through user interaction > Anyhow, what makes IMAP particularly weak compared to HTTP is that it > isn't designed to allow the server to do arbitrary computation in the > generation of responses. It accepts data and moves data but it can't > generate it without warping the protocol. I don't think so. Pick an application that works better for HTTP than IMAP. Its just that most implementations are designed for actual mailboxes. Nothing prevents a server from virtualizing "mailboxes" Arguably IMAP is nicer in that it more clearly differentiates between update and query! > > > > ODBC/SQL is also nice from the perspective you > > > > give. The problem is that it does not specify a > > > > way of passing the types of objects!!!!! > > > > > > Also not very well geared for large scale, loosely coupled computing. > > > > Why? > > Exposing your relational database schema to the world is not good > encapsulation! Nothing stops you from exposing a view of your schema rather than your underlying schema. If you do end up exposing your schema, you can always expose a view later when you change it. Since there is a pretty direct mapping between resources and objects in table, I am not really sure what you are arguing here. > > I think it is the main benefit of the protocol and > > the big problem with most RPC protocols. They > > don't provide a standard way of representing > > all types. > > We'll have to agree to disagree. The list of MIME types are part of the > Internet. Any protocol can easily adopt the relevant ones. But they don't. In particular, XML-RPC does not use MIME content types. Niether does RMI or Corba. SOAP sort-of uses them in the SOAP with attachments spec, but it is really an afterthought. The reason why HTTP and SMTP have been so succesful in letting people talk to one another is MIME. No non-MIME transport protocol has been particularly successful. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 1 Feb 2002, Paul Prescod wrote: > > Ugh. If you are doing this, then you should allow > > notification messages to specify alternative > > servers (preemptive redirect). > > I may do that but it is also easy to do that at the application > layer...anyhow, I call it "watched-URI". You call it > preemptive-redirect. It's a URI where you can get the resource. If watched-URI is optional, then I don't have a strong objection to it. I just want to make sure that systems work properly with trivial implementations. > > > I guess I'll take it out and see if a need for it arises. My main > > > concern is that while you are retrying one event you don't want to build > > > up a larger and larger queue of events you are retrying for the same > > > missing subscriber until you start to interfere with network > > > performance. > > > > If the client misses notifications, that is OK. > > Why not just drop them? > > What if the notification is for an important email that just arrived? > Late is better than never. Retry is just a MAY. If a publisher doesn't > want to implement it, they don't have to. Depends on the > mission-criticality of the application. OK. But if notification bodies are optional, then you don't need to accumulate a queue of update messages for the client. You just need to send the last one. > > > > Paul, this thing should be really easy to > > implement. > > The pure URI version with message dropping allowed > > means that each time a watched resource is changed > > it just iterates through a notification list > > issuing ___ requests with no content. > > Versus tagging each URI with "Watched-URI: $uri \nSubscription-URI: > $sub_base?$uri". It's not hard either way. It is harder because then server implementations MUST know what their URI is. I've seen too many server environments where you don't. > > I think this gets you almost everything you want. > > > > Adding all sorts of negotiation seems annoying. > > A few flags are not a major deal. We're talking about implementing in > two hours or three! As long as support for negotiation isn't mandatory! I want subscription to be as simple as POST /foo/bar/subscription HTTP/1.0 Subscriber: http://myserver/foo/bar/handler ---- Note in reading the spec. again I think the big gap is actually in acquiring the subscription resource! For example, you might want a polling server to notify you of changes to a resource even if the underlying resource server is not implementing this protocol (and therefore doesn't send a Subscriptions: header). Rather than having a resource issue a Subsriptions: header, it makes much more sense for a subscription to issue a "location:" header pointing to the underlying subscribed resource. Even better, it should issue a location-regex: header. That way you could watch collections of urls that match a particular regex or set of regexes. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > OK. But if notification bodies are optional, then > you don't need to accumulate a queue of update > messages for the client. You just need to send > the last one. If the application has meaningful notification bodies then it might prefer to queue and retry. >... > It is harder because then server implementations > MUST know what their URI is. I've seen too many > server environments where you don't. All I ask is that you know ONE of your URIs. i.e. that you can generate a URI for yourself. Anyhow, I'll keep thinking about this. >... > Note in reading the spec. again I think the big > gap is actually in acquiring the subscription > resource! You don't need to get a subscription resource if you already know of a server that provides that service. The Subscription: URI is for when you DON'T know of one and you DO want to ask the server whether it can do it for you. > For example, you might want a polling server to > notify you of changes to a resource even if the > underlying resource server is not implementing > this protocol (and therefore doesn't send a > Subscriptions: header). No problem. If you now how to generate a Subscriptions resource just by pasting together uris then you can do that. > Rather than having a resource issue a > Subsriptions: header, it makes much more sense for > a subscription to issue a "location:" header > pointing to the underlying subscribed resource. I think this is an orthogonal issue. But yes, I do want subscription resources to be self-describing about what they are watching, what their expiry policy is, etc. There will be standard headers for that stuff. > Even better, it should issue a location-regex: > header. That way you could watch collections of > urls that match a particular regex or set of > regexes. How would you implement that as a polling proxy? I think that this is way into the domain of the application now. If it wants to provide it then it could do so by providing you with a WATCH on a regex URI query that generates a container object...like watching your vanity search on Google. Paul Prescod
"S. Alexander Jacobson" wrote: > > On Fri, 1 Feb 2002, Paul Prescod wrote: > > > Re URI handling, do you mean RFC2192? > > The protocol doesn't know anything about RFC2192, does it? > > Does it need to? What are you trying to > accomplish? I'd like (e.g.) to be able to make a resource such that references to that resource result in redirects to another resource on another machine with no coordination between the two machines. >... > > Don't know what you mean. Can IMAP do content-negotiation so that I can > > ask for a particular message in different content-types depending on the > > client? > > That is the purpose of multipart/alternative. See > RFC2046 sec. 5.1.4: It isn't the same thing. The information producer has to generate all of the types speculatively. >... > I don't think so. Pick an application that works > better for HTTP than IMAP. Does IMAP even have a notion of non-authorized references that would allow me to reference public IMAP servers? Anyhow, I gave you an example above. >... > Nothing stops you from exposing a view of your > schema rather than your underlying schema. If you > do end up exposing your schema, you can always > expose a view later when you change it. It typically is not that easy in practice. You really need a rich, Turing complete, programmatic layer between outsiders and your databases -- much more than a view with some stored procedures. You need to be able to unify multiple data sources. So you would have to *implement* the ODBC/SQL interface in code. Even relational companies do not push ODBC/SQL as a good middle-teir integration so I > Since there is a pretty direct mapping between > resources and objects in table, I am not really > sure what you are arguing here. That ODBC/SQL is only intended to be an abstraction layer over relational databases. Trying to make it a general purpose integration layer for (e.g.) structured data and multiple data sources will be painful. >... > The reason why HTTP and SMTP have been so > succesful in letting people talk to one another is > MIME. No non-MIME transport protocol has been > particularly successful. I will agree that this is yet another reason why the RPCs will probably fail... Paul Prescod
On Fri, 1 Feb 2002, Paul Prescod wrote: > > OK. But if notification bodies are optional, then > > you don't need to accumulate a queue of update > > messages for the client. You just need to send > > the last one. > > If the application has meaningful notification bodies then it might > prefer to queue and retry. It could always consolidate all the changes into one message body, avoiding queuing. > > It is harder because then server implementations > > MUST know what their URI is. I've seen too many > > server environments where you don't. > > All I ask is that you know ONE of your URIs. i.e. that you can generate > a URI for yourself. The problem is that the URI you generate for yourself may be inaccessible by the client. > > Note in reading the spec. again I think the big > > gap is actually in acquiring the subscription > > resource! > > You don't need to get a subscription resource if you already know of a > server that provides that service. The Subscription: URI is for when you > DON'T know of one and you DO want to ask the server whether it can do it > for you. The issue is that, as the spec stands, you can't (at the protocol level) correlate a subscription with a resource unless that resource support it. I suppose that is ok. It is just a little wierd. There is no reason some subscription directory page can't provide URLs of various subscription resources. However, if it does, I think it would be nice if subcription resources identified themselves in some way so that user-agents can handle them in some automated way. > > For example, you might want a polling server to > > notify you of changes to a resource even if the > > underlying resource server is not implementing > > this protocol (and therefore doesn't send a > > Subscriptions: header). > > No problem. If you now how to generate a Subscriptions resource just by > pasting together uris then you can do that. ??? Can you explain? I think the answer above is that you just know out-of-band the resource to which the subscription refers. > > Rather than having a resource issue a > > Subsriptions: header, it makes much more sense for > > a subscription to issue a "location:" header > > pointing to the underlying subscribed resource. > > I think this is an orthogonal issue. But yes, I do want subscription > resources to be self-describing about what they are watching, what > their expiry policy is, etc. There will be standard headers for that > stuff. ok. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > > ... > > I don't think NotificationQueuing makes sense. > Why not just have an offline client ask for the > access log of its relay server? What do you mean by relay server? In what sense is the queuing intermediary not a relay server? > Either way, if the intermediary just stores the > URIs requested the client can do mapping whenever > it likes. Probably. It's just so ugly to have to pass around those double-encoded URIs. Paul Prescod
"S. Alexander Jacobson" wrote: > > ... > > > > If the application has meaningful notification bodies then it might > > prefer to queue and retry. > > It could always consolidate all the changes into > one message body, avoiding queuing. It's up to the application. I don't know if there is anything we disagree on here. >... > ??? Can you explain? > I think the answer above is that you just know > out-of-band the resource to which the subscription > refers. There is a CGI script that does polling. You call it like this: http://poll.com/poll.cgi?uri=http://www.slashdot.org Now you get "first post" every time. Except for the double encoding. Argh, why can't URIs contain URIs? This is another way of getting a subscription to slashdot rather than going to the page and asking it how to subscribe to it. The primary reason resources can declare themselves watchable and nominate their subscriptions URI is because they can implement something much more efficient than polling! Paul Prescod
On Fri, 1 Feb 2002, Paul Prescod wrote: > > On Fri, 1 Feb 2002, Paul Prescod wrote: > > > > Re URI handling, do you mean RFC2192? > > > The protocol doesn't know anything about RFC2192, does it? > > > > Does it need to? What are you trying to > > accomplish? > > I'd like (e.g.) to be able to make a resource such that references to > that resource result in redirects to another resource on another machine > with no coordination between the two machines. E.g. someone emails you a web page with an IMAP URL in it. You click on the URL and your browser retrieves the IMAP page? That is the whole purpose of RFC2192? If you mean 30x style redirection, you can return a message with a message/external-body pointing to some IMAP URL. > >... > > > Don't know what you mean. Can IMAP do content-negotiation so that I can > > > ask for a particular message in different content-types depending on the > > > client? > > > > That is the purpose of multipart/alternative. See > > RFC2046 sec. 5.1.4: > > It isn't the same thing. The information producer has to generate all of > the types speculatively. You want server negotiation rather than client negotiation. The HTTP spec appears to discourage server negotiation. In practice, the server has only a finite set of types and can enumerate them without sending them all using the message/external-body. If you really want the equivalent of Accept:, style content-negotiation, you can implement it with Search. > >... > > I don't think so. Pick an application that works > > better for HTTP than IMAP. > > Does IMAP even have a notion of non-authorized references that would > allow me to reference public IMAP servers? Yes, it is like anonymous FTP. See e.g. http://www.cyrusoft.com/support/faq/anonimap.html > > Nothing stops you from exposing a view of your > > schema rather than your underlying schema. If you > > do end up exposing your schema, you can always > > expose a view later when you change it. > > It typically is not that easy in practice. You really need a rich, > Turing complete, programmatic layer between outsiders and your databases > -- much more than a view with some stored procedures. You need to be > able to unify multiple data sources. So you would have to *implement* > the ODBC/SQL interface in code. Why? You are just implementing SELECT contentType,content FROM resources WHERE id='someuri.html'. > Even relational companies do not push ODBC/SQL as a good middle-teir > integration so I Actually, Oracle basically thinks of web apps as a think layer on top of stored procedures and queries. > > Since there is a pretty direct mapping between > > resources and objects in table, I am not really > > sure what you are arguing here. > > That ODBC/SQL is only intended to be an abstraction layer over > relational databases. Trying to make it a general purpose integration > layer for (e.g.) structured data and multiple data sources will be > painful. So you want an odbc URL. That exists. Delivering an odbcURL + SQL tuple seems pretty straightforward. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> > I don't think NotificationQueuing makes sense. > > Why not just have an offline client ask for the > > access log of its relay server? > > What do you mean by relay server? In what sense is the queuing > intermediary not a relay server? Sorry, I meant queuing intermediary. The point remains with either terminology. > > Either way, if the intermediary just stores the > > URIs requested the client can do mapping whenever > > it likes. > > Probably. It's just so ugly to have to pass around those double-encoded > URIs. Why are you passing them? Suppose that the client has two subscriptions: http://intermediary.com/~client/sub1 and http://intermediary.com/~client/sub2 It then requests all updates simply by doing: http://intermediary.com/getLog?user=client it gets back /sub1 /sub2 The client knows how to map these back into URLs somewhere else. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul Prescod wrote: > Jeff Bone wrote: > > > > Great stuff, Paul! :-) > > > > (1) I think we should go all the way with the "subscription" > > terminology. Instead of "watchable resource" and "Watched-URI," > > "subscribable resource" and "Subscribed-URI". Instead of just > > "Location," "Subscription-Location." Etc. > > Not bad...I wonder if we'll regret using pub/sub terminology if people > think it is too unlike pub/sub. When you subscribe to Playboy you don't > get a once a month notification that there is a new edition available. > You get a *magazine*. So our model is somewhat different. As you said, > it is almost cache invalidation. OTOH, I think this is easily justified --- for Web-based subscriptions today, you don't expect to get the content sent to you, you expect to have the content change from time to time and you're expected to go and get it. This is just gravy on top of that. :-) > > (4) It might be useful to require an appropriate validator > > (entity tag or last-modified header) in every notification. > > Require is a little strong. Remember that part of the genious of HTTP is > that basic implementations are so simple. MUST's start raising the bar. That's true. Perhaps SHOULD. The problem with MAY is that nobody implements it, and application developers can't depend on it. > One reason that I'm not happy with it yet as a cache invalidation > protocol is that it is not good at replicating collections. It's easy to > watch a document that represents a collection. But you can only > replicate the sub-resources if you understand the syntax of the > container. HTTP should have a "give me this resource's children" method > or something... I was just thinking about this in the shower thismorning, just a few minutes ago! (Ugh, I know, TMI. ;-) Cf. next message, "Notifications on Containers." jb
So we've got a problem we need to solve with notifications on
containers. As a cautionary note: I think we need to tread
lightly, here. We don't want to hardwire any particular kind of
container semantics into the spec --- IMO, one of the problems
with DAV is that it imposes a new and rigid container semantics
on Web-based systems, one that isn't necessarily universal. That
said...
When subscribing to a container, there are two possible kinds of
notification of interest: changes to the contents of the
container (i.e., what is in it) --- potentially recursively ---
and changes *in* the contents of the container (i.e., changes to
the things in it) --- again potentially recursively. In order to
subscribe to a particular subtree of the resource space, however
an application may define that, you shouldn't have to subscribe
to each individual resource in that subtree. So we need two
mechanisms: a notification-time specifier that indicates which
resource has changed, and a subscription-time specifier that
indicates the "depth" of the subscription.
NOTIFICATION SPECIFIER
----------------------------
This one's easy. A container which generates notifications
SHOULD include a header "Changed-URI" that gives the full URI for
the resource which has changed, generating this event. The
Changed-URI MAY be a different URI than the Subscribed-URI /
Watched-URI associated with the subscription. A Changed-URI in a
notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e.,
a URI that has as a leading substring the full Subscribed-URI.
SUBSCRIPTION SPECIFIER
----------------------------
This one is tricky. At a first pass, it might be acceptable to
simply allow two kinds of container subscriptions: subscriptions
to change notifications when the top-level contents of the
container change, and subscriptions to changes to the top-level
contents or to any of the contained objects, recursively. I.e.,
a "recursive" boolean. There are perhaps two ways to do this.
(1) On the subscription request, the client could pass a header
"Recursive-Subscription" along to the subscribed resource.
(2) We could introduce some URI magic. Before everyone begins
yelling that this violates URI opacity, consider OPTIONS *. It's
already the case that * is in effect a special URI that in the
context of OPTIONS means "state of the server that receives the
request." With that in mind, assume
/foo
/foo/bar
/foo/baz/baf
/foo/ is a container that contains a non-container /foo/bar, and
a container /foo/baz/ that itself contains a non-container
/foo/baz/baf. A subscriber might specify
/foo/*
To get notifications in all of the following circumstances: (a)
the contents of /foo/ change. (b) The state of /foo/bar
changes. (c) The contents of /foo/baz/ change. (d) The state
of /foo/baz/baf changes.
A subscription on just /foo/ would simply generate events when
the contents of /foo/ change.
I actually prefer the second option; it gives a name-based
mechanism for distinguishing between the object itself and the
subtree, and let's name-based dispatch code figure out what's
going on rather than having to grope through the headers.
Sticking it in the headers feels a bit too much to me like RPC
with paramater-passing in the headers. But it's only a mild
preference.
$0.02,
jb
We might also need a way for a resource to indicate that it supports recursive subscription. Any thoughts on this? Jeff Bone wrote: > So we've got a problem we need to solve with notifications on > containers. As a cautionary note: I think we need to tread > lightly, here. We don't want to hardwire any particular kind of > container semantics into the spec --- IMO, one of the problems > with DAV is that it imposes a new and rigid container semantics > on Web-based systems, one that isn't necessarily universal. That > said... > > When subscribing to a container, there are two possible kinds of > notification of interest: changes to the contents of the > container (i.e., what is in it) --- potentially recursively --- > and changes *in* the contents of the container (i.e., changes to > the things in it) --- again potentially recursively. In order to > subscribe to a particular subtree of the resource space, however > an application may define that, you shouldn't have to subscribe > to each individual resource in that subtree. So we need two > mechanisms: a notification-time specifier that indicates which > resource has changed, and a subscription-time specifier that > indicates the "depth" of the subscription. > > NOTIFICATION SPECIFIER > ---------------------------- > > This one's easy. A container which generates notifications > SHOULD include a header "Changed-URI" that gives the full URI for > the resource which has changed, generating this event. The > Changed-URI MAY be a different URI than the Subscribed-URI / > Watched-URI associated with the subscription. A Changed-URI in a > notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e., > a URI that has as a leading substring the full Subscribed-URI. > > SUBSCRIPTION SPECIFIER > ---------------------------- > > This one is tricky. At a first pass, it might be acceptable to > simply allow two kinds of container subscriptions: subscriptions > to change notifications when the top-level contents of the > container change, and subscriptions to changes to the top-level > contents or to any of the contained objects, recursively. I.e., > a "recursive" boolean. There are perhaps two ways to do this. > > (1) On the subscription request, the client could pass a header > "Recursive-Subscription" along to the subscribed resource. > > (2) We could introduce some URI magic. Before everyone begins > yelling that this violates URI opacity, consider OPTIONS *. It's > already the case that * is in effect a special URI that in the > context of OPTIONS means "state of the server that receives the > request." With that in mind, assume > > /foo > /foo/bar > /foo/baz/baf > > /foo/ is a container that contains a non-container /foo/bar, and > a container /foo/baz/ that itself contains a non-container > /foo/baz/baf. A subscriber might specify > > /foo/* > > To get notifications in all of the following circumstances: (a) > the contents of /foo/ change. (b) The state of /foo/bar > changes. (c) The contents of /foo/baz/ change. (d) The state > of /foo/baz/baf changes. > > A subscription on just /foo/ would simply generate events when > the contents of /foo/ change. > > I actually prefer the second option; it gives a name-based > mechanism for distinguishing between the object itself and the > subtree, and let's name-based dispatch code figure out what's > going on rather than having to grope through the headers. > Sticking it in the headers feels a bit too much to me like RPC > with paramater-passing in the headers. But it's only a mild > preference. > > $0.02, > > jb > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Quick thought: a notification shouldn't use the GET method on the Subscriber resource --- doing so might be interpreted by an intermediary as a request for the state of the Subscriber resource. Anytime a Subscriber responds to a GET request, the response SHOULD be explicitly non-cacheable. A notification itself SHOULD be a method other than GET; I'm in favor of saying it MUST be a POST. Thoughts? jb
Jeff, Paul, > So we've got a problem we need to solve with notifications on > containers. Can you explain this one again? It is not clear. The context of this discussio is cache invalidation. The notion is that the cache contains some set of resources and we want the cache to request only the documents which have changed. Is there another application for this or do we think this particular application is sufficiently common to warrant special spec. features? > When subscribing to a container, there are two possible kinds of > notification of interest: changes to the contents of the > container (i.e., what is in it) --- potentially recursively --- > and changes *in* the contents of the container (i.e., changes to > the things in it) --- again potentially recursively. So a client can subscribe either to pages generated with this: (1) find -newer lastcheck htdocs -print0 or pages generated with this: (2) find -newer lastcheck htdocs -exec cat; > So we need two > mechanisms: a notification-time specifier that indicates which > resource has changed, and a subscription-time specifier that > indicates the "depth" of the subscription. Whether the cache wants (1) or (2) depends on whether the it can update itself using sub-file level diffs. But, I am not seeing why this stuff isn't already covered in the existing notification spec? Why do need need a special protocol for containers, when I can define resources that correspond to arbitrary container semantics and subscribe to them? I think the issue here is really specifying a common use case for diff and is irrelevant to whether the resource is a container or not. (I am with Mark here; the notion of container is sort of meaningless in HTTP) On Fri, 1 Feb 2002, Jeff Bone wrote: > NOTIFICATION SPECIFIER > ---------------------------- > > This one's easy. A container which generates notifications > SHOULD include a header "Changed-URI" that gives the full URI for > the resource which has changed, generating this event. The > Changed-URI MAY be a different URI than the Subscribed-URI / > Watched-URI associated with the subscription. A Changed-URI in a > notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e., > a URI that has as a leading substring the full Subscribed-URI. This just seems like a special case of where to retrieve the diff. > SUBSCRIPTION SPECIFIER > ---------------------------- > > This one is tricky. At a first pass, it might be acceptable to > simply allow two kinds of container subscriptions: subscriptions > to change notifications when the top-level contents of the > container change, and subscriptions to changes to the top-level > contents or to any of the contained objects, recursively. I.e., > a "recursive" boolean. There are perhaps two ways to do this. I think there are more. Look at all the options to the unix 'find' command. * last modified * last accessed * last created * depth * file patter (e.g. only .html) * file owner/group This seems like a minefield. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Notifications may not be GETs because a notification is an update the the notified resource! If notifications are booleans then they are PUT. If notifications have time stamps or optional content they are POST. -Alex- On Fri, 1 Feb 2002, Jeff Bone wrote: > > Quick thought: a notification shouldn't use the GET method on > the Subscriber resource --- doing so might be interpreted by an > intermediary as a request for the state of the Subscriber > resource. Anytime a Subscriber responds to a GET request, the > response SHOULD be explicitly non-cacheable. A notification > itself SHOULD be a method other than GET; I'm in favor of saying > it MUST be a POST. > > Thoughts? > > jb > > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Haven't caught up on your rest-discuss reading yet, Jeff? 8-) (I know I haven't). Lucas and I talked about this. I think any method with side-effects is ok. > Quick thought: a notification shouldn't use the GET method on > the Subscriber resource --- doing so might be interpreted by an > intermediary as a request for the state of the Subscriber > resource. Anytime a Subscriber responds to a GET request, the > response SHOULD be explicitly non-cacheable. A notification > itself SHOULD be a method other than GET; I'm in favor of saying > it MUST be a POST. > > Thoughts? > > jb MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Came across this again... ----- Forwarded message from "Roy T. Fielding" <fielding@...> ----- Date: Mon, 03 Jan 2000 11:28:23 -0800 From: "Roy T. Fielding" <fielding@...> To: Mark Nottingham <mnot@...> Cc: http-wg@..., mnot@... Subject: Re: server parsing of URI path parameters In message <19991230095914.A436@...>, Mark Nottingham writes: > >I've been looking at use of parameters on path segments of URIs, as >discussed in RFC2396 (section 3.3). > >As I understand it, the original reason that parameters were used, >and therefore the semicolon was a reserved character, is >pre-HTTP/1.1 range specification. Actually, no, they were introduced in RFC 1808 long before the range hack. Before that, I'd say they were most influenced by the deisre to support versioning a la VMS. >I'm not clear on their current use, and was a bit surprised >to see 2396 say that each path segment could have its own parameters, so >that you could get: > http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5 >and so forth. If anyone could clear up the history here, I'd be grateful. Think of it as an issue of precedence. In almost all URL parsers, the slash characters have precedence over any other character during routine parsing of components. The result is that the path is separated into path segments before anything looks at the semicolons. >With that in mind, a more HTTP-specific question: How should an >origin server treat a request that includes parameters? Some trival >testing suggests that current practice is to treat them as part of >the path, so that an error is returned. Would it be better to have >them ignore parameters that aren't understood? That is entirely dependent on the nature of the resource. A server can interpret its own namespace however it wants. Cheers, ....Roy ----- End forwarded message ----- -- Mark Nottingham http://www.mnot.net/
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > Even with no details about the current or changed values of the the > > resource, I would like to know what type of operation occurred. > > You *might* like to know. But is it worth complicating the > specification? No. *I* would like to know. Other people *might* want to know. But *I* definitely do.
----- Original Message ----- From: "Paul Prescod" <paul@...> > "S. Mike Dierken" wrote: > > > "Having information about what happened on the web server" - the web server > > would have the results of applying what happned, but it wouldn't have a > > record of what happened. It wouldn't (in general) have an audit trail - like > > 'paul edited this file at 12:00am with vi'. It would have 'the file says > > "hello world"'. > > If the audit trail is important then the server should have a resource > representing the audit trail. If the audit trail is NOT important then > why do notification clients care about it? I'm a hardliner on this > principle that there should be nothing in the notification that is not > just a summary of information available on the site. I suspect that approach won't scale well.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > Also, I don't want 'twenty event types', I only want HTTP referenceable > > 'event types' - a mapping of what occurred into http state transition > > operations. Having 'twenty event types' is analagous to having twenty http > > methods. > > I am not convinced that the basic HTTP methods are automatically the set > of event types all applications would like. If the applications are 'resource modelling aware' they can only coordinate via 'resource modification' - and we've already determined that there are/should be a small number of common/generic modification primitives. Just as applications understand what deleting a resource means, or posting to a resource means, they will understand the inverse - a resource was deleted, a resource was posted to.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > Watching a file that contains READ occurrances is fine - but I would like to > > declare that in the subscription in a standardized way (WATCH /foo/logins > > method=READ) rather than a URI up to application definition (WATCH > > /foo/logins/all_reads). > > And some other user is going to want to watch READ occurrences FROM a > particular range of IP addresses. We either need to define a really > hairy, Turing-complete filter language or we need to leave it up to the > application. I claim that the "HTTP solution" is to leave it up to the > application to do with resource modeling. Now why is your seemingly > reasonable request any different in kind, not just degree, from the guy > who wants to filter by IP address or time of day or content-type or ... It isn't. That is the kind of filtering I would like to be able to do (other than the IP example, unless it is framed as an http uri). Just like HTTP allows me to send JPEG when everybody else is doing HTML. There is a slot for the concept - not everybody uses it, but its there. Just like not everybody would use the 'watch for this operation+status on this resource'. There could be a default to 'watch for method=POST|DELETE|PUT status=2xx on this resource' > > That content-type example is particularly interesting because it is > purely in the domain of HTTP so it falls into the same category as the > method. Should people be able to filter on content-type as well as > method? What about filtering on Host:. etc. etc. Yes. > > Just do it with the URI and be done with it! Reformulating queries and > filters as URIs is one of the most brilliant things about the Web and I > want to emulate it. Perhaps - let me think about it and write down some samples. I like that idea too - but I'm not sure if that looseness would hurt a 'watch' pseudo-method (the appearance of being custom/proprietary/non-standard may slow adoption). A more rigorous/burned-into-the-protocol approach is harder to do and also harder to deploy, but it might make some people more confident that it is okay to use.
----- Original Message ----- From: "Paul Prescod" <paul@...> > "S. Mike Dierken" wrote: > > > >... > > I don't mean the details in the body, I mean (from Alex's example) the > > method used for the notification. > > I think that there are strong backwards-compatibility forces that argue > in favour of using standard HTTP methods. But actually I'm willing to > allow the application to use whatever methods (standard or extension) it > wants. Yes, I agree completely - the examples were very consice and communicated the intent just fine, but I wouldn't use those as HTTP methods. Something like: --CREATED-- POST /notification/path HTTP/1.1 Content-Type: application/x-www-form-url-encoded uri=http://shop.widgets-r-us.com/accounting/po/ack/123/ method=PUT --CHANGED-- POST /notification/path HTTP/1.1 Content-Type: application/x-www-form-url-encoded uri=http://events.dierken.com/who/mike/status/ method=PUT --DELETED-- POST /notification/path HTTP/1.1 Content-Type: application/x-www-form-url-encoded uri=http://rooms.hot-live-chat.com/rooms/98034/55/ method=DELETE
----- Original Message ----- From: "Paul Prescod" <paul@...> > > I've clarified my thoughts on how to handle notifications for > collections. Collections are just documents that happen to contain URIs > to other documents. Just hang a WATCH on that document. Woohoo! Yes, by george, you've got it! As a Groves dude, this should be pretty straightforward for you to work out the details of. And the resource (aka 'collection') may have metadata separate from the list of URIs - how do distinguish between the two? That's where the 'add/remove' comes from - they are 'updates' to the 'default collection' property. But that is all really too complex for now - I can build it in the app layer with the low level primitives.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > I've also clarified my thoughts on message bodies. A notification's only > responsibility is to report that something changed. It is totally about > temporality. It's the secret spy-code where the phone rings twice with > no message. > I'm concerned that if this is deployed bodyless by default, there will be a tremendous amount of traffic back to the server (and there already is that at the tcp/ip level, this would add more) - a type of 'ack implosion'. As long as /my/ apps can send the data I'm fine with that, but I'd recommend the 'no-body' approach as a 'security' optimization at the cost of scalability.
----- Original Message ----- From: "Lucas Gonze" <lucas@...> > > * The prefix "Requested-" is redundant. Better wording would be > "Expiration-Date" and "Expiration-Count". Would 'max-age' (as applied to the messages) be relevant? Also, how would you ask for messages from the past (if you had a system with an 'audit trail'/history)? The KnowNow stuff has a max-age parameter when creating a subscription, but I haven't followed this 'expiration' discussion, so it might not be relevant.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > But at a deep level I hate the idea of inscrutable bytes arriving from > some remote source without telling me WHY they are arriving or HOW I > would stop them. That's why I wanted headers that would make the message > self describing. You would just click (literally or metaphorically) on > the "unsubscribe URI" and the messages would stop arriving.... > I feel the same - but it is also possible that response codes to the notify might be useful (404 not found). But with some UI agent storing the notifications, it might be better to 'stop the noise now' via the URI in a header. I like both approaches.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > > Ugh. If you are doing this, then you should allow > > notification messages to specify alternative > > servers (preemptive redirect). > > I may do that but it is also easy to do that at the application > layer...anyhow, I call it "watched-URI". You call it > preemptive-redirect. It's a URI where you can get the resource. > If the client knows what it is watching, and the 'watched-uri' doesn't match its list, what happens?
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > Rather than having a resource issue a > Subsriptions: header, it makes much more sense for > a subscription to issue a "location:" header > pointing to the underlying subscribed resource. > > Even better, it should issue a location-regex: > header. That way you could watch collections of > urls that match a particular regex or set of > regexes. > Watching collections via patterns is way cool - can you provide some examples of what that would look like?
If I parse this right, and I'm not sure I do, then I believe the answer is that it should be a PUT. Jeff Bone wrote: > > Quick thought: a notification shouldn't use the GET method on > the Subscriber resource --- doing so might be interpreted by an > intermediary as a request for the state of the Subscriber > resource. Anytime a Subscriber responds to a GET request, the > response SHOULD be explicitly non-cacheable. A notification > itself SHOULD be a method other than GET; I'm in favor of saying > it MUST be a POST. > > Thoughts? > > jb
----- Original Message ----- From: "Jeff Bone" <jbone@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, February 01, 2002 7:27 AM Subject: [rest-discuss] Notifications on Containers > > When subscribing to a container, there are two possible kinds of > notification of interest: changes to the contents of the > container (i.e., what is in it) --- potentially recursively --- > and changes *in* the contents of the container (i.e., changes to > the things in it) --- again potentially recursively. Yes - containers are interesting. I spent quite a bit of time implementing this last year at a previous company. Only got to 'depth=1' because I allowed for multiple sub-collections rather than one default. And I was using SQL and didn't want a bazillion queries fired off for each event for each subscription. It's one thing to define (fully) what the problem is, its another to specify what portion will be implemented and implement it.
You may want to distinguish changes that affect the collection via add/remove and changes that affect the content of the container via update. Useful, but probably too application specific for everybody (but if it is really common, it can at least be described). Recursive stuff is fun. If a resource has more than one named collection that's even more fun. If it has one 'default' un-named collection its easier to use the URL sub-path pattern matching approach (but, like you said, URI opaqueness will break, as well as the 'web-ness' of the Web). Doing this URI pattern stuff will be really powerful but only for a sub-set of all applications. So that'll probably end up at the application level and require documentation of 'my way' of doing things. If I were doing my own app and had multiple named collections per resource I'd use WATCH /foo/bar;children WATCH /foo/bar;referrers WATCH /foo/bar;permissions WATCH /foo/bar (implies /foo/bar;*) If I didn't have named collections but had one 'default' collection I'd use: WATCH /foo/bar?method=ADD
Good find. The mention of ";" appears to be counter to his suggestion on FoRK to use it as a universal modifier for resource properties (if I understood him). My investigations have left me concluding what Roy describes below, that it's entirely opaque. BTW, in the hopes of giving me the will necessary to polish off my opacity report, I'll give you all the URI to it, incomplete as it is. Comments, suggestions, and encouragement are all welcome. http://www.markbaker.ca/2002/01/UriOpacityInvestigation/ > > Came across this again... > > > ----- Forwarded message from "Roy T. Fielding" <fielding@...> ----- > > Date: Mon, 03 Jan 2000 11:28:23 -0800 > From: "Roy T. Fielding" <fielding@...> > To: Mark Nottingham <mnot@...> > Cc: http-wg@..., mnot@... > Subject: Re: server parsing of URI path parameters > > In message <19991230095914.A436@...>, Mark Nottingham writes: > > > >I've been looking at use of parameters on path segments of URIs, as > >discussed in RFC2396 (section 3.3). > > > >As I understand it, the original reason that parameters were used, > >and therefore the semicolon was a reserved character, is > >pre-HTTP/1.1 range specification. > > Actually, no, they were introduced in RFC 1808 long before the range > hack. Before that, I'd say they were most influenced by the deisre > to support versioning a la VMS. > > >I'm not clear on their current use, and was a bit surprised > >to see 2396 say that each path segment could have its own parameters, so > >that you could get: > > http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5 > >and so forth. If anyone could clear up the history here, I'd be grateful. > > Think of it as an issue of precedence. In almost all URL parsers, > the slash characters have precedence over any other character during > routine parsing of components. The result is that the path is > separated into path segments before anything looks at the semicolons. > > >With that in mind, a more HTTP-specific question: How should an > >origin server treat a request that includes parameters? Some trival > >testing suggests that current practice is to treat them as part of > >the path, so that an error is returned. Would it be better to have > >them ignore parameters that aren't understood? > > That is entirely dependent on the nature of the resource. A server > can interpret its own namespace however it wants. > > Cheers, > > ....Roy > > > ----- End forwarded message ----- > > -- > Mark Nottingham > http://www.mnot.net/ > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Nice! Another thing to note is that a URI with a query is effectively always a leaf node, whilst one with parameters can be a parent. 2396 says of parameters Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references. which seems to fit nicely into your doc's concept of whether a separator is significant in terms of establishing a hierarchical relationship. I'm leaning towards a use of parameters as ways to identify contextually (?) different variants of a resource; I know you talked about using conneg to negotiate an edit form of a LDAP entry (for example), but I still scratch my head at that. IMHO it makes more sense to say http://address.example.org/UserEntry <-- a representation of the entry http://address.example.org/UserEntry;editform <-- the editable form Thoughts? On Fri, Feb 01, 2002 at 01:15:56PM -0500, Mark Baker wrote: > Good find. > > The mention of ";" appears to be counter to his suggestion on FoRK to > use it as a universal modifier for resource properties (if I understood > him). My investigations have left me concluding what Roy describes > below, that it's entirely opaque. > > BTW, in the hopes of giving me the will necessary to polish off my > opacity report, I'll give you all the URI to it, incomplete as it is. > Comments, suggestions, and encouragement are all welcome. > > http://www.markbaker.ca/2002/01/UriOpacityInvestigation/ > > > > > Came across this again... > > > > > > ----- Forwarded message from "Roy T. Fielding" <fielding@...> ----- > > > > Date: Mon, 03 Jan 2000 11:28:23 -0800 > > From: "Roy T. Fielding" <fielding@...> > > To: Mark Nottingham <mnot@...> > > Cc: http-wg@..., mnot@... > > Subject: Re: server parsing of URI path parameters > > > > In message <19991230095914.A436@...>, Mark Nottingham writes: > > > > > >I've been looking at use of parameters on path segments of URIs, as > > >discussed in RFC2396 (section 3.3). > > > > > >As I understand it, the original reason that parameters were used, > > >and therefore the semicolon was a reserved character, is > > >pre-HTTP/1.1 range specification. > > > > Actually, no, they were introduced in RFC 1808 long before the range > > hack. Before that, I'd say they were most influenced by the deisre > > to support versioning a la VMS. > > > > >I'm not clear on their current use, and was a bit surprised > > >to see 2396 say that each path segment could have its own parameters, so > > >that you could get: > > > http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5 > > >and so forth. If anyone could clear up the history here, I'd be grateful. > > > > Think of it as an issue of precedence. In almost all URL parsers, > > the slash characters have precedence over any other character during > > routine parsing of components. The result is that the path is > > separated into path segments before anything looks at the semicolons. > > > > >With that in mind, a more HTTP-specific question: How should an > > >origin server treat a request that includes parameters? Some trival > > >testing suggests that current practice is to treat them as part of > > >the path, so that an error is returned. Would it be better to have > > >them ignore parameters that aren't understood? > > > > That is entirely dependent on the nature of the resource. A server > > can interpret its own namespace however it wants. > > > > Cheers, > > > > ....Roy > > > > > > ----- End forwarded message ----- > > > > -- > > Mark Nottingham > > http://www.mnot.net/ > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com -- Mark Nottingham http://www.mnot.net/
A list of URIs is too limiting - it may not be practical or possible to enumerate them all... On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote: > > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > > > > > I've clarified my thoughts on how to handle notifications for > > collections. Collections are just documents that happen to contain URIs > > to other documents. Just hang a WATCH on that document. > Woohoo! Yes, by george, you've got it! As a Groves dude, this should be > pretty straightforward for you to work out the details of. > And the resource (aka 'collection') may have metadata separate from the list > of URIs - how do distinguish between the two? That's where the 'add/remove' > comes from - they are 'updates' to the 'default collection' property. But > that is all really too complex for now - I can build it in the app layer > with the low level primitives. > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
On Fri, 1 Feb 2002, S. Mike Dierken wrote: > Yes - containers are interesting. I spent quite a bit of time implementing > this last year at a previous company. > Only got to 'depth=1' because I allowed for multiple sub-collections rather > than one default. And I was using SQL and didn't want a bazillion queries > fired off for each event for each subscription. > It's one thing to define (fully) what the problem is, its another to specify > what portion will be implemented and implement it. FYI, celko describes a very nice way of managing acyclic graphs using SQL without generating bazillion queries. The trick is to treat subtrees as subsets and give each node a left,right bound on the total number of leaves. Very elegant and very inexpensive. Gave me a whole new respect for the power of SQL. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 1 Feb 2002, S. Mike Dierken wrote: > Watching collections via patterns is way cool - can you provide some > examples of what that would look like? I think it is application level. But I would imaging wanting to know e.g usage of a particular set of conference rooms ... -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 1 Feb 2002, S. Mike Dierken wrote: > I'm concerned that if this is deployed bodyless by default, there will be a > tremendous amount of traffic back to the server (and there already is that > at the tcp/ip level, this would add more) - a type of 'ack implosion'. > As long as /my/ apps can send the data I'm fine with that, but I'd recommend > the 'no-body' approach as a 'security' optimization at the cost of > scalability. I'm not sure that scaling issues are soo bad. Servers with lots of subscribers can push notification out to slaves on other networks in larger batches. The spec can also recommend that clients wait to get the new version of the resource until it is demanded by a user. The server can enforce this by spreading out notification over time, so that clients that do immediate request updates are spread over time. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 1 Feb 2002, S. Mike Dierken wrote: > I feel the same - but it is also possible that response codes to the notify > might be useful (404 not found). > But with some UI agent storing the notifications, it might be better to > 'stop the noise now' via the URI in a header. > I like both approaches. User agents that store notifications can PUT to the URI to create a listenning resource on the intermediary notification server. Once the resource is created notifications will get a non 40x response. Btw, this means that notifications MUST be POST. PUT tells the intermediary to create a listener at that URI. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
You see, this is why I'm afraid to go to sleep at night. I never know how much crud will be awaiting me in the morning. Maybe if we're all in that state we should consciously slow down... Anyhow, we'll all be at the Python conference next week, right? ;) ;) ;) As an aside, there seems to be a frightening overlap of rest-discuss subscribers and Python programmers. And Tim B-L is a keynoter next week. And Dan C. has been a Python programmer for ages. Coincidence? I wonder.... Paul Prescod
Every body agrees that they shouldn't be GETs. The only question is whether the spec should be explicit about that or just depend on common sense. I'm in favour of being explicit. Next question is whether to hard-code a method. My sense is that you don't buy much by doing so. 99% of all services will use PUT or POST depending on whether the change is relative to the previous state fo the resource or absolute (Mark Baker's idea...stock price change versus new stock price). Leaving open the option of other methods doesn't seem to have much interoperability cost to me. People will only use it when they think that their subscribers will understand it. And it "feels" to me like it might allow some kinds of coordination where I say: "this thing is going to change in the future. I want that change to trigger a DELETE over here and a LOCK over there and ..." Of course authentication issues get weird because now the publisher is standing in for you...so this might not work really in practice. Paul Prescod
Jeff Bone wrote: > > ... > > > > (4) It might be useful to require an appropriate validator > > > (entity tag or last-modified header) in every notification. > > > > Require is a little strong. Remember that part of the genious of HTTP is > > that basic implementations are so simple. MUST's start raising the bar. > > That's true. Perhaps SHOULD. The problem with MAY is that nobody > implements it, and application developers can't depend on it. SHOULD also means they can't depend upon it. Anyhow, here is the original proposal: (4) It might be useful to require an appropriate validator (entity tag or last-modified header) in every notification. In a sense, clients are simply caches for particular representations, and the HttpEvents "protocol" is just a push-based cache invalidation protocol. We should reuse the appropriate pieces of HTTP in this capacity. Maybe you can go into more detail about why this is important for clients, servers, intermediaries, how you expect it to be used etc. so we can figure out how important it is. Paul Prescod
Your point about the existence of intermediaries requires that the method be neither PUT nor DELETE. If I want an intermediary to listen at a particular URI, I will PUT a listener there. If I want an intermediate to stop listening, I will DELETE the listener. If I want to change the listener in some way (e.g. log to a different file), I will probably want to be able to POST a change to the listener as well. If I want to get the current status of the listener I will probably want to GET it. In general we need to make a distinction between the way the notification agent talks to a notification listener and the way the owner of the listener controls it. Therefore, I think notification requires a new method e.g. NOTIFY. -Alex- On Fri, 1 Feb 2002, Paul Prescod wrote: > Every body agrees that they shouldn't be GETs. The only question is > whether the spec should be explicit about that or just depend on common > sense. I'm in favour of being explicit. > > Next question is whether to hard-code a method. My sense is that you > don't buy much by doing so. 99% of all services will use PUT or POST > depending on whether the change is relative to the previous state fo the > resource or absolute (Mark Baker's idea...stock price change versus new > stock price). > > Leaving open the option of other methods doesn't seem to have much > interoperability cost to me. People will only use it when they think > that their subscribers will understand it. And it "feels" to me like it > might allow some kinds of coordination where I say: "this thing is going > to change in the future. I want that change to trigger a DELETE over > here and a LOCK over there and ..." > > Of course authentication issues get weird because now the publisher is > standing in for you...so this might not work really in practice. > > Paul Prescod > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > Notifications may not be GETs because a > notification is an update the the notified > resource! Yup. It wasn't clear that everybody agreed to this --- have been reading the list in a lossy fashion due to time constraints, thought I remembered seeing somebody advocating for notifications being any old method. jb
"S. Alexander Jacobson" wrote: > User agents that store notifications can PUT to > the URI to create a listenning resource on the > intermediary notification server. Once the > resource is created notifications will get a non > 40x response. > > Btw, this means that notifications MUST be POST. > PUT tells the intermediary to create a listener at > that URI. Frightening as it is, I find myself in complete agreement here. The motivation for suggesting POST was just this, an analysis of the impact of PUT on intermediaries. jb
"S. Alexander Jacobson" wrote: > .... > In general we need to make a distinction between > the way the notification agent talks to a > notification listener and the way the owner of the > listener controls it. I think that the listener manager is a totally different resource than the listener URI. In particular, the listener manager may own many particular listener URIs... Paul Prescod
Jeff Bone wrote: > >... > > Frightening as it is, I find myself in complete agreement here. The motivation > for suggesting POST was just this, an analysis of the impact of PUT on > intermediaries. If you want to use POST to mean two different things on the same resource (or GET or ...) then probably you should just split the resource. Paul Prescod
Paul Prescod wrote: > Jeff Bone wrote: > > > >... > > > > Frightening as it is, I find myself in complete agreement here. The motivation > > for suggesting POST was just this, an analysis of the impact of PUT on > > intermediaries. > > If you want to use POST to mean two different things on the same > resource (or GET or ...) then probably you should just split the > resource. I don't think we disagree on this, but maybe I'm missing something. I'm suggesting that a POST to the Subscriber: URI has as its appropriate (and only) interpretation that the Subscribed-URI has changed. (Applications might further describe *how* it has changed via headers or body, but IMO that's app-specific and should be out-of-scope for our purposes.) What other interpretation of POST could there be? And why allow any other method to have those semantics? jb
Mark Nottingham wrote: > A list of URIs is too limiting - it may not be practical or possible > to enumerate them all... Yup, very important point. jb
Paul Prescod wrote: > SHOULD also means they can't depend upon it. Anyhow, here is the > original proposal: Good point. So you've argued me back to my original position, which you didn't seem to agree with. ;-) Notifications MUST include a validator. Note that a notification is however a request, so actually using the etag or last-modified header is probably inappropriate; we probably need a notification-specific version of these things. > (4) It might be useful to require an appropriate validator > (entity tag or last-modified header) in every notification. In a > sense, clients are simply caches for particular representations, > and the HttpEvents "protocol" is just a push-based cache > invalidation protocol. We should reuse the appropriate pieces of > HTTP in this capacity. > > Maybe you can go into more detail about why this is important for > clients, servers, intermediaries, how you expect it to be used etc. so > we can figure out how important it is. Consider that a subscriber is really in a sense a cache for the subscribed resource. This cache supports a "standard" HTTP-based interface (the Subscriber interface) allowing subscribable resources to pre-emptively notify the cache of changes and thereby invalidate cached entities. Given this, it seems useful to include data in a notification which the cache / subscriber can check against similar data for its cached representation to determine whether to proceed with refreshing it. Using such information would permit caches to avoid extraneous GET / refresh operations. Consider: notification to a list of subscribers is likely to take time. A subscribed resource changes. During the notification process but before a particular subscriber is notified, that subscriber does a GET and obtains the current representational state. They then receive a notification that the state is changed, but in fact they have the current and correct state. A mandatory validator in the notification would allow the subscriber to check its cached copy and determine that a GET was unnecessary at that point. This is important for servers because it lightens the GET load when things change; it's important both for servers and traditional proxy caches as it can potentially significantly reduce the burden of keeping the cache fresh. It's important to clients because, as mentioned, clients are conceptually nothing more than specialized caches; the benefits to proxies apply as well to clients. Does that help, or was it clear as mud? ;-) jb
On Fri, 1 Feb 2002, Jeff Bone wrote: > I don't think we disagree on this, but maybe I'm missing something. I'm suggesting > that a POST to the Subscriber: URI has as its appropriate (and only) interpretation > that the Subscribed-URI has changed. (Applications might further describe *how* it > has changed via headers or body, but IMO that's app-specific and should be > out-of-scope for our purposes.) What other interpretation of POST could there be? > And why allow any other method to have those semantics? My argument in my last mail on this issue is that POST to the subscriber URL may be an update to the listener e.g. you may want to tell the listener to log notifications to a different file or you know want it to page a user when it recieves notification. See my last message for all scenarios. I argue that therefore either you need a new method or you need to pass something in the header/body saying the POST is a notification. Paul argues that listener management should happend at a different URL from notification. I don't think that makes sense. You can only notify a listener if it exists. The most obvious way to create a listener at a URL is to PUT a listener there. The alternative is some form of RPC with some listener manager which is ugly. I suspec Paul is concerned with the example in (1) describing why CVSSTAT is bad. The difference is that NOTIFY is not idempotent so this argument doesn't apply. -Alex- (1) http://www.w3.org/DesignIssues/Architecture ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Jeff Bone wrote: > >.... > > I don't think we disagree on this, but maybe I'm missing something. I'm suggesting > that a POST to the Subscriber: URI has as its appropriate (and only) interpretation > that the Subscribed-URI has changed. (Applications might further describe *how* it > has changed via headers or body, but IMO that's app-specific and should be > out-of-scope for our purposes.) What other interpretation of POST could there be? > And why allow any other method to have those semantics? One way of looking at it is that the notifications are trying to replicate the content from the publisher to the subscriber. So the publisher PUSHes representations of the resource or POSTs representations of changes or extensions to the resource. This would imply that it would DELETE if the resource was deleted. I don't think that view is going to go anywhere. Whether or not you agree with this model you might still want to allow the application to choose its own method. It would be up to the publisher and subscriber to decide what the methods mean exactly. Another way of looking at it (Alex's) is that the POSTs to the listener would come from the app that owns the listener and would be used to configure it. So then the publisher should send NOTIFYs. Or you could say that POSTs on listeners come from publishers but DELETEs come from the application. Not sure what you would say about PUT, probably from the publisher... Paul Prescod
"S. Alexander Jacobson" wrote: > Paul argues that listener management should > happend at a different URL from notification. I agree. "Listener management" --- if it's provided by the listener at all --- should happen at a different URL. Overloading POST to the same resource to do both notification and listener management begins to slip away from resource modeling to RPC-land, IMHO. > I don't think that makes sense. You can only > notify a listener if it exists. The most > obvious way to create a listener at a URL is to > PUT a listener there. Since when is creating the "listener" the Subscribable entity's responsibility? (I assume by listener you mean the client-side interface onto which notifications are dispatched, i.e. the "observer" or what we've been calling the "Subscriber.") jb
Paul Prescod wrote: > One way of looking at it is that the notifications are trying to > replicate the content from the publisher to the subscriber. Here I think we disagree --- I started off this whole tangent at that point of view and have basically convinced myself / been convinced by the conversation (some of it yours! ;-) that what we're specifying is purely a *change notification* protocol, and that proactive *state replication* in-band with notifications is best left out-of-scope. (Neither specified nor prohibited.) That's not to say it's not attractive in many scenarios --- just that we should take baby steps. "Hey, this changed" is simpler on a whole lot of dimensions than "Hey, this changed and here's the new state." It's more general, too. jb
On Fri, 1 Feb 2002, Jeff Bone wrote:
> Since when is creating the "listener" the Subscribable entity's responsibility? (I
> assume by listener you mean the client-side interface onto which notifications are
> dispatched, i.e. the "observer" or what we've been calling the "Subscriber.")
OIC. We are having a miscommunication.
The scenario I am describing is one in which the
client has some intermediary that takes care of
listening for notification messages (that hosts
listeners). So the listener is owned by the
client not by the "subscribable entity."
I imagine a workflow that looks something like
this:
1. client PUTS listener at
http://intermediary.com/~client/subcription1
2. client PUTS another listener at
http://intermediary.com/~client/subcription2
3. client requests notifications on http://foo.com
to be deliverd to the subscription1 URL.
4. client requests notifications on http://goo.com
to be delivered to the subscription2 URL.
5. intermediary.com recieved NOTIFY messages at
http://intermediary.com/~client/subcription1
http://intermediary.com/~client/subcription2
http://intermediary.com/~client/subcription1
in all of these cases intermediary responds
with non 40x status codes
6. client requests changes by e.g.
http://intermediarty.com/getLogs?user=client
7. client decides that foo.com info is really
important and would like to be sent a page
when foo.com changes. Client issues a POST
to
http://intermediary.com/~client/subcription1
8. client is no longer interested in goo.com and
does
DELETE http://intermediary.com/~client/subcription2
9. intermdiary recieves another NOTIFY message at
http://intermediary.com/~client/subcription2
and now responds with a 404 Not Found.
10 the notification server sees that there is now
no listener and deletes the subscription for
http://intermediary.com/~client/subcription2
Do you see why a separate listener manager makes
no sense?
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
Jeff Bone wrote: > >... > > Consider that a subscriber is really in a sense a cache for the subscribed > resource. Be careful there...if this is true then we get back to treating PUT as PUSH CONTENT and POST as PUSH DELTA. > ... > Using such information would permit caches to avoid extraneous GET / refresh > operations. Consider: notification to a list of subscribers is likely to take > time. A subscribed resource changes. During the notification process but > before a particular subscriber is notified, that subscriber does a GET and > obtains the current representational state. They then receive a notification > that the state is changed, but in fact they have the current and correct state. Will this happen often enough to worry about? Why would the client do a GET before it is notified? Maybe just dumb luck. Maybe clairvoyance. Neither seem important enough to worry about. > This is important for servers because it lightens the GET load when things > change; But maybe standard caching handles that. The client gets a notification of a change. It asks its local caching proxy for the document. The caching proxy uses all of the standard HTTP voodoo to say whether its local copy is fresh "enough". On the other hand, the etag might be useful to let the client push through the proxy and really get the latest version if necessary. This is the more compelling use-case for me. The client says to its local caching proxy: "I just got this notification that version X of a resource is available. Please give me a version that is at least that recent." >... it's important both for servers and traditional proxy caches as it can > potentially significantly reduce the burden of keeping the cache fresh. It's > important to clients because, as mentioned, clients are conceptually nothing > more than specialized caches; the benefits to proxies apply as well to clients. I don't mind having optimizations as a SHOULD. They are best practices that clients and intermediaries do not rely upon but may use to improve performance. Arguably, all optimizations should be MAY or SHOULD. If you want to write this up as an optimization SHOULD or MAY, I'd buy it. Paul Prescod
"S. Alexander Jacobson" wrote: > On Fri, 1 Feb 2002, Jeff Bone wrote: > > Since when is creating the "listener" the Subscribable entity's responsibility? (I > > assume by listener you mean the client-side interface onto which notifications are > > dispatched, i.e. the "observer" or what we've been calling the "Subscriber.") > > OIC. We are having a miscommunication. > The scenario I am describing is one in which the > client has some intermediary that takes care of > listening for notification messages (that hosts > listeners). So the listener is owned by the > client not by the "subscribable entity." We're cool. This is useful. I just think we shouldn't necessarily specify listener management in the same context as just plain notifications. With you all the way to (6) with the exception that we aren't assuming NOTIFY, we're assuming POST. > 6. client requests changes by e.g. > http://intermediarty.com/getLogs?user=client > Resource model alert! I have no idea what this means. ;-) > 7. client decides that foo.com info is really > important and would like to be sent a page > when foo.com changes. Client issues a POST > to > http://intermediary.com/~client/subcription1 I think that this has to be something other than POST, as the POST on that resource indicates changes on http://foo.com. > 8. client is no longer interested in goo.com and > does > DELETE http://intermediary.com/~client/subcription2 No problem. > 9. intermdiary recieves another NOTIFY message at > http://intermediary.com/~client/subcription2 > and now responds with a 404 Not Found. Fine, with the exceptions noted above. Can't assume NOTIFY. It's a bad idea, because not all resources are listeners. jb
"S. Alexander Jacobson" wrote: > >... > > 1. client PUTS listener at > http://intermediary.com/~client/subcription1 > > 2. client PUTS another listener at > http://intermediary.com/~client/subcription2 > > 3. client requests notifications on http://foo.com > to be deliverd to the subscription1 URL. > > 4. client requests notifications on http://goo.com > to be delivered to the subscription2 URL. I see these steps very differently. In particular I see the first two steps as being unnecessary extra coordination headache. Listeners are not files. Practically speaking the component that implements a listener is a CGI-alike. It looks like: http://intermediary.com/listener.cgi?user=paulp Now without any further coordination with the intermediary, I can go all over the Web registering URIs like: http://intermediary.com/listener.cgi?user=paulp&site=http://www.slashdot.org http://intermediary.com/listener.cgi?user=paulp&site=http://www.news.com http://intermediary.com/listener.cgi?user=paulp&site=http://www.slate.com ... The listeners are dynamically created. Or they are in theory "always there" like every possible Google query is a resource that is always available. I configure these by fiddling with listener.cgi, maybe through a web page. For instance I might tell it to reject notifications from particular domains or the opposite, reject notifications from domains I haven't told you about. Or reject notifications that don't have a magic cookie header. Generally you would manage subscriptions in bulk, not per-URI, although you could of course do that too if listener.cgi happens to support it. Paul Prescod
On Fri, 1 Feb 2002, Jeff Bone wrote: > We're cool. This is useful. I just think we shouldn't necessarily specify listener > management in the same context as just plain notifications. With you all the way to (6) > with the exception that we aren't assuming NOTIFY, we're assuming POST. I agree we should not be specifying listener management. That is why I want notification to be a distinct method (so as not to get confused with whatever listener management the client implements). If I understand you correctly, the only issue here is whether the new method should be one for the client to update the state of the listener or whether it should be to notify the listener of a change to the subscribed resource. I think that it is more natural to use POST to modify the listener (because we don't want to write a listener management spec). However, you don't like NOTIFY because it only applies to listener URLs and not all URLs are listener URLs. So, my question to you is whether all HTTP methods have to apply to all resources. The spec has various 50x status codes, like 501 Not Implemented or 503 Service Unavailable that I think make it OK to define methods that don't apply to all resources. > > 6. client requests changes by e.g. > > http://intermediarty.com/getLogs?user=client > > > > Resource model alert! I have no idea what this means. ;-) Yeah. Me neither. My point is simply that the client uses the intermediary to retrieve all of its notifications. I am not trying to specify that interface. Just provide a simple example. > > 7. client decides that foo.com info is really > > important and would like to be sent a page > > when foo.com changes. Client issues a POST > > to > > http://intermediary.com/~client/subcription1 > > I think that this has to be something other than POST, as the POST on that resource > indicates changes on http://foo.com. As I said above, I don't see why we can't use NOTIFY to indicate a change on http://foo.com and leave POST for the listener to manage itself in the normal HTTP way. (Otherwise you start defining a listener management protocol) > Can't assume NOTIFY. It's a bad idea, because > not all resources are listeners. See above. Why does that matter? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Fri, 1 Feb 2002, Paul Prescod wrote: > Generally you would manage subscriptions in bulk, not > per-URI, although you could of course do that too if listener.cgi > happens to support it. Paul, This is also a good way to do listener management. If you want to be promiscuous, go right ahead. My point is simply to leave flexibility for the client to manage the listener however it wants. I think the only way to do that is to use an explicit NOTIFY method (or methods). -Alex- PS My gut also says that NOTIFY really means something quite distinct from POST. In particular, POST says something about a resource is to be changed in some way. NOTIFY signals that the change has already happened. ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Paul Prescod wrote: > Jeff Bone wrote: > > > >... > > > > Consider that a subscriber is really in a sense a cache for the subscribed > > resource. What I really mean here is this: HTTP is REpresentational State Transfer. This is orthogonal in some respects to whether it's push or pull. Independent of that, the basic idea is that state is transferred from origins to others; those others then do things with that state. So in essence it's an object migration protocol for arbitrary representations of object state, and everybody but the origin server receives / maintains / caches one of these representations in order to act on it. Even a browser can be viewed as a cache with a pretty face. What we're really adding with HttpEvents is an optional cache invalidation protocol which operates via HTTP and for which both sides present a resource-based and HTTP-appropriate interface. > Be careful there...if this is true then we get back to treating PUT as > PUSH CONTENT and POST as PUSH DELTA. Not necessarily. As mentioned, I'm in favor of treating notifications as just that, strictly that from the perspective of HttpEvents: a notification that change has happened. It's up to the client to get the state. Pushing state is an optimization. (As an optimization, though, it seems that treating those methods that way might be appropriate in some contexts, but the negotiation details seem hairy so we should leave it alone. > Will this happen often enough to worry about? Why would the client do a > GET before it is notified? Maybe just dumb luck. Maybe clairvoyance. > Neither seem important enough to worry about. This kind of argument scares me. ;-) Seriously, I see no harm in having the origin server provide a timestamp with each state-change notification that says "state changed at this time." Seems to me there's no downside. (Or, alternatively, not a timestamp but a fingerprint, etc. Just something to let the subscriber check their current representation state against the origin state.) > But maybe standard caching handles that. The client gets a notification > of a change. It asks its local caching proxy for the document. The > caching proxy uses all of the standard HTTP voodoo to say whether its > local copy is fresh "enough". That's true --- but what if the client is itself an intermediary? :-) > I don't mind having optimizations as a SHOULD. They are best practices > that clients and intermediaries do not rely upon but may use to improve > performance. Arguably, all optimizations should be MAY or SHOULD. If you > want to write this up as an optimization SHOULD or MAY, I'd buy it. Okay, I haven't come up with a use case for why this should be a MUST, so I'm willing to let it be optional. jb
"S. Alexander Jacobson" wrote: > I agree we should not be specifying listener > management. That is why I want notification to be > a distinct method (so as not to get confused with > whatever listener management the client > implements). The problem with this is that (a) *new methods impose unnecessary adoption friction*, and (b) *NOTIFY to a listener is not a reasonable part of the generic interface of resources, as not all resources can be listeners.* New methods should only be created for generic operations that are universally meaningful to all potential resources. > However, you don't like NOTIFY because it only > applies to listener URLs and not all URLs are > listener URLs. > > So, my question to you is whether all HTTP methods > have to apply to all resources. I believe this to be the case. Whether or not a particular resource supports a particular method should be an authorization concern, not an interface concern. Truly universal generic interfaces have LOTs of benefits; introducing new type-specific interfaces for certain resource types is a slippery slope toward losing all the benefits of genericity. > As I said above, I don't see why we can't use > NOTIFY to indicate a change on http://foo.com > and leave POST for the listener to manage itself > in the normal HTTP way. Let me think about this. The argument for is that this already exists for proxy caches; the argument against is that reusing it for this purpose may confuse the issue, *and* it's not clear that it's generic enough. Maybe it doesn't break things. Let me digest this. We're getting awfully close to the same problem as notification for proxy caches with all of this... hmmm.... jb
On Fri, 1 Feb 2002, Jeff Bone wrote: > > I agree we should not be specifying listener > > management. That is why I want notification to be > > a distinct method (so as not to get confused with > > whatever listener management the client > > implements). > > The problem with this is that (a) *new methods impose unnecessary adoption friction*, That was MY argument before. YOU pursuaded me that new methods are OK. If you want, I can go rehash YOUR arguments :-) > and (b) > *NOTIFY to a listener is not a reasonable part of the generic interface of resources, as not > all resources can be listeners.* Yeah, thats what I think we are disagreeing about. > New methods should only be created for generic operations > that are universally meaningful to all potential resources. I don't think LOCK works on all resources. I don't think POST makes sense for static files. > I believe this to be the case. Whether or not a particular resource supports a particular > method should be an authorization concern, not an interface concern. How do you explain the differences between: 401 Unauthorized 403 Forbidden 405 Method Not Allowed 501 Not Implemented 503 Service Unavailable It certainly seems like the HTTP spec contemplates new non-universal methods. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > > A list of URIs is too limiting - it may not be practical or possible > to enumerate them all... That's just from Pauls example. However, is it a 'web collection' is the things inside aren't first-class resources (uri addressable)? > > > > On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote: > > > > ----- Original Message ----- > > From: "Paul Prescod" <paul@...> > > > > > > > > I've clarified my thoughts on how to handle notifications for > > > collections. Collections are just documents that happen to contain URIs > > > to other documents. Just hang a WATCH on that document. > > Woohoo! Yes, by george, you've got it! As a Groves dude, this should be > > pretty straightforward for you to work out the details of. > > And the resource (aka 'collection') may have metadata separate from the list > > of URIs - how do distinguish between the two? That's where the 'add/remove' > > comes from - they are 'updates' to the 'default collection' property. But > > that is all really too complex for now - I can build it in the app layer > > with the low level primitives. > > > > > >
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > FYI, celko describes a very nice way of managing > acyclic graphs using SQL without generating > bazillion queries. > > The trick is to treat subtrees as subsets and give > each node a left,right bound on the total number > of leaves. > > Very elegant and very inexpensive. Gave me a > whole new respect for the power of SQL. > Cool - I'll track that down sometime...
"S. Alexander Jacobson" wrote: > That was MY argument before. YOU pursuaded me > that new methods are OK. If you want, I can go > rehash YOUR arguments :-) This I can say with absolute certainty: you may have come to your conclusion based on something I said that you misinterpreted, but it has *never* been my position that new methods are a good thing, generally speaking. > I don't think LOCK works on all resources. I think LOCK the most bletcherous partial-birth abortion in DAV, so that's not a good example. > It certainly seems like the HTTP spec contemplates > new non-universal methods. No doubt. Lots of things have been "tried" in HTTP at various points, and there is quite a bit of ambiguity. My own REST quest is to try to discern what the minimal, diamond-like core of ideas within HTTP actually consists of; to figure out, to crib Paul, what the "lambda calculus"-like underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-) jb
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> I suggest that 'subscription' is a superset of 'listener' and 'route' - it is a relationship between 'source' and 'destination'. Your example has this - the 'destination' is http://intermediarty.com/getLogs?user=client (and what's 'get' doing in the uri??) If you want to tell the intermediary how to behave, use this uri (possibly qualified bythe subscription id) and not the public listener uri. > > I imagine a workflow that looks something like > this: > > 6. client requests changes by e.g. > http://intermediarty.com/getLogs?user=client >
----- Original Message ----- From: "S. Alexander Jacobson" <alex@...> > > PS My gut also says that NOTIFY really means > something quite distinct from POST. In > particular, POST says something about a resource > is to be changed in some way. NOTIFY signals that > the change has already happened. I agree.
On Fri, 1 Feb 2002, Jeff Bone wrote: > No doubt. Lots of things have been "tried" in HTTP at various points, and there is quite a bit of > ambiguity. My own REST quest is to try to discern what the minimal, diamond-like core of ideas > within HTTP actually consists of; to figure out, to crib Paul, what the "lambda calculus"-like > underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-) OK. I agree. Therefore I think the whole structure of the HTTPEvents spec is wrong. Clients that want notification should just open up a persistent GET on a watcher resource. The watcher resource just sends chunks whenever the watched resource changes. You and others made a compelling argument that this sort of architecture is very scalable so why not use it. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "Jeff Bone" <jbone@...> > > The problem with this is that (a) *new methods impose unnecessary adoption friction*, and (b) > *NOTIFY to a listener is not a reasonable part of the generic interface of resources, as not > all resources can be listeners.* New methods should only be created for generic operations > that are universally meaningful to all potential resources. > What does it mean to POST to an HTML file? It isn't meaningful. It /might/ be meaningful if you craft a server to do something - but then so would NOTIFY.
On Fri, 1 Feb 2002, Jeff Bone wrote: > > It certainly seems like the HTTP spec contemplates > > new non-universal methods. > > No doubt. Lots of things have been "tried" in HTTP at various points, and there is quite a bit of > ambiguity. My own REST quest is to try to discern what the minimal, diamond-like core of ideas > within HTTP actually consists of; to figure out, to crib Paul, what the "lambda calculus"-like > underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-) Ok. If you don't want persistent GET, you have to make an argument why NOTIFY isn't right, rather than a general philsophical point. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
So just finished an afternoon reread of Ari Luotonen's book, hadn't looked at it in a couple of years; also some material online. I've *almost* convinced myself that HttpEvents as we are currently discussing them are mostly extraneous. I'm going to say some things about my understanding of the current very rough but gradually converging consensus, then lay out the strawman for why this approach is unnecessary. It's a straw man, whack away. CURRENT CONSENSUS: An HttpEvents protocol could be any one of or combination of things. It might be (1) simply a state-change notification protocol, (2) a push-based state replication protocol, or (3) a subscription / listener management protocol. It appears that we are generally converging on (1), viewing (2) as either an optimization or application-specific or both, and (3) as interesting but somewhat out-of-scope for this spec. (We are talking about reifying subscribers and subscriptions, but pushing out "listener management" etc.) Is that about right? If so, then we may be spinning our wheels somewhat; various folks did a fair bit of work on NOTIFY back in the early days [1] in the context of proxy cache notification and in the course of the HTTP-NG discussions. Not sure what the current state of NOTIFY is; did it ever go anywhere? I apologize if there's an obvious answer to this, as my own "cache" of HTTP caching-related information is a bit stale. No mention of NOTIFY / this draft in Ari's 1998 book, and very little I can find via Google. BUT... [1] describes a protocol extension (with a "new" method, NOTIFY) that solves (1) in a very HTTPish way. It doesn't reify subscriptions, but it doesn't have to --- it appears that subscriptions are at-most-once commitments to notify the subscriber that the state of a resource has changed, for the purpose of cache invalidation. Renewal of the subscription appears to happen incrementally --- the subscription "expires" after the first notification, and is "renewed" on the subsequent GET (if any) that happens to refresh the cache after the notification is received. The more I think about this, the more elegant it seems. Here's how this protocol could be used to accomplish (1): CLIENT -> SERVER ---------------------- GET /foo HTTP/1.1 Accept: text/html Proxy-Features: my.host.com; notify (Note that we're "pretending" to be our own proxy server cache. We're requesting notification of state change on the resource if it's available.) SERVER -> CLIENT --------------------- 201 OK Cache-Control: notify Content-Type: text/html ...text... (The SERVER responds and says, among other things, that it is willing to notify (via the Cache-Control directive) the CLIENT at-most-once (?) that the resource has changed by possibly emitting a NOTIFY for that resource to the CLIENT at some later date.) Later on, when /foo changes, the SERVER initiates a connection back to CLIENT (the machine specified in Proxy-Features:, i.e. my.host.com) and sends notification that the state change occurred / the cached copy (if any) has expired: SERVER -> CLIENT --------------------- NOTIFY /foo HTTP/1.1 (Presumably the fully-qualified URI is somehow reconstructed from TCP connection data. This is gross and unworkable, so I would assume that instead NOTIFY is required to provide a fully-qualified URI.) The client CLIENT proceed to refresh its cache via a GET. At this point, the SERVER is presumably allowed to stop sending further notifications; in order to receive the next notification, the client parameterizes the GET so that it looks just like the first one. This cycle repeats, ad infinitum, as long as the CLIENT is interested in being updated about state changes on SERVER/foo: CLIENT -> SERVER ---------------------- GET /foo HTTP/1.1 Accept: text/html Proxy-Features: my.host.com; notify ...lather, rinse, repeat... DISCUSSION -------------- PROS: This seems generally workable. It avoids issues with management of subscriptions, etc. by its at-most-once notification semantics. (It's at-most-once in that notifications aren't guaranteed; the origin server may provide data to feed cache age and freshness calculations, and the client / proxy must use its own heuristics to determine whether to trust a cached object in the absense of a notification.) The net effect is the same as (1) in that clients receive state change notifications for particular objects. *** It also partially addresses Lucas' concern about state-leakage, in much the same manner that Lucas suggested; a notification client need only support the NOTIFY method. Responses to NOTIFY aren't described, but presumably a reasonable set of responses could be specified so that extra state isn't leaked in response to a NOTIFY. *** It also, as Alex notes, avoids complications with overloading the semantics of i.e. POST. CONS: As noted in [1], any point-to-point notification protocol suffers when there are a large number of parties interested in receiving notifications; the draft explicitly states that "clients should not attempt to use this facility as a matter of course" for that reason. IMO, we're no better or worse off in this regard with either [1] or HttpEvents as contemplated. There are some problems with this draft, such as the lack of fully qualifying the URI in the NOTIFY message --- how does the notification client know what the notification relates to? Also, the terminology is very proxy specific. It doesn't reify the notion of a subscription, but given a one-shot semantics I'm not sure this is necessary or even desirable. (!) :-/ TANGENTIAL ISSUES ------------------------ Most of the notification application scenarios I've been contemplating are actually made simpler by simply recasting them in terms of proxy cache invalidation and assuming something like the above. This does *not* specify any state replication / update by piggybacking the NOTIFY, nor does it address the issue of fan-out. It also doesn't address the issue of proxy fan-out, where a *request* to an intermediary needs to be fanned out to multiple origin servers, but that's a completely different topic and scenario. [1] http://www.w3.org/TR/WD-proxy
Good food for thought... going back through old bookmarks, came
across this talk by Jeffrey Mogul from USENIX '98. Interesting
POV on many things, not sure about some of the conclusions (i.e.,
the "not the only game in town" is / was definitely an academic
point
of view disconnected with commercial reality.)
http://www.usenix.org/events/usenix99/invited_talks/mogul.pdf
jb
> What does it mean to POST to an HTML file? It isn't meaningful. It /might/ > be meaningful if you craft a server to do something - but then so would > NOTIFY. You don't POST to an HTML file, you post to a resource represented by an HTML file. If that resource is mailing list, then POSTing adds a new message to it. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > >... > > CURRENT CONSENSUS: An HttpEvents protocol could be any one of or > combination of things. It might be (1) simply a state-change > notification protocol, (2) a push-based state replication > protocol, or (3) a subscription / listener management protocol. > It appears that we are generally converging on (1), viewing (2) > as either an optimization or application-specific or both, and > (3) as interesting but somewhat out-of-scope for this spec. (We > are talking about reifying subscribers and subscriptions, but > pushing out "listener management" etc.) You should separate listener management and subscription management. The latter is in scope because it is part of the relationship between publisher and subscriber. The former is not. > If so, then we may be spinning our wheels somewhat; various folks > did a fair bit of work on NOTIFY back in the early days [1] in > the context of proxy cache notification and in the course of the > HTTP-NG discussions. Not sure what the current state of NOTIFY > is; did it ever go anywhere? I apologize if there's an obvious > answer to this, as my own "cache" of HTTP caching-related > information is a bit stale. No mention of NOTIFY / this draft in > Ari's 1998 book, and very little I can find via Google. Mnot seems to think it is still a very open issue. (btw, we could have been more forthcoming with comments on his spec): * http://groups.yahoo.com/group/rest-discuss/message/292 Following some links he's provided, I'd say it is still under active standardization. >... >... > CONS: As noted in [1], any point-to-point notification protocol > suffers when there are a large number of parties interested in > receiving notifications; the draft explicitly states that > "clients should not attempt to use this facility as a matter of > course" for that reason. IMO, we're no better or worse off in > this regard with either [1] or HttpEvents as contemplated. First, it isn't sufficient to say: "Their spec doesn't scale but ours doesn't either." Second, I think that a subscription based spec is more amenable to optimization. If the publisher pushes enough information to the client that the client is "happy" then there is no need for a GET which avoids a GET-flood. I would expect this to be the common case. Consider implementing a chat program using only GETs and cache invalidation. You would double the latency, bandwidth usage etc. Paul Prescod
I like max-age. Suggest adding an expiration type of Date-relative. > -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Friday, February 01, 2002 12:28 PM > To: Rest-Discuss; Lucas Gonze > Subject: Re: [rest-discuss] Expiration > > > > ----- Original Message ----- > From: "Lucas Gonze" <lucas@...> > > > > * The prefix "Requested-" is redundant. Better wording would be > > "Expiration-Date" and "Expiration-Count". > Would 'max-age' (as applied to the messages) be relevant? > Also, how would you ask for messages from the past (if you had a system with > an 'audit trail'/history)? > The KnowNow stuff has a max-age parameter when creating a subscription, but > I haven't followed this 'expiration' discussion, so it might not be > relevant. > > > >
I find your comments here extremely sensible, parsimonious, etc, and register a strong +1 for many if not all features of WD-Proxy. More detailed comments follow, but without having read the WD-Proxy spec in detail yet. Proxies ======= A proxy oriented approach has been a ghost in the backround of these conversations all along. I have stayed away from it because whenever I try to model the actual interactions using proxies I find an awkward fit in using proxies to do active work. The syntax of a request to a proxy is slightly different than the syntax of a request to a normal host. As a result the end application can't be a CGI script. I don't advocate that implementations should only ever be CGI, but rather that it must be possible for implementations to be CGI. I advocate this because of the huge boost to adoption that CGI enables -- the backdoor is often the only door for new technology. Now, there's a question of whether most servers will accept a proxy request where the Host: header is their own domain. I tested this just now by setting my proxy server to yahoo.com and requesting http://www.yahoo.com. When I set my proxy as a user preference in Opera, I got back a 200 OK but no content. When I set Opera to use Muffin as a proxy, then set Muffin to use Yahoo as a proxy, then requested yahoo.com (as well as hotmail.com) I got successful test results. ...inconclusive, obviously. A question: to what degree is a request to a proxy a legal request to an endpoint server? A really great reason to use a proxy approach is that proxies can already handle the request-in-request pattern. One-shots ========= I haven't been able to think of a problem with one-shot notifications, and I have been able to think of advantages. So I am a strong +1 for this. NOTIFY method ============= I am strongly against new methods. For one, they're about as un-REST as you can get. For another, they make adoption a long, slow, painful process. Any design that requires new methods will be adopted at tenth the pace of one that doesn't. If the HTTP Events spec ends up requiring new methods, I will almost certainly fork and make a version that enables implementations to avoid new methods. WD-proxy uses an orthogonal header for the request: proxy-option= "notify" | "loging" | log This is a really good solution. Any other approach requires the request to contain both a request method and a watched resource method. That's r-i-r, and whenever I see r-i-r I see a problematic solution. ...R-i-r is something like an infinity -- whenever a design leads you to an infinity you should question your approach. It's not that RIR is evil, just that it's best avoided until somebody does a careful analysis/cookbook for making it work. > So just finished an afternoon reread of Ari Luotonen's book, > hadn't looked at it in a couple of years; which book, Jeff? > also some material > online. I've *almost* convinced myself that HttpEvents as we are > currently discussing them are mostly extraneous. I'm going to > say some things about my understanding of the current very rough > but gradually converging consensus, then lay out the strawman for > why this approach is unnecessary. It's a straw man, whack away. *whack* *whack* :) IMO WD-proxy is good but not quite there. Let's finish the job -- http://www.janeylee.com/oldhome/mmbattle.au !!!!! - Lucas
Paul Prescod wrote: > You should separate listener management and subscription management. The > latter is in scope because it is part of the relationship between > publisher and subscriber. The former is not. Fair enough. > First, it isn't sufficient to say: "Their spec doesn't scale but ours > doesn't either." I'm not sure why not. ;-) Point being, there are still some serious things to think about with both -wrt- scaling. IMO, in order to get scale we're going to have to do one of two things, one trivial, one hard. The trivial solution is to leave it up to the origin server to stop accepting requests for state notification at whatever level that server thinks is its scaling limit and / or manage generation of notifications at an appropriate rate. The hard solution is to figure out how to fan out that notification from the origin server through an arbitrary number of intermediaries. > Second, I think that a subscription based spec is more amenable to > optimization. If the publisher pushes enough information to the client > that the client is "happy" then there is no need for a GET which avoids > a GET-flood. I would expect this to be the common case. Quite possibly, but it seems this is both an optimization and, it would seem, compatible with the basic idea. (The basic idea is that rather than long-lived subscriptions that have to be managed you instead use traditional cache age / freshness heuristics and an at-most-once or one-shot invalidation notification.) Second, it's important to note that the mechanism for scaling and balance is *better understood* in a GET + one-shot invalidation scenario than in a pure push scenario. The origin server can avoid GET storms by simply interleaving invalidation notifications with servicing the correspondig GETs, no > Consider implementing a chat program using only GETs and cache > invalidation. You would double the latency, bandwidth usage etc. The more I think about it, the more convinced I am that this type of app is most suited for a long-running GET rather than either fine-grained events with state or cache invalidation. jb
Lucas Gonze wrote: > A proxy oriented approach has been a ghost in the backround of these > conversations all along. I have stayed away from it because whenever I try to > model the actual interactions using proxies I find an awkward fit in using > proxies to do active work. The syntax of a request to a proxy is slightly > different than the syntax of a request to a normal host. BTW, if it wasn't clear, I wasn't actually suggesting that using an actual intermediary in this capacity. Rather, I was suggesting that something like WD-Proxy's notification scheme be generalized so that the notification receiver is topology-independent; every Web application can in some sense be viewed as a "cache" for representations elsewhere, and the problem of maintaining current state in that cache can be aided by active cache invalidation. > As a result the end > application can't be a CGI script. I don't advocate that implementations should > only ever be CGI, but rather that it must be possible for implementations to be > CGI. I advocate this because of the huge boost to adoption that CGI enables -- > the backdoor is often the only door for new technology. Hmmm. Does it really matter? After all, all we're doing is sending a message back to the client that says "come and get it again." There's no reason "it" can't be a CGI. Is there? Clearly, we can't cache POST results, but... (btw, thinking about this using the proxy / cache control terminology does confuse the issue. You're not really proxying if you make the request yourself, obviously, and you're not really caching something if you get it, look at it / use it for something, then toss it.) > One-shots > ========= > > I haven't been able to think of a problem with one-shot notifications, and I > have been able to think of advantages. So I am a strong +1 for this. This IMO is the real meat of the deal. I think it's HUGELY advantageous. > NOTIFY method > ============= > > I am strongly against new methods. For one, they're about as un-REST as you can > get. For another, they make adoption a long, slow, painful process. Any design > that requires new methods will be adopted at tenth the pace of one that doesn't. > If the HTTP Events spec ends up requiring new methods, I will almost certainly > fork and make a version that enables implementations to avoid new methods. In general I agree. There are some "pros," though. I thought you'd like this, as it does allow client implementations to support a *very* minimal protocol --- they only need to accept NOTIFY on port 80. IMO, that's cleaner than overloading standard HTTP method (GET) and using an older and much laxer version of the HTTP spec. > WD-proxy uses an orthogonal header for the request: > proxy-option= "notify" | "loging" | log > > This is a really good solution. I think you need to read the spec, I don't think it does what you think. ;-) > > So just finished an afternoon reread of Ari Luotonen's book, > > hadn't looked at it in a couple of years; > > which book, Jeff? Ari was head of server development at CERN back in the day, then ran proxy development at Netscape. His book "Web Proxy Servers" [1] is one of the classics; it was released in about '98. A lot of the information is now out of date, but it's still worth a read. Note that it doesn't talk about WD-Proxy, but it does have a great explanation of the various age / freshness tradeoffs and algorithms. jb [1] http://www.amazon.com/exec/obidos/ASIN/0136806120/
> ----- Original Message ----- > From: "S. Alexander Jacobson" <alex@...> > > > > > PS My gut also says that NOTIFY really means > > something quite distinct from POST. In > > particular, POST says something about a resource > > is to be changed in some way. NOTIFY signals that > > the change has already happened. > > I agree. I don't. The resource identified by the callback URI can be whatever the subscriber wants it to be. If it's a semaphore, then PUT or POST is fine. If it's a mailbox, then POST is good. I dare you to try and choose a resource that's used to receive notifications that can't receive them with PUT or POST. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I think we are converging on your (1), state- change-notification/cache-invalidation. I also am beginning to think that this whole discussion is extraneous; that people who want notification should just use persistent GET. The main argument against persistent GET for notification is that clients and servers are forced to hold open potentially large numbers of TCP connections (and this is expensive). However: 1. There is no evidence that open TCP connections really consume that many more resources than subscriptions. The only difference is that OSs typically don't allow TPC connections to be stored on disk, but I don't think that is something we need be concerned with. (I could imagine unused connections being swapped to virtual memory (or people can just buy more memory). 2. Holding open a persistent GET consumes less bandwidth than establishing two HTTP connections and sending NOTIFY in one reuest and a repeat of the actual content in the other. 3. Persistent GET is much more in the spirit of HTTP than asynchronous notifications. I think, unless you can make a good argument against Persistent GET, there is no real need for the HttpEvents spec. That being said, it might be useful to establish a standard format for this Persistent GET for cache invalidation or for replication or for security monitoring, but I don't see any value in HttpEvents that persistent GET does not better provide. -Alex- On Fri, 1 Feb 2002, Jeff Bone wrote: > > So just finished an afternoon reread of Ari Luotonen's book, > hadn't looked at it in a couple of years; also some material > online. I've *almost* convinced myself that HttpEvents as we are > currently discussing them are mostly extraneous. I'm going to > say some things about my understanding of the current very rough > but gradually converging consensus, then lay out the strawman for > why this approach is unnecessary. It's a straw man, whack away. > > CURRENT CONSENSUS: An HttpEvents protocol could be any one of or > combination of things. It might be (1) simply a state-change > notification protocol, (2) a push-based state replication > protocol, or (3) a subscription / listener management protocol. > It appears that we are generally converging on (1), viewing (2) > as either an optimization or application-specific or both, and > (3) as interesting but somewhat out-of-scope for this spec. (We > are talking about reifying subscribers and subscriptions, but > pushing out "listener management" etc.) > > Is that about right? > > If so, then we may be spinning our wheels somewhat; various folks > did a fair bit of work on NOTIFY back in the early days [1] in > the context of proxy cache notification and in the course of the > HTTP-NG discussions. Not sure what the current state of NOTIFY > is; did it ever go anywhere? I apologize if there's an obvious > answer to this, as my own "cache" of HTTP caching-related > information is a bit stale. No mention of NOTIFY / this draft in > Ari's 1998 book, and very little I can find via Google. > > BUT... > > [1] describes a protocol extension (with a "new" method, NOTIFY) > that solves (1) in a very HTTPish way. It doesn't reify > subscriptions, but it doesn't have to --- it appears that > subscriptions are at-most-once commitments to notify the > subscriber that the state of a resource has changed, for the > purpose of cache invalidation. Renewal of the subscription > appears to happen incrementally --- the subscription "expires" > after the first notification, and is "renewed" on the subsequent > GET (if any) that happens to refresh the cache after the > notification is received. > > The more I think about this, the more elegant it seems. > > Here's how this protocol could be used to accomplish (1): > > CLIENT -> SERVER > ---------------------- > GET /foo HTTP/1.1 > Accept: text/html > Proxy-Features: my.host.com; notify > > (Note that we're "pretending" to be our own proxy server cache. > We're requesting notification of state change on the resource if > it's available.) > > SERVER -> CLIENT > --------------------- > 201 OK > Cache-Control: notify > Content-Type: text/html > > ...text... > > (The SERVER responds and says, among other things, that it is > willing to notify (via the Cache-Control directive) the CLIENT > at-most-once (?) that the resource has changed by possibly > emitting a NOTIFY for that resource to the CLIENT at some later > date.) > > Later on, when /foo changes, the SERVER initiates a connection > back to CLIENT (the machine specified in Proxy-Features:, i.e. > my.host.com) and sends notification that the state change > occurred / the cached copy (if any) has expired: > > SERVER -> CLIENT > --------------------- > NOTIFY /foo HTTP/1.1 > > (Presumably the fully-qualified URI is somehow reconstructed from > TCP connection data. This is gross and unworkable, so I would > assume that instead NOTIFY is required to provide a > fully-qualified URI.) > > The client CLIENT proceed to refresh its cache via a GET. At > this point, the SERVER is presumably allowed to stop sending > further notifications; in order to receive the next > notification, the client parameterizes the GET so that it looks > just like the first one. This cycle repeats, ad infinitum, as > long as the CLIENT is interested in being updated about state > changes on SERVER/foo: > > CLIENT -> SERVER > ---------------------- > GET /foo HTTP/1.1 > Accept: text/html > Proxy-Features: my.host.com; notify > > ...lather, rinse, repeat... > > DISCUSSION > -------------- > > PROS: This seems generally workable. It avoids issues with > management of subscriptions, etc. by its at-most-once > notification semantics. (It's at-most-once in that notifications > aren't guaranteed; the origin server may provide data to feed > cache age and freshness calculations, and the client / proxy must > use its own heuristics to determine whether to trust a cached > object in the absense of a notification.) The net effect is the > same as (1) in that clients receive state change notifications > for particular objects. *** It also partially addresses Lucas' > concern about state-leakage, in much the same manner that Lucas > suggested; a notification client need only support the NOTIFY > method. Responses to NOTIFY aren't described, but presumably a > reasonable set of responses could be specified so that extra > state isn't leaked in response to a NOTIFY. *** It also, as Alex > notes, avoids complications with overloading the semantics of > i.e. POST. > > CONS: As noted in [1], any point-to-point notification protocol > suffers when there are a large number of parties interested in > receiving notifications; the draft explicitly states that > "clients should not attempt to use this facility as a matter of > course" for that reason. IMO, we're no better or worse off in > this regard with either [1] or HttpEvents as contemplated. There > are some problems with this draft, such as the lack of fully > qualifying the URI in the NOTIFY message --- how does the > notification client know what the notification relates to? Also, > the terminology is very proxy specific. It doesn't reify the > notion of a subscription, but given a one-shot semantics I'm not > sure this is necessary or even desirable. (!) :-/ > > TANGENTIAL ISSUES > ------------------------ > > Most of the notification application scenarios I've been > contemplating are actually made simpler by simply recasting them > in terms of proxy cache invalidation and assuming something like > the above. This does *not* specify any state replication / > update by piggybacking the NOTIFY, nor does it address the issue > of fan-out. It also doesn't address the issue of proxy fan-out, > where a *request* to an intermediary needs to be fanned out to > multiple origin servers, but that's a completely different topic > and scenario. > > > > > [1] http://www.w3.org/TR/WD-proxy > > > > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
per Alex: > The main argument against persistent GET for > notification is that clients and servers are > forced to hold open potentially large numbers of > TCP connections (and this is expensive). ... > I think, unless you can make a good argument > against Persistent GET, there is no real need > for the HttpEvents spec. Edges are able to receive email events from a very large number of people -- persistent GET with all of them is not doable on any machine ever built, much less a desktop machine. It would amount to an NxN matrix of open connections between every possible sender/recipient pair. Ok, ok, I realize that you were talking about persistent GET between edge nodes and server-class sponsor machines. :) a couple problems with this approach: * Many people own perfectly capable desktop machines with good connectivity. For them to pay someone else to sponsor their connections is a waste. * The servers at the center of a persistent-GET topography would still need notifications. The persistent GET at the last mile wouldn't have anything to persistently GET otherwise. That said, I agree that persistent GET is the one solution for nodes behind firewalls. ...both persistent GET and http notifications are needed. > That being said, it might be useful to establish a > standard format for this Persistent GET for cache > invalidation or for replication or for security > monitoring, This would be a useful project, assuming that KnowNow's format isn't already there, and even if KN is already there it would still be productive to send their stuff through the standards process. - Lucas
I think that persistent GET, http notifications, and http updates are complementary projects. Hopefully people working on these can find *cough* synergies.
On Sat, 2 Feb 2002, Lucas Gonze wrote: > Edges are able to receive email events from a very large number of people -- > persistent GET with all of them is not doable on any machine ever built, much > less a desktop machine. It would amount to an NxN matrix of open connections > between every possible sender/recipient pair. Just to be clear, we are talking about subscriptions not email. Recipients need only recieve events from the places to which they subscribe. Servers need only handle as many connections as they have subsciptions. Recipients dont' subscribe to all servers and servers don't have subscriptions from all possible recipients. So persistent GET does NOT result in an NxM connection matrix. > * Many people own perfectly capable desktop machines with good connectivity. > For them to pay someone else to sponsor their connections is a waste. Why would they pay someone else? Why not just open connections to the relevent servers whenever they connect? Edge class machines probably won't have too many subscriptions in any case. > * The servers at the center of a persistent-GET topography would still need > notifications. The persistent GET at the last mile wouldn't have anything to > persistently GET otherwise. Why? The server exposes a URL that represents the stream of notification messages. > That said, I agree that persistent GET is the one solution for nodes behind > firewalls. ...both persistent GET and http notifications are needed. Again, I don't see why. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I don't think there is a coherent generic http update spec. As I said, I don't see the justification for http notification. The only thing that makes sense is various protocols that run over persistent GET. -Alex- On Sat, 2 Feb 2002, Lucas Gonze wrote: > I think that persistent GET, http notifications, and http updates are > complementary projects. Hopefully people working on these can find *cough* > synergies. > > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> BTW, if it wasn't clear, I wasn't actually suggesting that using an actual > intermediary in this capacity. Rather, I was suggesting that something like > WD-Proxy's notification scheme be generalized so that the > notification receiver is > topology-independent; Got it. That's an important distinction. > Hmmm. Does it really matter? After all, all we're doing is sending > a message back > to the client that says "come and get it again." There's no reason > "it" can't be a > CGI. Is there? -- Just to clarify, I was thinking about the source side of things rather than the sink side. > > One-shots > > ========= > > > > I haven't been able to think of a problem with one-shot notifications, and I > > have been able to think of advantages. So I am a strong +1 for this. > > This IMO is the real meat of the deal. I think it's HUGELY advantageous. Is anybody on the list against one-shot notifications? Are there disadvantages not seen here? Speak now or hold your peace. I think that multiple-shot notifications are a sloppy way of introducing more information into the channel, so they're really a form of updates. For example you might use multiple shot notifications on an email account to allow the client to count the number of unread messages. That's useful, but flawed enough that I'd leave equivalent functionality to any http-updates project that may happen. Keep the scope of hEvents minimal enough to do a good job, and hopefully lay the groundwork for related projects like persistent GET and http-updates. > In general I agree. There are some "pros," though. I thought you'd > like this, as > it does allow client implementations to support a *very* minimal > protocol --- they > only need to accept NOTIFY on port 80. IMO, that's cleaner than overloading > standard HTTP method (GET) and using an older and much laxer version > of the HTTP > spec. Uh, pretty much _anything_ is cleaner than that. Actually, I've been thinking about PSP as two separate things munged together - a "mole" communications pattern and idempotent notifications. The mole pattern is that one party, a requester, has almost total control over the communications stream. The mole pattern has to use idempotent notifications, but idempotent notifications don't have to use the mole pattern. > > which book, Jeff? > > Ari was head of server development at CERN back in the day, then ran proxy > development at Netscape. His book "Web Proxy Servers" [1] is one of > the classics; > it was released in about '98. A lot of the information is now out of > date, but it's > still worth a read. Note that it doesn't talk about WD-Proxy, but it > does have a > great explanation of the various age / freshness tradeoffs and algorithms. > Oh, yeah, I remember that I was excited when it came out but slacked on actually getting it....
> I don't think there is a coherent generic http > update spec. Yeah, I was just thinking out loud about long term directions. There's no doubt in my mind that full-scale callbacks using HTTP for state replication are needed -- stuff like Mike D's "DELETED" flag and Paul's original "DIFF" callback argument. Idempotent notifications are way too limited in scope to do everything needed. They do one thing well, but that's all.
Another issue is that there is no "persistent GET". HTTP 1.1 assumes persistent connections by default, but that's not the same as assuming a streaming response returning notifications of state updates. You still need a way for the user to request these updates. KnowNow does this because all their URIs are topics that behave in a particular way. But that's not the case for an arbitrary URI. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Per Jeff's suggestion that notifications be one-shot firings that get renewed when the requester phones in to pick up the resource, much of the expiration language can go away. However there may still be a need to state the period of time in which a requester wants to receive that one notification. For example, an expiration date in the request and/or response. Since this is a minor issue I don't want to get bogged down in it. Here are the options: 1) no expiration date 2) expiration specified by requester and either accepted or denied by the responder. 3) hoped-for expiration sent in request and actual expiration sent in response. I lean towards #1 but don't have strong feelings. #3 is really not bad either. There is a secondary issue, even more trivial than the first, which is what the status code should be in the case of #2 above when the responder denies a request based on expiration field value in the request. I propose a new status code, 418 "Requested expiration unacceptable." I can't think of any damage this would cause, and extension codes are acceptable within the RFC. The reason to have a new status code is to allow clients to diagnose and repair the error. The best reason to support #1 is that expiration is irrelevant nit picking at this early stage, and just introduces complication. In the interest of finishing with this not very interesting feature, up or down votes for any of the above would be appreciated.
I do like the fact that one-shot notifications simplify subscription management out of existence. I haven't thought through all of the issues, but I'm worried about scalability and robustness. 1. it must be possible to be able to piggy-back resources (and/or deltas?) in notifications 2. it must be possible to re-subscribe in the response to a notification 3. the last point implies that the server must tell the client in the notification that it is "pre-authorized" for re-subscription. Paul Prescod
"S. Alexander Jacobson" wrote: > >... > > > I believe this to be the case. Whether or not a particular resource supports a particular > > method should be an authorization concern, not an interface concern. > > How do you explain the differences between: These three are authorization issues (with the last being the most precise): > 401 Unauthorized > 403 Forbidden > 405 Method Not Allowed These are implementation issues: > 501 Not Implemented > 503 Service Unavailable > > It certainly seems like the HTTP spec contemplates > new non-universal methods. The point isn't that the methods should be universal but that they be logically *generic*, not *specific* to a particular type of resource. You can PUT web pages, purchase orders, user IDs, shopping carts, and any other logical kind of thing. You can GET them. You can DELETE them. And you can extend them with POST. (as usual the definition of POST is more fuzzy than the others) If we make a new method NOTIFY, then it should also apply to web pages, purchase orders, user IDs, shopping carts, etc. Does that make sense? Maybe. Paul Prescod
On Sat, 2 Feb 2002, Mark Baker wrote: > I don't. The resource identified by the callback URI can be whatever > the subscriber wants it to be. If it's a semaphore, then PUT or POST > is fine. If it's a mailbox, then POST is good. I dare you to try and > choose a resource that's used to receive notifications that can't > receive them with PUT or POST. As I said this is really a gut level issue, but I think at very least you cannot use PUT. PUT is supposedly idempotent. That means that the result of two PUTs is the same as the result of one PUT. I don't think that is true of notifications. In particular, do two notifications mean that the original object changed once or that it changed twice? So the semantics of PUT are definitely wrong for notification. You obviously can use POST. But that is because POST has no meaning at all. It is used for queries (terroristornot.com), it is used for updates, it is even used to delete sometimes. Often POST actually results in the creation of new resources (e.g. adding stuff to a shopping basket). The choice of POST or NOTIFY boil down to how you distinguish between changing the behavior of a listener and interacting with it. There are three choices: 1. Use POST and define special content like a mime-header or body. This interferes with allowing arbitrary local management of listeners. 2. Use NOTIFY 3. Use a different URL for notification and listener management -- this is very non RESTy. All that being said, I don't, at this point, see a need for anything other than persistant GET. So this is all sort of moot. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sat, 2 Feb 2002, Mark Baker wrote:
> Another issue is that there is no "persistent GET". HTTP 1.1 assumes
> persistent connections by default, but that's not the same as assuming a
> streaming response returning notifications of state updates. You still
> need a way for the user to request these updates.
Thats fine, I think. If you offer notification,
you create URLs which represent the stream of
changes to some other URL (or collection of URLs).
The recipient then gets a chunk encoded stream of
update messages.
> KnowNow does this because all their URIs are topics that behave in a
> particular way. But that's not the case for an arbitrary URI.
Basically the "topic" is the set of changes to a
URL.
Here is what I think the GET Events Protocol
looks like:
1. The client PUTs a list of URLs on which it
wants notification to some location. (The client
may want to GET this list later and make changes).
2. The server replies CREATED and sends back a
location header with a notification URL at which
the client can recieve the notifications it just
requested.
3. The client GETs this notification URL.
4. The server sends a mime multipart
with each part being either:
* the new contents of each URL together with a
content-location header telling the client
the URL from which this data originates
-or-
* a message of content-type:
message/external-body; access-type="URL"
and the URL that changed.
-or-
* a message of content-type application/x-diff
(The content is some representation of just
the diff that the recipient can use to
recreate the original)
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
You don't need expiration if you use GET. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> As I said this is really a gut level issue, but I > think at very least you cannot use PUT. > PUT is supposedly idempotent. That means that the > result of two PUTs is the same as the result of > one PUT. > > I don't think that is true of notifications. > In particular, do two notifications mean that the > original object changed once or that it changed > twice? So the semantics of PUT are definitely > wrong for notification. The notification doesn't say whether the resource changed once or twice. It only means that the watched resource has a new state since the subscription was created. This is exactly the difference between updates and notifications. An update is for synchronization -- it tells you about the new state. A notification is for invalidation -- it tells you there is a new state.
On Sat, 2 Feb 2002, Paul Prescod wrote: > The point isn't that the methods should be universal but that they be > logically *generic*, not *specific* to a particular type of resource. > You can PUT web pages, purchase orders, user IDs, shopping carts, and > any other logical kind of thing. You can GET them. You can DELETE them. > And you can extend them with POST. (as usual the definition of POST is > more fuzzy than the others) Ok. The *generic* semantics of NOTIFY is to tell the server that the resource is now out-of-date. This is generic to all resources. Whether the server knows or cares to resolve the situation is an entirely separate question. This is very different from POST which tells the server that the target URL should change in some manner. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> I don't think that is true of notifications. > In particular, do two notifications mean that the > original object changed once or that it changed > twice? So the semantics of PUT are definitely > wrong for notification. So treat it as a semaphore; a resource that represents my interest in the resource. If it's "0", then I don't care. If it's "1", then I do care, and I'll go off and do my thing, then set it back to "0". That's all PUT. > You obviously can use POST. But that is because > POST has no meaning at all. It is used for > queries (terroristornot.com), it is used for > updates, it is even used to delete sometimes. > Often POST actually results in the creation of > new resources (e.g. adding stuff to a shopping > basket). I'm not singling you out here Alex, because others have said it, but POST has a *very* precise meaning. It's not fuzzy at all. All that's fuzzy is the implementation details of what it means for the POSTed thing to be processed. But that's implementation, not interface. The interface is quite clear. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Sun, 3 Feb 2002, Lucas Gonze wrote: > The notification doesn't say whether the resource changed once or twice. It > only means that the watched resource has a new state since the subscription was > created. Actually I now think it says even less. It says only that the resource is now out-of-date. The server may or may not know how to resolve the situation (e.g. it may retrieve the URL or it may tell someone else to deal with it) Either way telling the server that a resource is out-of-date is very different from using POST or PUT to change it. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> On Sun, 3 Feb 2002, Lucas Gonze wrote: > > The notification doesn't say whether the resource changed once or twice. It > > only means that the watched resource has a new state since the > subscription was > > created. > > Actually I now think it says even less. It says > only that the resource is now out-of-date. The > server may or may not know how to resolve the > situation (e.g. it may retrieve the URL or it may > tell someone else to deal with it) > > Either way telling the server that a resource is > out-of-date is very different from using POST > or PUT to change it. That is exactly right. A notification is not a way of pushing resources from source to sink. Anything that is about pushing resources from source to sink is an update.
> I do like the fact that one-shot notifications simplify subscription > management out of existence. I haven't thought through all of the > issues, but > I'm worried about scalability and robustness. > > 1. it must be possible to be able to piggy-back resources (and/or > deltas?) in notifications Need more info here to know what you mean. In general, if the notification contains anything but a TRUE value, it's an update. If the notification is used to push changed resources, including via deltas, then it is an update. I am very much for dealing with the need for updates, but not now. It's an entire layer of complexity. > > 2. it must be possible to re-subscribe in the response to a > notification agreed. > > 3. the last point implies that the server must tell the client in the > notification that it is "pre-authorized" for re-subscription. It seems safe to assume that the sink is pre-authorized to resubscribe often enough to consider it the default. Plus it doesn't really cause damage to have a re-subscribe fail. So it is parsimonious to leave authorization to the usual HTTP means, i.e. by having the source return 401 (Unauthorized) when the need arises to deny a sub request.
Mark Baker wrote: > I'm not singling you out here Alex, because others have said it, but > POST has a *very* precise meaning. It's not fuzzy at all. All that's > fuzzy is the implementation details of what it means for the POSTed > thing to be processed. But that's implementation, not interface. > The interface is quite clear. This is actually one of the main conceptual innovations of Roy's REST view of the world --- it's a bit of "defining away the problem," but the implementation / interface distinction is clean and useful. Think of it this way, Alex: on UNIX, we have files that are bit bags and files that represent active entities such as devices. We write to each of them via the same interface, and the interface semantics are the same. What happens as a result of that write differs depending on the particular "file." jb
Lucas Gonze wrote: > > ... > > > > 1. it must be possible to be able to piggy-back resources (and/or > > deltas?) in notifications > > Need more info here to know what you mean. In general, if the notification > contains anything but a TRUE value, it's an update. If the notification is used > to push changed resources, including via deltas, then it is an update. I'm trying to make a distinction here between the semantic content of the message and the literal content. The semantic content is "something changed." The literal content is often "oh, and by the way, you could do a GET to fetch it but in order to reduce network load I've inlined the value here for you. If you would rather ignore the inlined value, go ahead and do the GET. It's all the same to me." >... > > 3. the last point implies that the server must tell the client in the > > notification that it is "pre-authorized" for re-subscription. > > It seems safe to assume that the sink is pre-authorized to resubscribe often > enough to consider it the default. Sure, the default. But you're just reversing the question. Then the publisher must be able to tell the subscriber that it is NOT pre-authorized. > ... Plus it doesn't really cause damage to have > a re-subscribe fail. I strongly disagree. If I believe that I'm subscribed to a stock ticker but I'm not really, heads will roll. Resubscription is important! > ... So it is parsimonious to leave authorization to the usual > HTTP means, i.e. by having the source return 401 (Unauthorized) when the need > arises to deny a sub request. I don't follow. The NOTIFY message has the publisher as the requester and the client as the receiver. The response to the NOTIFY may have a header saying: "Please re-subscribe me." Now the server has no opportunity to report an error because the re-subscription "request" was in a "response". That's why the server should pre-authorize. Paul Prescod
On Sun, 3 Feb 2002, Mark Baker wrote: > I'm not singling you out here Alex, because others have said it, but > POST has a *very* precise meaning. It's not fuzzy at all. All that's > fuzzy is the implementation details of what it means for the POSTed > thing to be processed. But that's implementation, not interface. > The interface is quite clear. I was not really trying to attack the meaning of POST. My basic point is that using PUT or POST for notify requires a prior arrangement that the URL being PUT/POSTed refers to the URL being invalidated. However NOTIFY requires no prior arrangement and no subscription. It is just a communication from the client to the server telling the server that the page is out of date (and that it may want to do something about it). If you want to request notification from a server that is a totally separate protocol. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Lucas Gonze wrote: > > Either way telling the server that a resource is > > out-of-date is very different from using POST > > or PUT to change it. > > That is exactly right. A notification is not a way of pushing resources from > source to sink. Anything that is about pushing resources from source to sink is > an update. It also means that we can completely separate subscription from notification. NOTIFY is simply a method telling a server that a resource is out of date. The server may or may not know or care to resolve the situation. A client might also request that a server NOTIFY another SERVER under various conditions (a subscription), but that is a separate protocol. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Jeff Bone wrote: > Think of it this way, Alex: on UNIX, we have files that are bit bags and > files that represent active entities such as devices. We write to each of > them via the same interface, and the interface semantics are the same. What > happens as a result of that write differs depending on the particular "file." Ok. If we are going to analogize to UNIX. NOTIFY is like Make. If I know that a specific executable is out of date (or think it might be), I do Make file. The Make system knows how to check dependencies and will update the file if necessary. But the better analogy is that NOTIFY is like having a Refresh button that works on arbitrary servers rather than just Browser caches. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I don't understand the purpose of the whole notification scheme. It seems to have much complexity and little benefit over the GET Events protocol I described in (1). -ALex- (1) http://groups.yahoo.com/group/rest-discuss/message/612 ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
It is not complex, it is subtle. Implementation is trivial. > > I don't understand the purpose of the whole > notification scheme. It seems to have much > complexity and little benefit over the GET Events > protocol I described in (1). > > -ALex-
Either way. It is more expensive than GET events. With one shot notifications, you continually have a back request for another subscription. With GET Events, when you don't want events any more, you simply close the connection. -Alex- On Sun, 3 Feb 2002, Lucas Gonze wrote: > It is not complex, it is subtle. Implementation is trivial. > > > > > I don't understand the purpose of the whole > > notification scheme. It seems to have much > > complexity and little benefit over the GET Events > > protocol I described in (1). > > > > -ALex- > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Yes, the need for back requests in one shot notifications means that they are too inefficient for some applications. Just like HTTP/XML/text encodings/non-kernel applications/etc are too inefficient for some applications. > Either way. It is more expensive than GET events. > With one shot notifications, you continually have > a back request for another subscription. > > With GET Events, when you don't want events any > more, you simply close the connection. > > -Alex-
"S. Alexander Jacobson" wrote: > On Sun, 3 Feb 2002, Jeff Bone wrote: > > Think of it this way, Alex: on UNIX, we have files that are bit bags and > > files that represent active entities such as devices. We write to each of > > them via the same interface, and the interface semantics are the same. What > > happens as a result of that write differs depending on the particular "file." > > Ok. If we are going to analogize to UNIX. NOTIFY > is like Make. > > If I know that a specific executable is out of > date (or think it might be), I do Make file. > The Make system knows how to check dependencies > and will update the file if necessary. > > But the better analogy is that NOTIFY is like > having a Refresh button that works on > arbitrary servers rather than just Browser caches. Silly rabbit. NOTIFY is "touch." jb
At least with HTTP/XML, you get some bonus in deployability/flexibility. With one shot notifications, you don't. Worse, with One-shot, you need a new HTTP method! The semantics of GET Events are cleaner. It is more deployable. It is more scalable. And, it is more consistent with the way the web already works. -Alex- On Sun, 3 Feb 2002, Lucas Gonze wrote: > Yes, the need for back requests in one shot notifications means that they are > too inefficient for some applications. Just like HTTP/XML/text > encodings/non-kernel applications/etc are too inefficient for some applications. > > > > Either way. It is more expensive than GET events. > > With one shot notifications, you continually have > > a back request for another subscription. > > > > With GET Events, when you don't want events any > > more, you simply close the connection. > > > > -Alex- > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Jeff Bone wrote: > Silly rabbit. NOTIFY is "touch." No because NOTIFY may result in a change in the thing being notified. Touch simply causes the date to change. E.g. Suppose I go to a web site and think that a binary is out of date with respect to the source. I NOTIFY on the URL of the binary and the server may retrieve the source and recompile IF the source is more recent than the binary. The source may be coerced to being more recent than the binary by touching it. Touch is equivalent to using GET/PUT to affect if-modified-since requests. NOTIFY tells a server that it might want to make IMS requests. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> At least with HTTP/XML, you get some bonus in > deployability/flexibility. With one shot > notifications, you don't. Worse, with One-shot, > you need a new HTTP method! You do not need a new method. PUT is perfect.
PUT is incorrect. It also requires both endpoints to be HTTP servers. GET Events requires only one endpoint to be a server. -Alex- On Sun, 3 Feb 2002, Lucas Gonze wrote: > > At least with HTTP/XML, you get some bonus in > > deployability/flexibility. With one shot > > notifications, you don't. Worse, with One-shot, > > you need a new HTTP method! > > You do not need a new method. PUT is perfect. > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > At least with HTTP/XML, you get some bonus in > deployability/flexibility. With one shot > notifications, you don't. Worse, with One-shot, > you need a new HTTP method! > > The semantics of GET Events are cleaner. It > is more deployable. It is more scalable. And, it > is more consistent with the way the web already > works. Okay, so here's the conclusion I'm coming to --- all of the various options we've been discussing are appropriate in different application contexts. None of them is universal --- as Paul points out, viewing a chat room as a caching problem is probably not the right answer, but OTOH presence is *very much* a caching problem. For a chat room, you most likely need a "centralized" resource that reifies the room and manages mux/demux/ordering of arriving messages. For presence, a resource models a particular person's status and cache invalidation is appropriate, update an optimization. For IM, it's probably the case that a simple POST is appropriate. (Rollover from IM to chat is then cleanly handled by a 3xx redirect in response to a POST, with a header indicating that a long-lived GET on the indicated resource should be established.) For syndication, cache invalidation is the right option, and update via a pushed state representation an important optimization. For Web-based distributed storage, again cache invalidation is probably the right option. For stock quote streams, long-lived GET is probably the right option. Etc., etc., etc. Long-lived GET is appropriate in two contexts: first, where the problem you're actually solving is the asymmetry of connectivity on the Web, and then long-lived GET only solves half the problem, and that rather poorly. Second, when the resource model of interest changes frequently and ordering of those updates is important. The problem, though, is that (particularly in the second case) the mechanism for framing and delivering events over a long-running GET is (a) not specified by HTTP, really --- there are no existing suitable mechanisms for passing *multiple* responses to a single request, though pipelining could potentially be abused somehow, and (b) even if there were, the problem seems very application-specific; knowing what individual update messages or events mean, etc. may not be generalizable. To the extent that it is generalizable, KN or similar probably provides the right general pattern. Just some thoughts... mulling over a whole can of worms that I'd been mostly ignoring for the last few years... ;-) jb
"S. Alexander Jacobson" wrote:
> On Sun, 3 Feb 2002, Jeff Bone wrote:
> > Silly rabbit. NOTIFY is "touch."
>
> No because NOTIFY may result in a change in the
> thing being notified. Touch simply causes the
> date to change.
And that's specifically what WD-Proxy's NOTIFY does --- though in fact
it's sort of the reverse of touch. Proxy A has a cached version of
/bar from origin server www.foo.com. When /bar changes, the origin
server www.foo.com sends a message to Proxy A:
www.foo.com -> Proxy A
-----------------------------
NOTIFY http://www.foo.com/bar HTTP/1.1
thereby invalidating your copy. ("You" being Proxy A.) Admittedly it
doesn't actually change the modification time of your copy; rather, it
lets you know that the actual resource on the origin server has been
modified since your original GET request.
> E.g. Suppose I go to a web site and think that
> a binary is out of date with respect to the
> source. I NOTIFY on the URL of the binary and the
> server may retrieve the source and recompile IF
> the source is more recent than the binary.
I think you misundertand the NOTIFY pattern; re-read the WD-Proxy
spec. You don't NOTIFY a resource on an origin server, you GET that
resource with appropriate headers and then the origin server generates
a NOTIFY to you, "touching" your cached representation to tell you it's
been modified on the origin server.
At any rate, the semantics of NOTIFY are entirely related to relative
modification times, similar to "touch," not anything nearly as complex
as make's dependencies and refreshing.
jb
paul said: > I'm trying to make a distinction here between the semantic content of > the message and the literal content. The semantic content is "something > changed." The literal content is often "oh, and by the way, you could do > a GET to fetch it but in order to reduce network load I've inlined the > value here for you. If you would rather ignore the inlined value, go > ahead and do the GET. It's all the same to me." IMO this is a good thing, but not related to notifications. The thing you are describing is updates. I am _for_ dealing with updates, but as a separate project. > > > 3. the last point implies that the server must tell the client in the > > > notification that it is "pre-authorized" for re-subscription. > > > > It seems safe to assume that the sink is pre-authorized to resubscribe often > > enough to consider it the default. > > Sure, the default. But you're just reversing the question. Then the > publisher must be able to tell the subscriber that it is NOT > pre-authorized. > > > ... Plus it doesn't really cause damage to have > > a re-subscribe fail. > > I strongly disagree. If I believe that I'm subscribed to a stock ticker > but I'm not really, heads will roll. Resubscription is important! I don't mean fail silently. If the re-subscribe fails, the server should say so. 1) A sink receives a notification that state on the server is different since the last time it requested a copy. 2) In the period between receiving the notification and requesting the new state subsequent notifications are meaningless, hence resubscribe is meaningless. 3) Eventually the sink performs a request for the new state. As part of the request the sink resubscribes. (A combined operation will be hard to model in HTTP, but this message is not the place to articulate the problems.) 4) If the resub in the request fails, the server returns a status code to say so. So there's no possibility of losing ticks. I think there is a failure to communicate here. I believe that you are thinking that first the source reports an event; later another event happens that the server needs to report; but there is not a subscription at that moment because the subscription expired after the first notification. However that situation cannot arise in the idempotent notification model. INM notifications are all identical. There is no difference in the semantic content of the first and Nth notifications. A subscription _does_ expire after the notification is received by the sink, but it doesn't matter, because all of the content that doesn't cause notifications to be fired gets picked up anyway when the sink requests the new state. A stock ticker isn't a usecase for idempotent notifications, FWIW. Timing is everything with a ticker, so it should use an update approach. Avoiding time lags caused by the period between POP polling loops is a more focused usecase. Google might register for notifications in order to be able to both keep its cache more up-to-date and expend fewer resources on spidering runs. A user might register for blog updates that come in too sporadically to poll for. A C++ UI might might communicate with a Java engine by registering for "computation complete" notifications. - Lucas
"S. Alexander Jacobson" wrote: > PUT is incorrect. > It also requires both endpoints to be HTTP > servers. GET Events requires only one endpoint > to be a server. This is an aspect of the asymmetry problem, particularly the asymmetrical hardwiring of "client" and "server" roles. In the context of what we're discussing, we've deemed it safe to assume that notifications happen between resources, with the implication that both ends have a resource namespace and respond to (at least some) HTTP requests --- everything is a server. How those requests actually get from end to end --- i.e., connection directionality, etc. --- are out of scope, but there are various options, cf. [1] In general, the formula for dealing with this requires an external and open "rendezvous" server coupled with a tunnel that allows a requests to flow downstream and responses upstream over a long-lived GET connection to a resource on the rendezvous server. jb [1] http://internet.conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern
Lucas Gonze wrote: > 3) Eventually the sink performs a request for the new state. As part of the > request the sink resubscribes. (A combined operation will be hard to model in > HTTP, but this message is not the place to articulate the problems.) Can you expand on this? IMO, it seems trivial to me --- the sink merely requests notification and indicates the sink resource in-band with the GET of the new state, ala WD-Proxy. > 4) If the resub in the request fails, the server returns a status code to say > so. So there's no possibility of losing ticks. This may be a bit trickier --- you want to return both the appropriate response to the GET *and* information relating to the notification commitment or lack thereof. But again, IMO, WD-Proxy provides a reasonable starting point. > I think there is a failure to communicate here. I believe that you are thinking > that first the source reports an event; later another event happens that the > server needs to report; but there is not a subscription at that moment because > the subscription expired after the first notification. However that situation > cannot arise in the idempotent notification model. INM notifications are all > identical. There is no difference in the semantic content of the first and Nth > notifications. A subscription _does_ expire after the notification is received > by the sink, but it doesn't matter, because all of the content that doesn't > cause notifications to be fired gets picked up anyway when the sink requests the > new state. This is exactly right. It's also the primary difference between the pure notification model and the update model. jb
"S. Alexander Jacobson" wrote: > >... > > Thats fine, I think. If you offer notification, > you create URLs which represent the stream of > changes to some other URL (or collection of URLs). > The recipient then gets a chunk encoded stream of > update messages. This is a weird abuse of HTTP. Chunks are supposed to be used to make data flow more efficient, not to indicate changes in state across time. An intermediary might choose to group chunks to merge them or re-chunk for performance reasons. Data formats are about the structure of bytes in a stream. Protocols are about the timing of when data moves across a pipe. You're abusing a data format (mime/multipart) to invent a new protocol. REST philosophy (like Mao Zedung-thought) says you shouldn't have to do that. Paul Prescod
> > 3) Eventually the sink performs a request for the new state. As part of the > > request the sink resubscribes. (A combined operation will be hard > to model in > > HTTP, but this message is not the place to articulate the problems.) > > Can you expand on this? IMO, it seems trivial to me --- the sink > merely requests > notification and indicates the sink resource in-band with the GET of > the new state, > ala WD-Proxy. Your response to point #4 is the same thing that I meant. Quoting you to you: "you want to return both the appropriate response to the GET *and* information relating to the notification commitment or lack thereof." You need to both pick up the new state of the watched resource and post to the subscription resource. Since these address separate resources, encapsulating them in a single request is request-in-request. The natural solution is to require that two requests be performed, one to request the resource and one to renew your sub. Performing two requests (one to the watched resource, one to the subscription resource) may be an unacceptable efficiency issue. Given that the size of a subscription request is low and that the connection can be kept alive, this isn't a real efficiency blow. A more pressing problem is that there's a race condition between the time you pick up the new state of the resource and the time your renewal is processed. If the resource changes between those times then you'll lose intervening states. ...my instinct is to say that there needs to be a way of locking these two transactions together. ...but perhaps there is a simple solution -- to say that every subscription may specify a baseline state. If the current state of the resource at the time the request is received differs from the baseline state, a notification is immediately fired. All subscriptions would be: 1) Requester requests current state of watched resource. 2) Requester requests subscription. Subscription headers include the hash of the last known state. 3) Source compares last-known hash with current hash and, if there is a difference, fires a notification. The race condition is not unique to renewals. New subscriptions would also suffer from it, so the above algorithm should be the same across all interactions. I supposed a default value of the hash that means "I don't care about the race condition, just use your current state as a baseline" would do good things for hello world implementations...
> Long-lived GET is appropriate in two contexts: first, where the problem you're > actually solving is the asymmetry of connectivity on the Web, and then long-lived GET > only solves half the problem, and that rather poorly. HTTP fundamentally differentiates between clients and servers. It specifically does not require clients to implement server functionality. A client should not have to implement server like functionality if it is just receiving requested state from a server. Assymetry is part of the HTTP model. Enjoy it! > Second, when the resource model > of interest changes frequently and ordering of those updates is important. > The problem, though, is that (particularly in the second case) the mechanism for > framing and delivering events over a long-running GET is (a) not specified by HTTP, > really --- I agree with you. My general claim is indeed that this is a problem to be solved at the content-type level rather than at the HTTP protocol level. And, moreover, the combination of multipart/mixed with message/external-body has exactly the semantics that notification requires. There is no deep need to reinvent the wheel. > there are no existing suitable mechanisms for passing *multiple* responses > to a single request, though pipelining could potentially be abused somehow, I am not advocating passing multiple responses. I am advocating passing a single multipart/mixed response (that may be sent chunk encoded). > and (b) > even if there were, the problem seems very application-specific; knowing what > individual update messages or events mean, etc. may not be generalizable. To the > extent that it is generalizable, KN or similar probably provides the right general > pattern. I don't know the details of the KN protocol, but the application of getting notifications of change on some set of URLs is best handled by MIME. You need to get the MIME zen. :-) -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> HTTP fundamentally differentiates between clients > and servers. It specifically does not require > clients to implement server functionality. ... > Assymetry is part of the HTTP model. Enjoy it! I agree. I am excited to work on changing that but also uneasy about it.
On Sun, 3 Feb 2002, Jeff Bone wrote: > > E.g. Suppose I go to a web site and think that > > a binary is out of date with respect to the > > source. I NOTIFY on the URL of the binary and the > > server may retrieve the source and recompile IF > > the source is more recent than the binary. > > I think you misundertand the NOTIFY pattern; re-read the WD-Proxy > spec. You don't NOTIFY a resource on an origin server, you GET that > resource with appropriate headers and then the origin server generates > a NOTIFY to you, "touching" your cached representation to tell you it's > been modified on the origin server. My use of NOTIFY had nothing to do with the WD-Proxy spec. Though it is good to know that we are in some agreement. My point is that NOTIFY is more general than just explicit proxies. It applies to any HTTP resource. The fact that the WD-Proxy spec. describes a NOTIFY that is specific to proxies is irrelevant to my argument. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I think it is an abuse of HTTP (or conflict with REST) to require clients to be servers, just to recieve a resource on some HTTP server. Semantically, the client is requesting a list of modifications or modification times of some set of URLs from the server. The server is then providing it. Why does this require two servers? -Alex- On Sun, 3 Feb 2002, Jeff Bone wrote: > > > "S. Alexander Jacobson" wrote: > > > PUT is incorrect. > > It also requires both endpoints to be HTTP > > servers. GET Events requires only one endpoint > > to be a server. > > This is an aspect of the asymmetry problem, particularly the asymmetrical > hardwiring of "client" and "server" roles. > > In the context of what we're discussing, we've deemed it safe to assume that > notifications happen between resources, with the implication that both ends > have a resource namespace and respond to (at least some) HTTP requests --- > everything is a server. How those requests actually get from end to end --- > i.e., connection directionality, etc. --- are out of scope, but there are > various options, cf. [1] In general, the formula for dealing with this > requires an external and open "rendezvous" server coupled with a tunnel that > allows a requests to flow downstream and responses upstream over a long-lived > GET connection to a resource on the rendezvous server. > > jb > > [1] http://internet.conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I can't believe I am hearing you all say this is a wierd abuse of HTTP given that you were advocating exactly this solution to a large set of problems when I joined this list. Either HTTP is the universal protocol or its not. Pick one! Note, if HTTP intermediaries decide to group chunks in awkward ways, that is not a problem with HTTP. It is a problem with the intermediaries implementation. -Alex- On Sun, 3 Feb 2002, Paul Prescod wrote: > "S. Alexander Jacobson" wrote: > > > >... > > > > Thats fine, I think. If you offer notification, > > you create URLs which represent the stream of > > changes to some other URL (or collection of URLs). > > The recipient then gets a chunk encoded stream of > > update messages. > > This is a weird abuse of HTTP. Chunks are supposed to be used to make > data flow more efficient, not to indicate changes in state across time. > An intermediary might choose to group chunks to merge them or re-chunk > for performance reasons. > > Data formats are about the structure of bytes in a stream. > > Protocols are about the timing of when data moves across a pipe. You're > abusing a data format (mime/multipart) to invent a new protocol. REST > philosophy (like Mao Zedung-thought) says you shouldn't have to do that. > > Paul Prescod > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
Lucas Gonze wrote: > >... > > IMO this is a good thing, but not related to notifications. The thing you are > describing is updates. I am _for_ dealing with updates, but as a separate > project. Fine. But for performance reasons we need to leave hooks into *this* project that will allow us to inline useful information later. If the performance characteristics of the protocol make it unusable for anything other than cache invalidation then it won't have met any of my goals. In almost every application I can think of (other than pure cache invalidation), the common pattern is: GET NOTIFY GET NOTIFY So you are going to trigger TCP connection/teardown twice for each notification. Developers will hate that. If you know of a bunch of applications for a "pure" notification model then I'd like to hear about them. But almost anything that goes across organizational boundaries will want a full update because you can't trust the other party to not delete the data before you get to it. > I don't mean fail silently. If the re-subscribe fails, the server should say > so. > > 1) A sink receives a notification that state on the server is different since > the last time it requested a copy. > 2) In the period between receiving the notification and requesting the new state > subsequent notifications are meaningless, hence resubscribe is meaningless. I guess that's our problem. I'm thinking ahead to inline representations and re-subscribe in responses. In that case, the inline representation is the equivalent of a GET. Here's another (somewhat less efficient) idea: the response to a NOTIFY could return a Location: that says where to PUT the changed data. Because all of the connections go from publisher to subscriber, the same TCP connection could be used. I kind of like that becuase the notification could say: "the document is 5MB. You may or may not want to fetch it unless you know you really need it." > 3) Eventually the sink performs a request for the new state. As part of the > request the sink resubscribes. (A combined operation will be hard to model in > HTTP, but this message is not the place to articulate the problems.) What's wrong with the header approach from WD-NOTIFY? >... > A stock ticker isn't a usecase for idempotent notifications, FWIW. Timing is > everything with a ticker, so it should use an update approach. Well it is essentially impossible to guarantee latency on the public Internet anyhow. So I don't see a big difference between a notification model and an update model. Even without resource inlining, we're talking about an extra second or two. For all you know, the message is already five minutes late because of network congestion! I do think that notifications should be efficient enough for interactive (but not hard-realtime) use. Paul Prescod
You can't use chunks as message delimeters because proxies may (must?) strip out chunk encoding before the data is passed to the client. > Note, if HTTP intermediaries decide to group > chunks in awkward ways, that is not a problem with > HTTP. It is a problem with the intermediaries > implementation. > > -Alex-
"S. Alexander Jacobson" wrote: > > I can't believe I am hearing you all say this is a > wierd abuse of HTTP given that you were advocating > exactly this solution to a large set of problems > when I joined this list. I've never advocated using chunked HTTP for anything like that. > Either HTTP is the universal protocol or its not. HTTP is the universal protocol. You can use it as it was designed to be used without tricking it. Any of us could implement an HTTP-based notification scheme in a couple of hours. *BUT* the reason that what we are doing is difficult is because we are trying to define an HTTP notification scheme *for* HTTP. i.e. we want to get our heads inside HTTP and design a notification model as it would have been designed by Roy, Henrik, Tim, Philip etc. at the time HTTP was being designed. This is much harder than figuring out a way to use HTTP for a particular application. >... > Note, if HTTP intermediaries decide to group > chunks in awkward ways, that is not a problem with > HTTP. It is a problem with the intermediaries > implementation. Infosar as the HTTP implementation says to treat the chunks as *one logical stream* it is perfectly legit for an intermediary to re-chunk however it wants. It also might blow away the connection when it feels like it has timed out. Paul Prescod
per Paul: > Fine. But for performance reasons we need to leave hooks into *this* > project that will allow us to inline useful information later. IMO charter for the notifications design is partly to lay the groundwork for an update project to follow, which means in practice that anything that prevents later update extensions has a high burden of proof. EG We should avoid specifying what's in the notification entity body, because that's the likely location of update data, but we should also not give a half-assed definition of what's in the update entity body, because that may make things harder on the update project. > I guess that's our problem. I'm thinking ahead to inline representations > and re-subscribe in responses. In that case, the inline representation > is the equivalent of a GET. Yeah, and I think that's a good thing. > Here's another (somewhat less efficient) idea: the response to a NOTIFY > could return a Location: that says where to PUT the changed data. > Because all of the connections go from publisher to subscriber, the same > TCP connection could be used. > > I kind of like that becuase the notification could say: "the document is > 5MB. You may or may not want to fetch it unless you know you really need > it." I like this idea, though I would wait on a dedicated project to work through all the implications before committing to it. > > 3) Eventually the sink performs a request for the new state. As part of the > > request the sink resubscribes. (A combined operation will be hard > to model in > > HTTP, but this message is not the place to articulate the problems.) > > What's wrong with the header approach from WD-NOTIFY? don't know it yet. :) busy workdays for me lately, sorry to be slack in keeping up with reading. > > A stock ticker isn't a usecase for idempotent notifications, FWIW. > Timing is > > everything with a ticker, so it should use an update approach. > > Well it is essentially impossible to guarantee latency on the public > Internet anyhow. So I don't see a big difference between a notification > model and an update model. Even without resource inlining, we're talking > about an extra second or two. For all you know, the message is already > five minutes late because of network congestion! Sure! And given that you can actually pick up all transient states (by subscribing to a broad /resource/all_states resource instead of a child /resource/current_state resource) notifications should be able to provide quite a lot of functionality. > > I do think that notifications should be efficient enough for interactive > (but not hard-realtime) use. Agreed.
"S. Alexander Jacobson" wrote: > > I think it is an abuse of HTTP (or conflict with > REST) to require clients to be servers, just to > recieve a resource on some HTTP server. HTTP says that all connections are made from clients to servers. You could argue that requiring subscribers to be servers is a bad idea for security reasons or whatever, but it isn't in conflict with HTTP! You're using a different definition of client and server than HTTP does. If a Linux box is the initiator of a particular HTTP transaction then it is the client. If we really decide that the "right thing" is a TCP connection from subscriber to publisher then we would have to invent a non-HTTP protocol. I can see various practical limits including: * limits on numbers of TCP connctions on particular machines * timeouts * firewalls * security admins freaking out about the number of open connections Think about Google subscribing to notifications from every news site in the world. I can't imagine it keeping TCP connections open to tens of thousands of them at a time. You're going to run into some serious OS limitations. Paul Prescod
Lucas Gonze wrote: > > per Paul: > > Fine. But for performance reasons we need to leave hooks into *this* > > project that will allow us to inline useful information later. > > IMO charter for the notifications design is partly to lay the groundwork for an > update project to follow, which means in practice that anything that prevents > later update extensions has a high burden of proof. EG We should avoid > specifying what's in the notification entity body, because that's the likely > location of update data, but we should also not give a half-assed definition of > what's in the update entity body, because that may make things harder on the > update project. Here's a proposal for both the notify and update parts. 1. the client signs up for notification by doing a GET or HEAD with a special header. 2. the server does a POST or NOTIFY (argue that one out later) to the client informing it that the resource is available. It MUST pre-announce whether an immediate re-subscribe would succeed. 2. the client responds, optionally asking: a) to be re-susbcribed (any flags or options the same) b) for a representation of the resource to be PUT to a URI specified in a Location: header 3. the server does the requested PUT and re-SUB If we have broad agreement on these, I could write it up. Paul Prescod
Mark Baker wrote: > >... > > This is like saying that Ethernet is general purpose. It's true, but > not too useful. RPC is a lower layer than HTTP because it defines no > application semantics, leaving them for the "API" to define. I'm scared of the term "application" because we also build applications on top of HTTP. Plus, RPC has its own set of semantics involving parameters, return codes, methods, etc. The word semantics is also a mine-field. I'm one of a vocal few people who claim that XML has semantics (angle-brackets are syntax, attributed-trees are semantics). > Linda, like HTTP and FTP and NNTP, defines the methods. So you've > got an application layer contract - a coordination language - > between endpoints a priori. Is SMTP a coordination language? Do we have a definition that can be made precise? >... > > Definitions aside, the point remains: in terms of generality, HTTP has > > more in common with SOAP than with SMTP. It is not just about moving > > HTML pages from servers to clients. > > I'd say it's the other way around. SMTP "DATA" has a precise > meaning, not unlike POST. I know you claim that POST's meaning is precise. ;) >... > > HTTP is similar. HTTP allows you to read from the storage with GET, > > write to it with PUT and the addresses are URIs. Because disk space in > > the real world is limited, HTTP also has DELETE. And because multiple > > people will be using the system at once, there is a need for a method > > that will create guaranteed-new "storage locations". > > I'd say that POST was the movement of the tape. PUT creates new > locations. We disagree on the meaning of POST. What a surprise. ;) If we are strict about the idea that URIs are opaque then the client doing the PUT can't really know what URI to use to create a new resource. POST can be used to provide a new URI. > > FTP is the closest protocol to HTTP conceptually. But really the gap > > I think NNTP is probably closest. It has POST (that's where HTTP's > POST came from), a basic get (ARTICLE), and a very specific type of > put (for setting read messages). FTP has a more general GET (i.e. it has a concept of hierarchy and filenames) and PUT. > > important, though, FTP's semantics do not allow the server to be an > > active participant in the computation. HTTP very precisely defines how > > the server can do complicated computations by itself. It is not just a > > holder of bits -- it can embody a complex service! > > You mean the app here I guess. You should distinguish between the > web server and the web app. Okay. > > efficiency and modeling simplicity. For instance WebDAV has a LOCK > > method which could be modeled as a POST of a LOCk object. In theory the > > PUT actually, since it is defined absolutely. Okay. >... > > > I say "quasi-universal" because there are limits. Just as XML isn't > > really great for binary media, HTTP isn't really great for streaming > > real-time media. So for those applications you should use something > > else. > > (though perhaps with HTTP's application semantics) Okay. > > There is no doubt that HTTP has its limitations. For one thing there is > > not much software out there that knows how to deal with HTTP in a > > peer-to-peer or asychronous fashion. > > I don't know what that means. Define client as a device with potentially transient connectivity, directly controlled by an end-user. Define server as a device with persistent connectivity not controlled by an end-user. There is not much software out there that uses HTTP to have servers contact clients, or servers to contact servers using HTTP. This is important because it means that firewalls are not appropriately configured for that sort of usage. Thus, KnowNow single-byte hacks. Paul Prescod
> > This is like saying that Ethernet is general purpose. It's true, but > > not too useful. RPC is a lower layer than HTTP because it defines no > > application semantics, leaving them for the "API" to define. > > I'm scared of the term "application" because we also build applications > on top of HTTP. Technically, we don't. I know the common use of the term is just that, but in actuality, we are simply adding more resources to an existing app, the Web. > Plus, RPC has its own set of semantics involving > parameters, return codes, methods, etc. The word semantics is also a > mine-field. I'm one of a vocal few people who claim that XML has > semantics (angle-brackets are syntax, attributed-trees are semantics). Sure, and I agree with you about XML having semantics (Jon Bosak has said as much). But "application semantics" has a much more precise meaning, though not commonly known. > > Linda, like HTTP and FTP and NNTP, defines the methods. So you've > > got an application layer contract - a coordination language - > > between endpoints a priori. > > Is SMTP a coordination language? Yes. > Do we have a definition that can be > made precise? I'm sure we could whip one together without much trouble. As I say on the Wiki, I believe that all application protocols are coordination languages. > We disagree on the meaning of POST. What a surprise. ;) > > If we are strict about the idea that URIs are opaque then the client > doing the PUT can't really know what URI to use to create a new > resource. POST can be used to provide a new URI. Right, that's the point. The whole idea with PUT is that the client specifies the name, likely because it had previously done a GET and so knows what the name already is. But any container can choose to reject a PUT with a name it doesn't like, so that's why it's still opaque (it determines the meaning of the name). I suppose that somewhere in there is a PUT based form solution where the form suggests a URI. POST means "accept as a subordinate", which means that the client is specifically punting all responsibility for the document to the container, including naming it, as you say. > > > FTP is the closest protocol to HTTP conceptually. But really the gap > > > > I think NNTP is probably closest. It has POST (that's where HTTP's > > POST came from), a basic get (ARTICLE), and a very specific type of > > put (for setting read messages). > > FTP has a more general GET (i.e. it has a concept of hierarchy and > filenames) and PUT. News groups and articles are hierarchically named too. Each group is a container that contains multiple articles, articles can be posted to multiple groups, etc.. (it goes beyond HTTP here, and gets into KnowNow-land with message ids and topics). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Sun, 3 Feb 2002, Lucas Gonze wrote: > A stock ticker isn't a usecase for idempotent notifications, FWIW. However it is a use case for GET Events. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Jeff Bone wrote: > And that's specifically what WD-Proxy's NOTIFY does I just read the WD-Proxy spec. It doesn't make sense. Methods should be delivered to endpoints, not proxies! -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Paul Prescod wrote: > Protocols are about the timing of when data moves across a pipe. You're > abusing a data format (mime/multipart) to invent a new protocol. REST > philosophy (like Mao Zedung-thought) says you shouldn't have to do that. Go ahead and re-read the discussion on this list when I first joined justifying REST. Many of the answers revolved around either persistent GET or long GET with multiple plaudits for KnowNow. Is KnowNow abusing HTTP? Really I think if you want to make this argument, you should take it up with Jeff, Mike, and Mark. They were all arguing about why HTTP is great protocol for chat, using persistent GET. Actually, I think you might have been arguing this as well. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Lucas Gonze wrote: > A more pressing problem is that there's a race condition between the time you > pick up the new state of the resource and the time your renewal is processed. Again, using GET Events does not have this problem. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Lucas Gonze wrote: > > HTTP fundamentally differentiates between clients > > and servers. It specifically does not require > > clients to implement server functionality. > ... > > Assymetry is part of the HTTP model. Enjoy it! > > > I agree. I am excited to work on changing that but also uneasy about it. Why change it? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
How does KnowNow work? In any case, I don't think these GET requests are cachable so intermediaries should act transparently. -Alex- On Sun, 3 Feb 2002, Lucas Gonze wrote: > You can't use chunks as message delimeters because proxies may (must?) strip out > chunk encoding before the data is passed to the client. > > > Note, if HTTP intermediaries decide to group > > chunks in awkward ways, that is not a problem with > > HTTP. It is a problem with the intermediaries > > implementation. > > > > -Alex- > > ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
On Sun, 3 Feb 2002, Paul Prescod wrote: > > I can't believe I am hearing you all say this is a > > wierd abuse of HTTP given that you were advocating > > exactly this solution to a large set of problems > > when I joined this list. > > I've never advocated using chunked HTTP for anything like that. What does KnowNow do? > > Either HTTP is the universal protocol or its not. > > HTTP is the universal protocol. You can use it as it was designed to be > used without tricking it. Any of us could implement an HTTP-based > notification scheme in a couple of hours. Again, please re-read the discussion from before. > >... > > Note, if HTTP intermediaries decide to group > > chunks in awkward ways, that is not a problem with > > HTTP. It is a problem with the intermediaries > > implementation. > > Infosar as the HTTP implementation says to treat the chunks as *one > logical stream* it is perfectly legit for an intermediary to re-chunk > however it wants. It also might blow away the connection when it feels > like it has timed out. Re-chunking does not affect the protocols performance (except perhaps in a good way). If it blows away the connection, the client can just reconnect it. This is certainly lighter weight and more sane than repeatedly connecting just to request subscriptions. But, again, I refer you to the discussion of implementing chat and knownow in the discussion we had when I arrived. Mark and Jeff, where are you on this issue? -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
----- Original Message ----- From: "Mark Baker" <distobj@...> > > ----- Original Message ----- > > From: "S. Alexander Jacobson" <alex@...> > > > > > > > > PS My gut also says that NOTIFY really means > > > something quite distinct from POST. In > > > particular, POST says something about a resource > > > is to be changed in some way. NOTIFY signals that > > > the change has already happened. > > > > I agree. > > I don't. The resource identified by the callback URI can be whatever > the subscriber wants it to be. If it's a semaphore, then PUT or POST > is fine. If it's a mailbox, then POST is good. I dare you to try and > choose a resource that's used to receive notifications that can't > receive them with PUT or POST. It's not the method name that is important to me, it is the meaning - that a notification is about a change that already happened.
On Sun, 3 Feb 2002, Paul Prescod wrote: > HTTP says that all connections are made from clients to servers. You > could argue that requiring subscribers to be servers is a bad idea for > security reasons or whatever, but it isn't in conflict with HTTP! No, the conflict is philosophical. HTTP says that a client makes a request for information and the server delivers it. Defining a new protocol that works by requesting information and getting it delivered over another connection later is not in the spirit of HTTP. > If we really decide that the "right thing" is a TCP connection from > subscriber to publisher then we would have to invent a non-HTTP > protocol. I can see various practical limits including: > > * limits on numbers of TCP connctions on particular machines > * timeouts > * firewalls > * security admins freaking out about the number of open connections Again, I refer you to the discussion from before. Limits on the numbers of TCP connections is entirely artificial. Mike and Jeff both referred to implementations with 50k connections per machine. Timeouts are handled by periodic reconnects. Firewalls are BETTER handled by using GET. Security admins freaking is just part of life. The typical client is not going to have that many connections open. Since users are already using IM I am not sure this is really an issue. > Think about Google subscribing to notifications from every news site in > the world. I can't imagine it keeping TCP connections open to tens of > thousands of them at a time. You're going to run into some serious OS > limitations. These OS limitations are entirely spurious. There is no reason why socket information cannot be stored in virtual memory (on disk). I don't think your scaling argument is good here. More to the point, I don't think you can make a solid argument that the load from notification back and forth is really higher than maintaining open GET connections. I think GET Events is actually much MORE scalable than notification! -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
I am realizing that I am spending too much time on this list without getting enough done. I've learned a lot, but I need to move on. If you are interested in helping to formalize GET Events, please send me mail. Either way, have fun. -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
"S. Alexander Jacobson" wrote: > >... > > Go ahead and re-read the discussion on this list > when I first joined justifying REST. Many of the > answers revolved around either persistent GET or > long GET with multiple plaudits for KnowNow. KnowNow uses a good hack to get around firewalls. We may need to define a hack like that for getting around firewalls too. But first you define the protocol properly and then you figure out what you need to hack. > Is KnowNow abusing HTTP? Yes! Any solution that involves one-byte stay-alive messages is a hack! But my understanding (and observation) is that *within* the hacked socket KnowNow uses regular HTTP messages, not chunked MIME data. I want to emulate what they do within the hack, not the hack. Paul Prescod
On Mon, 4 Feb 2002, Paul Prescod wrote: > > Is KnowNow abusing HTTP? > > Yes! Any solution that involves one-byte stay-alive messages is a hack! But the hack is to route around disfunction in HTTP implemenations, rather than to route around limits in HTTP, right? I mean why are they sending one-byte stay-alive messages? > But my understanding (and observation) is that *within* the hacked > socket KnowNow uses regular HTTP messages, not chunked MIME data. I want > to emulate what they do within the hack, not the hack. More particularly, how are they sending one byte stay alive messages that also HTTP? HTTP seems to require at least a method and a status code, both of which are at least 3 bytes... -Alex- ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
> It's not the method name that is important to me, it is the meaning - that a > notification is about a change that already happened. A PUT and/or POST in response to a WATCH can be made to mean exactly that. It's not a typical PUT or POST, since the invoker of the WATCH method provides a callback resource that it knows will be used this way. So there's additional context that isn't there in a blind PUT or POST (though the context is private to the WATCH invoker). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Alexander Jacobson" wrote: > > Why does this require two servers? Because if you're doing notification between resources... drumroll... you've got to have a server to host those resources. Bye, Alex. jb
On Mon, 4 Feb 2002, Jeff Bone wrote: > > Why does this require two servers? > > Because if you're doing notification between resources... drumroll... you've got > to have a server to host those resources. Only if they are both resources. If the outcome of notification is to send an page or email, I don't think that involves 2 resources. As you have said repeatedly, an email address is not a resource.... I am curious why you have changed your mind on this issue. You were definitely involved in convincing me that long GET was a good way to go for this type of application. You appear to have changed your mind. Why? -Alex- PS I am replying to email sent to me. ___________________________________________________________________ S. Alexander Jacobson i2x Media 1-212-787-1914 voice 1-603-288-1280 fax
The W3C's Annotea [1] seems to be a good example of a RESTful Web application. Cheers, [1] http://www.w3.org/2001/Annotea/User/Protocol.html -- Mark Nottingham http://www.mnot.net/
It could be; however, for some applications, that's too limiting. More to the point, it's difficult to arrange your resources so that these relationships are meaningful in multiple contexts; e.g., P3P and access control (insert your own, more notification-specific, examples here). I discussed this a bit in Urispace [1]. I'd approach the problem differently now. Cheers, [1] http://www.w3.org/TR/urispace.html On Fri, Feb 01, 2002 at 05:11:29PM -0800, S. Mike Dierken wrote: > > ----- Original Message ----- > From: "Mark Nottingham" <mnot@...> > > > > > > A list of URIs is too limiting - it may not be practical or possible > > to enumerate them all... > That's just from Pauls example. However, is it a 'web collection' is the > things inside aren't first-class resources (uri addressable)? > > > > > > > > > On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote: > > > > > > ----- Original Message ----- > > > From: "Paul Prescod" <paul@...> > > > > > > > > > > > I've clarified my thoughts on how to handle notifications for > > > > collections. Collections are just documents that happen to contain > URIs > > > > to other documents. Just hang a WATCH on that document. > > > Woohoo! Yes, by george, you've got it! As a Groves dude, this should be > > > pretty straightforward for you to work out the details of. > > > And the resource (aka 'collection') may have metadata separate from the > list > > > of URIs - how do distinguish between the two? That's where the > 'add/remove' > > > comes from - they are 'updates' to the 'default collection' property. > But > > > that is all really too complex for now - I can build it in the app layer > > > with the low level primitives. > > > > > > > > > -- Mark Nottingham http://www.mnot.net/
> Here's how this protocol could be used to accomplish (1): > > CLIENT -> SERVER > ---------------------- > GET /foo HTTP/1.1 > Accept: text/html > Proxy-Features: my.host.com; notify I wonder if use of the notify flag should be considered a backdoor way to set state on the server during a GET? Does it matter if this operation is combining a GET of the watched resource with a PUT to a subscription resource? Are there serious difficulties with figuring out whether the response status code applies to the watched resource or the subscription resource? For example, if the response is "unauthorized", how to figure out if it applies to the watched resource or the subscription resource?
Lucas Gonze wrote: > > Here's how this protocol could be used to accomplish (1): > > > > CLIENT -> SERVER > > ---------------------- > > GET /foo HTTP/1.1 > > Accept: text/html > > Proxy-Features: my.host.com; notify > > I wonder if use of the notify flag should be considered a backdoor way to set > state on the server during a GET? Does it matter if this operation is combining > a GET of the watched resource with a PUT to a subscription resource? Are there > serious difficulties with figuring out whether the response status code applies > to the watched resource or the subscription resource? Hmmm... I don't think this is terribly problematic. One thing HTTP definitely *doesn't* provide is an assurance that the overall state of resource space *only* changes through the actions of the HTTP methods. Given this, I don't think it's necessary to view the above as a GET + PUT, even if it has some effect on a second, unnamed (subscription) resource. > For example, if the response is "unauthorized", how to figure out if it applies > to the watched resource or the subscription resource? Bear in mind that the notify is only a request for a subscription, if one exists. The subsequent response will indicate whether or not such a subscription is either available, authorized, granted... not sure it's really manditory to distinguish between those conditions. Either the subscription is available and was granted, or its not. Dunno that more need be done. What do you think? jb
So,
I was doing some coding the other day (it happens) and thought of a way to
clarify (for myself anyways) the distinction between put and post. Say I've
got a hashmap (dictionary, hashtable, etc.) with names and values.
value = server.get("name");
server.put("name",value);
server.post("name",value);
The put and post looks similar but the difference is
server.put(name,value)
{
data[name] = value;
}
server.post(name,value)
{
old = data[name];
newValue = old + value; // where "+" is arbitrarily complex
data[name] = newValue;
}
So 'post' is (to me) a lot like 'append' (at least for some situations).
Although the '+' operation could ignore the old value and the post() would
act like put(), an intermediary (cache) won't know this and can't emulate
the '+' operation - hence optimizing the situation by publicly declaring
what the '+' operation is via the method name - put=a pure replacement.
Mike "stating the obvious" Dierken
I don't think it is appropriate for us to have GET have the side-effect of registering a notification. What if a cache intercepts the method? What if a server just doesn't understand the header at all? It won't announce that. Paul Prescod
All good points. Here are some off-the-top (hopefully not over-the-top ;-) thoughts about these issues... (1) Side-effects. I'm not 100% convinced its correct to view the notification request behavior as a side-effect. It doesn't actually impact the content returned beyond adding a header and *later* producing an effect that wouldn't exist otherwise; a proxy doesn't necessarily have visibility to the latter, so it's not clear that it's side-effecting from the proxy's point-of-view. Determination of idempotency -wrt- heavers vs. content is a bit ambiguous. (2) Note that WD-Proxy was originally intended to allow proxies to request invalidation notifications from origin servers. Given that the requesting party identifies themselves inline with distinct headers, this is a bit of a grey area. Also note that, while inlining multiple requests is clearly handled, there's no mechanism for allowing proxies to request upstream proxies to generate invalidations based on their own receipt of notifications, i.e. not clear whether / how to handle notification fan-out. These are all valid areas for further discussion. (3) It should be possible to force the request through the proxy from the subscriber end of things through the use of other proxy directive headers in combination... right? It does make me a bit uneasy, but I'm not sure why or how to weight the pros and cons. $0.02, jb Paul Prescod wrote: > I don't think it is appropriate for us to have GET have the side-effect > of registering a notification. What if a cache intercepts the method? > What if a server just doesn't understand the header at all? It won't > announce that. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
I am hopelessy undecided on this -- there are excellent reasons on both sides. My plan is to write up sample transactions in both styles and compare how well they work in practice. > It does make me a bit uneasy, but I'm not sure why or how to weight the pros > and cons. ... > jb ... > Paul Prescod wrote: ... > > I don't think it is appropriate for us to have GET have the side-effect > > of registering a notification. What if a cache intercepts the method? > > What if a server just doesn't understand the header at all? It won't > > announce that.
Paul wrote; > I don't think it is appropriate for us to have GET have the side-effect > of registering a notification. What if a cache intercepts the method? GET doesn't have side-effects in that case. The resource doesn't change state, plus any other stateful action are undone when the GET finishes. > What if a server just doesn't understand the header at all? It won't > announce that. The "Subscriber" header? Nope, it won't announce it, but that's part of the Subscription/Subscriber contract. Why would somebody POST a message with a Subscriber body to a URI that didn't advertise its ability to accept it (and have it mean "subscribe")? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > > All good points. Here are some off-the-top (hopefully not over-the-top ;-) > thoughts about these issues... > > (1) Side-effects. I'm not 100% convinced its correct to view the > notification request behavior as a side-effect. It doesn't actually impact > the content returned beyond adding a header and *later* producing an effect > that wouldn't exist otherwise; The server needs to change state to remember the request. That sounds like a side-effect to me. >... > (3) It should be possible to force the request through the proxy from the > subscriber end of things through the use of other proxy directive headers in > combination... right? I suppose so. Paul Prescod
Mark Baker wrote: > > > I don't think it is appropriate for us to have GET have the side-effect > > of registering a notification. What if a cache intercepts the method? > > GET doesn't have side-effects in that case. The resource doesn't change > state, plus any other stateful action are undone when the GET finishes. I don't follow you. If a GET tells a server to remember to contact me later then how is that not a side-effect. It is a change of server-side state (though not a change of the resource's state). > > What if a server just doesn't understand the header at all? It won't > > announce that. > > The "Subscriber" header? Nope, it won't announce it, but that's part of > the Subscription/Subscriber contract. Why would somebody POST a message > with a Subscriber body to a URI that didn't advertise its ability to > accept it (and have it mean "subscribe")? First: you shouldn't have to know a priori whether a resource is subscribable. You should be able to ask it. Second: having a resource do a completely different type of action based on the contents of the entity body sounds like RPC to me! Paul Prescod
> Mark Baker wrote: > > > > > I don't think it is appropriate for us to have GET have the side-effect > > > of registering a notification. What if a cache intercepts the method? > > > > GET doesn't have side-effects in that case. The resource doesn't change > > state, plus any other stateful action are undone when the GET finishes. > > I don't follow you. If a GET tells a server to remember to contact me > later then how is that not a side-effect. It is a change of server-side > state (though not a change of the resource's state). Ooh, ow, who's using GET that way? I've only ever suggested using a GET that lasts for a long time. > > > What if a server just doesn't understand the header at all? It won't > > > announce that. > > > > The "Subscriber" header? Nope, it won't announce it, but that's part of > > the Subscription/Subscriber contract. Why would somebody POST a message > > with a Subscriber body to a URI that didn't advertise its ability to > > accept it (and have it mean "subscribe")? > > First: you shouldn't have to know a priori whether a resource is > subscribable. You should be able to ask it. That's what the Subscriptions header asserts, no? It says, "Hi, I support being subscribed to, and here's the URI that is a container for all of my subscriptions". > Second: having a resource do a completely different type of action based > on the contents of the entity body sounds like RPC to me! Hmm, that's not what I was suggesting. POST means "accept". If I POST something with a Subscriber header and get a 200 back, I know that is was accepted, not that is processed as a subscription. It may just have been stored as a file, who knows. How I know that my POST means "subscribe" is because it was asserted that the URI I was posting to was a container for subscriptions. That's what I thought the Subscriptions header was for. No? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > Ooh, ow, who's using GET that way? Jeff Bone. http://groups.yahoo.com/group/rest-discuss/message/591 > I've only ever suggested using a GET that lasts for a long time. That's why we're miscommunicating. ;) > That's what the Subscriptions header asserts, no? It says, "Hi, I > support being subscribed to, and here's the URI that is a container > for all of my subscriptions". Yeah. You're talking about a totally different proposal than the one I was critiquing. Paul Prescod
Just to be clear about what it is we're talking about: We have more or less achieved a loose consensus on what should happen at the sink side. Now we're figuring out what interactions with the source should look like. There are two general approaches on the table. Approach 1 is to have the GET of the watched resource contain a "notify" flag in the headers. This is getting the watched resource and leaving a callback request at the same time. Approach 2 is to have two separate transactions, one to GET the watched resource and the other to POST to the subscription resource.
Lucas Gonze wrote: > > Just to be clear about what it is we're talking about: > > We have more or less achieved a loose consensus on what should happen at > the sink side. Very loose....I don't think we're agreed on PUT versus POST versus NOTIFY. Plus the decision of whether subscriptions are persistent has implications for the sync. Paul Prescod
Ok, just so I'm clear; approach 1 is evil, approach 2 is goodness. 8-) Sorry, I haven't been keeping up with all your work. > Just to be clear about what it is we're talking about: > > We have more or less achieved a loose consensus on what should happen at > the sink side. Now we're figuring out what interactions with the source > should look like. There are two general approaches on the table. > > Approach 1 is to have the GET of the watched resource contain a "notify" > flag in the headers. This is getting the watched resource and leaving a > callback request at the same time. > > Approach 2 is to have two separate transactions, one to GET the watched > resource and the other to POST to the subscription resource. > MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Yes, I didn't mean to pre-empt further discussion, just to say that the there appears to be consensus on algorithm. > Very loose....I don't think we're agreed on PUT versus POST versus > NOTIFY. Plus the decision of whether subscriptions are persistent has > implications for the sync. > > Paul Prescod
Paul Prescod wrote: > Jeff Bone wrote: > > > > All good points. Here are some off-the-top (hopefully not over-the-top ;-) > > thoughts about these issues... > > > > (1) Side-effects. I'm not 100% convinced its correct to view the > > notification request behavior as a side-effect. It doesn't actually impact > > the content returned beyond adding a header and *later* producing an effect > > that wouldn't exist otherwise; > > The server needs to change state to remember the request. That sounds > like a side-effect to me. Sure, sure, but there's side effects and then there's side effects. I.e., on some strictly literal level it's wrong to call even GET "idempotent" since resources are actually time-varying streams of different, mutable representations, and GET can indeed (as with counters, etc.) have some kinds of effects. Think of the subscription in sort of the same sense as incrementing a page hit counter. jb
Paul Prescod wrote: > Mark Baker wrote: > > > >... > > > > Ooh, ow, who's using GET that way? > > Jeff Bone. http://groups.yahoo.com/group/rest-discuss/message/591 With the admission that this was offered as a straw man for discussion, and is just a rehash of the old WD-Proxy NOTIFY stuff. jb
Paul Prescod wrote: > Lucas Gonze wrote: > > > > Just to be clear about what it is we're talking about: > > > > We have more or less achieved a loose consensus on what should happen at > > the sink side. > > Very loose....I don't think we're agreed on PUT versus POST versus > NOTIFY. Plus the decision of whether subscriptions are persistent has > implications for the sync. Also note --- the WD-Proxy model supports NOTIFY on resources that aren't actually hosted on the node that receives the notify. I.e., even though I'm "bar.com," if I subscribe to "foo.com/baz" then I'll get a NOTIFY http://foo.com/baz when that resource changes. jb
Mark Baker wrote: > Ok, just so I'm clear; approach 1 is evil, approach 2 is goodness. 8-) Don't be quite so hasty, Mark... after starting things out by pushing for reification of the subscription as a resource, I re-stumbled across the WD-Proxy stuff and discovered that there's actually some goodness lurking in there. Go take a look. There's some evil as well, but some reasonably good things worth thinking about (like 1-shot notifications, etc.) jb
I started pseudocoding both proposed designs for the interactions with the server/source and instantly found serious problems with both. "Model-2req" (coinage here for reasons of convenience) is the one where there are two requests, a POST to a subscription resource and a GET to a watched resource. The problem with this is that it implies a transaction. In my former proposal on the subject I suggested that there be a GET, the GET results would be hashed by the client in some well known way, and the hash would be transmitted with the followup POST as a "baseline state." The subscription resource would decide when to fire a notification by computing its own hash of the watched resource and compare it to the hash sent by the client. However the hash has to be up to the server, since GET headers often imply a view of the object. (By "view" I mean a transformation that is orthogonal to the underlying content of the object. For example the GET may have "Accept: XML-2.0", while the base resource exists in a neutral form like a unix mbox file.) "Model-1req" is the one where there is a single request/response that augments a GET with a header that implies a watch. The problem with this is that it requires the owner of the resource to be the watcher. That precludes all third party watchers, whether on another host or on the same one. If the watched resource is a script then it has to be edited to support the notify request. If it is a file then the web server has to be edited with something like mod_notify. So deployment becomes an obstacle. There is a solution to the problem with Model-2req. I propose that the subscription POST and resource GET be completely separated and the hash be eliminated. The subscription POST would become effective immediately. POSTing to it would mean "Do what you need to do to know that this resource has changed, whether it's computing a hash or creating a database trigger." The POST would have to precede the GET -- otherwise there would be a race condition between the GET and POST, and states between the time of the GET and POST could be lost. I will post a sample set of Model-2req transactions in a separate followup message. - Lucas
"Model-2req" is the one where there are two requests, a POST to a subscription resource and a GET to a watched resource. I previously suggested that there be a GET, the GET results would be hashed by the client in some well known way, and the hash would be transmitted with the followup POST as a "baseline state." However it is hard to lock the GET and POST together, because it is hard to make a hash that the client and server can both compute independently. If there has to be a hash computed by the client, then the POST can't precede the GET. If the hash has to be computed by the server, then the GET has to return it, and that means the watched resource has to be modified to compute and output the hash. The following sample set of Model-2req transactions is intended to correct these problems. I propose that the POST precede the GET and the hash be eliminated. The subscription POST would become effective immediately on reception. POSTing to it would mean "Do what you need to do to know that this resource has changed, whether it's computing a hash or creating a database trigger." Though it is assumed that the sink will followup the POST with the GET, it is not necessary from the perspective of the subscription resource. Eliminating the hash opens the nice optimization that the POST request and GET request can sometimes be precomputed and stuffed into a single packet without waiting for the POST results to make the round trip. As a result the efficiency problems of having two separate round trips can sometimes be eliminated. A sample set of Model-2req transactions: [HEAD] CLIENT -> SERVER ---------------------- POST [notifications Request-URI] HTTP/1.1 [TBD: stuff to say what the callback URI is] [TBD: stuff to say what the watched resource is] ... SERVER -> CLIENT ---------------------- 200 OK ... CLIENT -> SERVER ---------------------- GET [watched resource Request-URI] HTTP/1.1 ... SERVER -> CLIENT ---------------------- 200 OK ... [time passes] SOURCE -> SINK ---------------------- PUT [callback Request-URI] HTTP/1.1 ... [goto HEAD] - Lucas
hi, did anybody considered using HTTP connection as biderectional channel that contains *two* virtual connections: 1. standard HTTP: client request -> server response 2. opposite direction: server initiates request -> client responses this should work just great with keep-alive for p2p situations ... it is easy to do as HTTP distinguishes between what is request "GET ... HTTP1/..." and response "HTTP code message" so client can identify server request just based on first lisne (starts with "HTTP" => response, otherwise try to interpet as request from server). i searched web but could not find anybody doing or even considering it ... appreciate comments (and URLs) thanks, alek
Cf. http://conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern I think that tunneling in this fashion coupled with rendezvous services is essentially the only way to deal with asymmetrical connectivity. jb as10m wrote: > hi, > > did anybody considered using HTTP connection as biderectional channel > that contains *two* virtual connections: > 1. standard HTTP: client request -> server response > 2. opposite direction: server initiates request -> client responses > this should work just great with keep-alive for p2p situations ... > > it is easy to do as HTTP distinguishes between what is request "GET > ... HTTP1/..." and response "HTTP code message" so client can > identify server request just based on first lisne (starts with "HTTP" > => response, otherwise try to interpet as request from server). > > i searched web but could not find anybody doing or even considering it > ... > > appreciate comments (and URLs) > > thanks, > > alek > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
It occurs to me that part of the problem in reasoning about the behavior of the Web is that the methods of HTTP are actually methods on two different kinds of things --- resources and representations --- and yet URI munges the two concepts together in a rather confusing way. And the concepts are very different: resources are / can be state machines that generate a time-varying stream of representations (or at least they are a time-varying stream of representations, i.e. for static content that evolves over time) while representations are themselves immutable and potentially mobile data. The net effect is that it is difficult to name, sort out, and reason about the semantics of representations vs. resources. POST, PUT, DELETE, etc. operate directly on *resources* named by URI. When I perform one of these operations, it interacts directly with the resource in question and yields an appropriate response / representation of the resource. GET, however, is more ambiguous. In general, it operates on *representations* of a named resource. This may or may not imply an interaction with said resource. In general, GET http://foo.com/bar means "get the first valid representation of the resource at foo.com/bar that's lurking in the proxy chain from here to the origin server for that resource." I.e., GET is really an operation that's conceptually about retrieving representations rather than interacting with the resource in question. The rather fuzzy treatment of resources vs. representations is what leads to a lot of the bletcherousness -wrt- how we handle caching, and a lot of the cognitive dissonance that we experience whenever we bring intermediaries into the picture. There's power in the fuzziness, but in general we don't have a very principled way to deal with all of those representations that we have floating around in caches in various places. (We've got plenty of tools in the various headers and so forth, but the semantics are loose.) This is really a sort of half-formed thought, but the distinction seemed rather interesting. jb
> representations --- and yet URI munges the two concepts together > in a rather confusing way. It can be confusing until you recognize that representations can also be resources. That's what happens when you PUT. But luckily this is already accounted for in HTTP, since the Content-Location header provides a means to identify representations as resources. > And the concepts are very different: > resources are / can be state machines that generate a > time-varying stream of representations (or at least they are a > time-varying stream of representations, i.e. for static content > that evolves over time) while representations are themselves > immutable and potentially mobile data. The net effect is that it > is difficult to name, sort out, and reason about the semantics of > representations vs. resources. They are each just things with identity. That's how I think about it. I haven't had any trouble with that. > POST, PUT, DELETE, etc. operate directly on *resources* named by > URI. When I perform one of these operations, it interacts > directly with the resource in question and yields an appropriate > response / representation of the resource. > > GET, however, is more ambiguous. In general, it operates on > *representations* of a named resource. This may or may not imply > an interaction with said resource. In general, GET > http://foo.com/bar means "get the first valid representation of > the resource at foo.com/bar that's lurking in the proxy chain > from here to the origin server for that resource." I.e., GET is > really an operation that's conceptually about retrieving > representations rather than interacting with the resource in > question. GET is special because it doesn't change state and therefore can have its function distributed about the network. Think of it this way; the "main resource" extends its tentacles to all caches on the Web, but controls them in a sense by how it specifies cache behaviour. If it knows it's going to change frequently, it will use short Expires times to tell the caches that they have to phone home more often. But this policy is most definitely an attribute of the resource, not of a representation. Another way to think about this, is that there's a difference between "the resource" (say, me), my representations (picture, HTML page, vCard), and the software that manages all of that. AFAIK, there's no name for the software. But I think you may be confusing the resource with that software, by your suggestion that GET doesn't operate on the resource. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Lucas Gonze wrote: > >... > > "Model-2req" (coinage here for reasons of convenience) is the one where there > are two requests, a POST to a subscription resource and a GET to a watched > resource. The problem with this is that it implies a transaction. I don't think I'll be able to understand the rest until I understand this sentence. Could you elaborate? Or was the rest of the paragraph elaboration? > ... In my former > proposal on the subject I suggested that there be a GET, the GET results would > be hashed by the client in some well known way, and the hash would be > transmitted with the followup POST as a "baseline state." Remind me of why this is necessary? Also, is there a motivation for not using etags or timestamps or did you just not think of that? > .... The subscription > resource would decide when to fire a notification by computing its own hash of > the watched resource and compare it to the hash sent by the client. That's not how I see it. The subscription resource knows when the resource changes. By definition all clients are out of date. Why keep a per-client hash? > ... However the > hash has to be up to the server, since GET headers often imply a view of the > object. (By "view" I mean a transformation that is orthogonal to the underlying > content of the object. For example the GET may have "Accept: XML-2.0", while > the base resource exists in a neutral form like a unix mbox file.) XML is specific and mbox is neutral? Okay, whatever. ;) Anyhow, the terminology that we've been using is representation (for your "view") versus resource (for your "object"). I don't understand how any of this is necessary yet, though.... Paul Prescod
Jeff Bone wrote:
>
>...
>
> Sure, sure, but there's side effects and then there's side effects. I.e., on some
> strictly literal level it's wrong to call even GET "idempotent" since resources
> are actually time-varying streams of different, mutable representations, and GET
> can indeed (as with counters, etc.) have some kinds of effects.
>
> Think of the subscription in sort of the same sense as incrementing a page hit
> counter.
I knew you were going to say that. But the client supposedly doesn't
care ("much") about a page counter. A notification is extremely
important to the client. So it is a relevant side effect IMO.
I also think that Lucas makes a good point about third-party watchers.
An explicit subsription model supports that.
On the other hand, we could probably steal the idea of one-shot
notifications. There may be virtue in elevating that whole subscription
expiry crap to the application level. With each notification you attempt
to re-subscribe and if it ever fails, it fails. The application should
know why that might happen. Then Lucas doesn't get bogged down into
trying to design a query language for the union of temporal and
numerical expiries.
Paul Prescod
Paul said: > On the other hand, we could probably steal the idea of one-shot > notifications. There may be virtue in elevating that whole subscription > expiry crap to the application level. With each notification you attempt > to re-subscribe and if it ever fails, it fails. The application should > know why that might happen. Agreed. 1-shot notifications eliminate a whole bag of problems. They're pure chocolatey goodness. > Then Lucas doesn't get bogged down into > trying to design a query language for the union of temporal and > numerical expiries. :) It's just like singing in the shower always sounds good to the singer.
me: > > "Model-2req" (coinage here for reasons of convenience) is the one > where there > > are two requests, a POST to a subscription resource and a GET to a watched > > resource. The problem with this is that it implies a transaction. > Paul: > I don't think I'll be able to understand the rest until I understand > this sentence. Could you elaborate? Ok. The POST to the subscription resource has to have a base state to measure against. The base state is the last known state which should not cause a notification to be fired. It might be a version number, a date, a byte count, an SHA-1 hash, whatever. It might not even be an explicit state -- the base state for a database trigger is just whatever the current state is. In my post yesterday, http://groups.yahoo.com/group/rest-discuss/message/691 I proposed that the notification resource should find out the base state on its own, as part of handling the request for notifications. In my previous post, http://groups.yahoo.com/group/rest-discuss/message/640 I proposed that the base state be the one that the GET returned. In that case the GET and POST were a logical unit operating on the same base state. On that level they had to be in synch, and so could be considered a transaction. > > ... In my former > > proposal on the subject I suggested that there be a GET, the GET > results would > > be hashed by the client in some well known way, and the hash would be > > transmitted with the followup POST as a "baseline state." > > Remind me of why this is necessary? Also, is there a motivation for not > using etags or timestamps or did you just not think of that? Per etags and timestamps -- they fall into the general category of hash functions that identify states. I didn't really talk about which hash function was optimal. Since the whole idea of hashing may now be gone, this doesn't matter. The important thing is that the server needs to compute the hash, because the client only has access to a representation. For example the timestamp that matters is the one the server returns. > > > .... The subscription > > resource would decide when to fire a notification by computing its > own hash of > > the watched resource and compare it to the hash sent by the client. > > That's not how I see it. The subscription resource knows when the > resource changes. By definition all clients are out of date. Why keep a > per-client hash? Not! :) I argued for a per-client hash before, and in this rev argued against it. We are in synch on that. > Anyhow, the terminology that we've been using is representation (for > your "view") versus resource (for your "object"). thx. > I don't understand how any of this is necessary yet, though.... It's just an attempt at modeling the source interactions in detail. ...pseudo-coding them to figure out what works and what doesn't. - Lucas
Mark Baker wrote: > > representations --- and yet URI munges the two concepts together > > in a rather confusing way. > > It can be confusing until you recognize that representations can also > be resources. That's what happens when you PUT. But luckily this is > already accounted for in HTTP, since the Content-Location header > provides a means to identify representations as resources. I'm not sure I buy that. It seems to me that PUT identifies a resource by URI and provides a representation in the request body, and that representation isn't actually a resource until the resource *at* the indicated URI sets its state. Another way to put it: the only things that live at origin servers are resources. Everything else --- cached, in transit, etc. --- is a representation. > They are each just things with identity. Yes, but they don't have unique identities --- we use the same URI to talk about both in different contexts. The only way these are disambiguated is by a blend of the semantics of the particular HTTP method we're using and the semantics of various HTTP headers in combination. > Another way to think about this, is that there's a difference between > "the resource" (say, me), my representations (picture, HTML page, > vCard), and the software that manages all of that. AFAIK, there's no > name for the software. But I think you may be confusing the resource > with that software, by your suggestion that GET doesn't operate on > the resource. Okay, well, it's tough to talk about the software entity itself if it's not named. ;-) Yes, I'm referring to that as the resource, with full understanding that the resource *stands for something.* jb
How do you do an efficient delete of many resources by property, not value, in the REST model? Do you have to do a POST? For instance, if I want to delete all messages by Jeff Bone in my FoRK mailing archive. ;) DELETE http://www.mysite.com/FoRK/by-author/Jeff+bone But that would only delete the *one resource* (the query), right? Not the set of them? Paul Prescod
> How do you do an efficient delete of many resources by property, not > value, in the REST model? Do you have to do a POST? For > instance, if I want to delete all messages by Jeff Bone in my FoRK > mailing archive. ;) > > DELETE http://www.mysite.com/FoRK/by-author/Jeff+bone > > But that would only delete the *one resource* (the query), right? Not > the set of > them? Right. You could do something like WebDav Depth to have a DELETE on a container mean delete the subordinate resources. But then you'd need M-DELETE. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
hi, the system you described - switchborad and long lived GET may work but not addressed is question how such GET request would be handled by firewall proxy that could chose to cache it ... however my quesiton was about much simpler approach: using TCP connection to carry HTTP requests and responses in *both* directions (and as such it is extension of HTTP). has anybody did this and have any experience? for example would it be tolerated by HTTP 1.1 proxy - what is it going when receives HTTP request instead of response - or maybe it can be somehow wrapped in multiple responses? thanks, alek --- In rest-discuss@y..., Jeff Bone <jbone@j...> wrote: > > Cf. http://conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern > > I think that tunneling in this fashion coupled with rendezvous services is > essentially the only way to deal with asymmetrical connectivity. > > jb > > as10m wrote: > > > hi, > > > > did anybody considered using HTTP connection as biderectional channel > > that contains *two* virtual connections: > > 1. standard HTTP: client request -> server response > > 2. opposite direction: server initiates request -> client responses > > this should work just great with keep-alive for p2p situations ... > > > > it is easy to do as HTTP distinguishes between what is request "GET > > ... HTTP1/..." and response "HTTP code message" so client can > > identify server request just based on first lisne (starts with "HTTP" > > => response, otherwise try to interpet as request from server). > > > > i searched web but could not find anybody doing or even considering it > > ... > > > > appreciate comments (and URLs) > > > > thanks, > > > > alek > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@y... > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
About the notification message definition: "A notification message must have the following headers: Watched-URI: (URI of the watched resource) Subscription-URI: URI of the subscription object" I believe that the Watched-URI and Subscription-URI are not properly a required part of the notification message. In the idempotent notification model the Subscriber URI contains the entire content of the callback. There are several reasons. 1) It is not properly a subscriber URI but a notification URI. This follows from the fact that the sink receives notifications via PUT. If you PUT multiple notifications to the same URI, and they contain data related to different subscriptions, they will wipe one another out. 2) If the subscription URI in the notification is used as the callback address for renewing/deleting/pending the subscription, or if the Watched-URI is used as the callback address for picking up further events, then an attacker can rewrite these headers to contain the target URI of a distributed denial of service attack. To prevent rewriting, the notification message would have to be either signed or encrypted, and if the sink has to handle signed or encrypted messages, it can't be a plain vanilla HTTP server. So the sink MUST NOT use either the Watched-URI or Subscription-URI as the callback address for renewing/deleting/pending the subscription. 3) If the Watched-URI and Subscription-URI in a notification message are used by the sink to identify the resource in question, an attacker can eavesdrop to discover any meaningful data within those URIs. For example the Subscription-URI may hold enough information to modify a subscription. If the Subscription-URI had been obtained within the context of an HTTPS connection, including it within an uncrypted notification message would disclose a secret. As a general comment on security of the design, the meaning of a notification URI is a secret shared only by the sink and source. That meaning is pre-arranged during requests to the subscription URI. If that rule is consistently followed then only one resource -- the subscription URI -- needs to be HTTPS. I don't mean to block off whatever the utility of the notification headers is, though. Explanations of the intended use of those headers would help in finding an alternative way to meet the need... - Lucas
Obviously one does not want to lock resources on the public internet based on a client's promise to finish a transaction that they may never get around to finishing. Nevertheless, I can see no harm in allowing a client to submit several requests that they would like to be executed atomically when and if the commit message does come through. If the message doesn't, then you just throw away the requests after a timeout. Paul Prescod
The first part is at xml.com. I'd like comments on the second part to be
published later this week. Thanks in advance!
====
REST, Resource Modeling and the Real World
In the last article I described a new model for Web Services
construction. It is called REpresentational State Transfer and applies
the principles of the Web to transaction-oriented services, rather than
publishing-oriented sites. When we apply the strategy in the real world,
we do so using Web technologies such as URIs, HTTP and XML. Unlike the
current generation of Web Services technologies, however, we make those
three technologies central rather than peripheral. We rethink our web
service interface in terms of URIs, HTTP and XML. It is this rethinking
that takes our web services beyond the capabilities of the first
generation.
In this article I want to discuss the applicability of several industry
buzzwords such as reliability, workflow, orchestration, security,
asynchrony, auditing and so forth. Intuitively, it seems that the Web
technologies are not sophisticated enough to handle the requirements for
large-scale inter-business commerce. Those who think of HTTP as a
simple, unidirectional GET and POST protocol will be especially
surprised to learn how sophisticated it can be.
Quick Review
REST is a model for distributed computing. It is the one used by the
world's biggest distributed computing application, the Web. When applied
to web services technologies, it usually depends on a triumvirate of
technologies designed to be extremely extensible: XML, URIs and HTTP.
XML's extensibility should be obvious to this most, but the other two
may not be.
Similarly there are an infinite possible of possible URIs. But, more
important, they can apply to an infinite number of logical entities
called "Resources". URIs are just their addresses. Some REST advocates
call the process of bringing your applications into this model Resource
Modeling. This process is not yet as formal as object oriented modeling
or entity-relation modeling but it is related to those. The strength and
flexibility of REST comes from the creative use of URIs.
HTTP's extensibility stems primarily from the ability to distribute any
payload with predefined or new headers using predefined or (on occasion)
new methods. What makes HTTP really special among all protocols,
however, is its implicit understanding of URIs and resources. URIs are
the defining characteristic of the Web: the glue that makes it work and
scale. HTTP as a protocol keeps them front and center by defining all
methods as operations on URI-addressed resources.
Auditing and Securing REST Web Services
The most decisive difference between web services and previous
distributed computing problems is that web services must be designed to
work across organizational boundaries. Of course, this is also one of
the defining characteristics of the Web. This difference has serious
implications with respect to security, auditing and performance. At the
core of the Web's solution to these problems is the same construct that
is at the core of the Web's solution to everything: URIs. By modeling
the right combination of resources, addressed through URIs, we can build
extremely secure systems.
In the previous article I discussed how it is possible to use ACLs to
secure services which use URIs as their organizational model.
Administrators can apply ACLs to the service itself and to every
document that passes through the service, because each of them would
have a URI. As two business partners work their way through a process,
each step would be represented by a new document with an attached ACL.
Other partners (or auditors) could be given access to this document
later merely by manipulating the ACLs. Another model for security is
called capabilities. This less popular model is more flexible than ACLs
and is nevertheless compatible with second-generation Web Services.
In the REST model, both business partners would have a shared view of
the URI-space representing the process. Rather than sending each other
business documents through an email-style pipe, they would put them on
mutually visible websites with shared URIs and passwords. These could be
easily checked for discrepancies. Third parties can be brought into the
process (perhaps for auditing) merely by pointing them at one or both of
the URIs. Standard HTTPS and HTTP authentication and authorization would
be sufficient to keep intruders from also being able to look at the
documents.
Of course HTTP-based Web Services can go through firewalls easily. But
that is the only point of similarity with RPC tunnels through HTTP such
as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
are being very explicit about what is going on. Your system
administrator can look at her logs to determine what services are
running and who is accessing them. She can disable PUT or POST to make
certain parts of the service read-only. She can use standard filtering
and hacker detection tools. When you use HTTP you and the system
administrator are on the same team.
Conversely, when you tunnel XML-RPC or SOAP through a firewall, you are
deliberately subverting her work and reducing the efficacy of her tools.
Because you are hiding your real actions in the XML body, you make it
much harder for her to use standard filtering tools. This greatly
expands the opportunity for new security holes!
Service Context
People building web services often complain that the "tricky bit" of web
services is maintaining shared context. For instance, context might
include:
Where are we in this business process?
What transactions have we done in the past?
Are there any resources that I promise to hold for you?
Are there any notifications I promise to deliver to you later?
What permissions do you have?
There are three main ways that two partners can share context. One is to
send the entire context with every message. This is obviously not very
scalable. As the relationship deepens the context will grow larger and
larger. Another option is to merely require each partner to keep context
privately and presume that the other partner has the same idea of
context. As you can imagine, this is quite unreliable. A network hiccup
or programming bug could make the contexts diverge. The mechanism used
on the Web today is to assign URIs to the context. For instance on
Expedia there is a "My Itinerary" URI for each individual. Within that,
every purchase you have recently made has its own URI. While you are
purchasing a new ticket, each step in the process is represented by
another URI.
The same principle applies to business-to-business processes. Of course
there will be some differences. Typically the canonical format for
context in a business process with be XML. HTML will be generated as a
view on that XML. But do not underestimate the importance of that
human-readable view! Business partners will probably be careful to store
a copy of the context in case of network outage, programming bug or
outright fraud.
This is precisely what the HTTP and the REST model were designed to
allow. Remember that REST stands for REpresentational State Transfer.
The HTTP client transfers the state (the context) from the server to the
client using a representation like XML or HTML (depending on its needs).
Context information can be linked together with XLink or RDF. Each bit
of it can be individually secured using ACLs or capabilities. This
mechanism for handling context seems so obvious to me as to be near
inevitable.
Orchestration
Every method that can be invoked on a resource or service is a possible
connector between the client and the service. If there are a hundred
methods then there are a hundred connectors. If every service has a
hundred different methods then your connections become very complex -
essentially point-to-point integrations rather than reusable patterns.
There are various systems in the computing world that have proven the
power of having just a few methods rather than many. For instance, every
true Unix hacker knows that the command line is incredibly powerful
because it is possible to pipe data from one process to another using
the redirection "methods", ">", ">>", "<". The other Unix command line
tools act as standardized filters and transformers connected by these
methods.
Similarly, if you think of a SQL table as a resource, the methods SQL
makes available are only SELECT, UPDATE, INSERT and DELETE. The rest of
SQL is a set of transformers and filters that allow you to combine these
methods into services. .NET My Services has Query, Insert, Replace,
Update and Delete. As I showed in the last article, UDDI has get_*,
delete_* and save_*. This pattern is ubiquitous.
HTTP has GET, PUT, POST and DELETE. Anything that can be done with SOAP
RPC or any other RPC can be done with those four methods. In fact, it is
precisely because HTTP has few methods that HTTP clients and servers can
grow and be extended independently without confusing each other. Rather
than invent new methods they find ways to represent new concepts in data
structures (increasingly XML data structures) and headers.
Now that we've boiled down our system to these basic methods, it turns
out that we have the beginnings of a web service coordination,
orchestration and assembly language. I could imagine defining a new web
service as easily as:
i = GET http://www.stockquotes.com/xmlquotes?IBM
m = GET http://www.stockquotes.com/xmlquotes?MSFT
if i > m:
WITH AUTHENTICATION $myuserid $mypassword
POST http://www.etrade.com/stocks/IBM
else:
POST http://www.etrade.com/stocks/MSFT
Or maybe we don't need a new language. Perhaps we could incorporate
these principles into existing scripting languages. The point is that
unifying the method vocabulary of the web provides tremendous
opportunities for simplifying interactions. Nobody learning a new web
service would ever have to learn the semantics of the various methods
again. Web services can be combined through simple Unix-style pipes: GET
this, GET that, transform, PUT there.
Of course there is no free lunch. Using someone else's web service
requires you to understand their data structures (XML vocabulary and
links between documents). But this is true whether we use REST or SOAP
RPC. RPC APIs merely hide the problem behind an extra layer of
non-standardization. First you must figure out the method names
available. Then you must still figure out the data structures that may
be used as parameters. And then behind those data structures is the
implicit data model of the web service. UDDI has an implicit relational
data model. .NET My Services has a concept of a "virtual document". The
whole thing would be simpler if the implicit data model was directly
exposed as XML documents available as URI-addressed resources through
HTTP. This in no way dictates the underlying implementation but it is
based upon a shared, web-wide data model that allows for easy
coordination!
Once you begin to orchestrate multiple web services, transaction
processing becomes much harder. HTTP does not have a magical solution to
this problem but neither do specifications such as SOAP or ebXML. The
solutions proposed by the OASIS Business Transactions working group are
currently protocol agnostic and should work fine with HTTP, once a
binding is formalized. A more complete analysis of their integration
with REST would be an interesting project, but it has not been done yet.
Asynchrony
People often complain that HTTP is not asynchronous. Unfortunately they
often mean different things by that term. Most often they compare it to
SMTP as an example of an asynchronous protocol. But you could make the
case that both are synchronous or asynchronous depending on how you
define those terms. Both are synchronous in that you cannot send a
message without waiting for a reply from the server. If an SMTP server
application is badly written, it can hold a connection open for hours,
just as a badly written HTTP web service might. Similarly, both can be
considered asynchronous in the sense that servers (HTTP or SMTP) never
know when they will get a request from a client. Requests are not
coordinated in advance. If one HTTP server makes a request to another
then it is exactly as synchronous or asynchronous as one SMTP server
making a request to another.
Email is asynchronous not primarily because of SMTP itself, but the
collection of software that does store-and-forward, failure notification
and replies. In an XML web services world, much of this must be
rewritten to deal with URIs so as to manage shared context. For
instance, every message that passes through a web service should
probably be given a persistent HTTP URI for auditing purposes.
Similarly, the reply-to header should refer to an HTTP resource, not an
email address. Although early web services will of course build on
whatever software is already available, the vast majority of it will be
written from scratch. I feel that it would make little sense to spend
the effort adapting a non-Web integrated protocol like SMTP to the Web
rather than merely using HTTP.
Still, it would require extensions to HTTP to offer all of the features
of SMTP (in addition to HTTP's own unique features). Primarily, HTTP
needs a concept of "callback" or "notification". Although this has been
done many times in many places, there is no single standardized way to
do this. Software dealing with notifications is not as reusable as other
HTTP-based software modules. There is work under progress to correct
this situation, under the name "HTTPEvents". Second, HTTP needs concepts
of explicit and implicit store and forward relays, transformational
intermediaries and return paths. These may be borrowed from SOAP headers
and SOAP Routing. In fact, some REST proponents believe that this is the
only part of SOAP that is strongly compatible with the Web and HTTP.
In summary, various kinds of asynchrony are certainly possible in HTTP.
Many commercial applications have been built using HTTP in a
peer-to-peer, asynchronous fashion, by companies as large as Microsoft
to as small as KnowNow. But there is active effort standardizing the
approach taken on the REST list.
Reliability
Networks are inherently unreliable and the Internet is an extreme case
of this. You must build network-based software to cope with failure no
matter what protocol you are using. Nevertheless, a combination of
software and protocols can make message delivery more reliable than it
would otherwise be. What most people ask for is that a message be
delivered if at all possible, and be delivered at most once. If it is
not possible to deliver then it should be reported to the application.
Writing reliable-delivery software with HTTP is relatively easy. Thanks
to the guarantees of TCP, you can always know for sure if you received
an appropriate response. If you did not, then in many cases it is safe
to repeat the message send, due to the principle of idempotency. In
other cases it takes a slight permutation of the service to make it one
that builds upon idempotency. Although this is not rocket science, a
full description does take more than a couple of paragraphs.
The bottom line is that software written on top of HTTP can make all of
the same guarantees that expensive message queuing software can. Once
you have done that, the only difference is that the message queuing
software builds reliability around a proprietary protocol that cannot
(typically) be used between business partners! If you would like to use
the message queuing software within your single organization then you
can easily tunnel HTTP on top of it and get the best of both worlds.
Case Studies
Despite its advantages, HTTP-based, URI-centric resource modeling is not
a common way of thinking about networking issues and REST-based web
services are not very common. On the other hand, useful, scalable,
public RPC-based web services are also quite difficult to find. The most
obvious examples of HTTP-based web services are actual web sites. Any
site that presents a purchasing process as a series of web pages can
trivially be changed to do the same thing with XML. People who go
through this process get all of the benefits of REST web services and
none of the expense of re-implementing their business logic around a
SOAP-RPC model.
Two businesses that have created (admittedly simple) REST web services
are Google and O'Reilly. Google offers to its subscribers the ability to
have search results published as XML rather than HTML. This makes it
easy to build various sorts of sophisticated programs on top of Google
without worrying about shifting HTML formats. Unfortunately the public
version of Google no longer supports the XML feature. Presumably there
was some danger it would undermine the banner-based business model!
Nevertheless, REST was a natural fit for Google. Essentially all they
had to do was change their HTML generating code to XML and they had a
Web Service instead of a Web Site.
The Meerkat Example
O'Reilly's Meerkat is one of a very few useful, public web services.
Unlike the majority of the services described on XMethods, Meerkat is
used by thousands of sites every single day.
Meerkat uses the three foundation technologies of second-generation web
services. It uses a standardized XML vocabulary: RSS. Meerkat would
never have become as powerful and scalable if it had invented its own
vocabulary. It absolutely depends on the fact that it can integrate
information from hundreds of sites that use the RSS vocabulary and the
HTTP protocol.
In addition to using HTTP and RSS, Meerkat uses URIs as its addressing
scheme. It has a very sophisticated URI-based "API" described here:
http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html
Meerkat's content is also available through an XML-RPC API described in
http://www.xml.com/pub/a/2001/07/18/excerpt/xml-rpc.html. Before the
REST philosophy was popularized it was not clear that Meerkat's
HTTP/XML-based interface was already a complete web service! It would be
an interesting project to compare and contrast these two interfaces in a
formal essay.
One interesting point, however, is that all of Meerkat's content
aggregation is done through HTTP, not XML-RPC or SOAP. It would be
ludicrous to suggest that every content publisher in the world should
not only support XML-RPC and SOAP but also some particular set of
methods. This would be the situation if instead of inventing the RSS
vocabulary the world had standardized the "RSS web service interface."
To be fair, HTTP's advantages would have been less pronounced if
Meerkat's interaction with these sites had required two-way
communication instead of a simple one-way information fetch.
Nevertheless, there is nothing particularly difficult about using HTTP
in a two-way fashion. It is a virtue of HTTP that it is much easier than
other models for one-way ("data publishing") services and not much
harder to use for bi-directional, transactional services.
Meerkat shows that when many sites share an XML vocabulary, a protocol
and a URI namespace, new services arise organically. It is arguably the
first equivalent in the Web Services world to a large-scale, distributed
service like Yahoo. Meerkat's success suggests strongly that the most
important enabler of large-scale, distributed web services will be
common XML vocabularies.
REST limitations
There is no free lunch. REST is not a panacea. The biggest problem most
will have with REST is that it requires you to rethink your problem in
terms of manipulations of addressable resources instead of method calls
to a component. Of course you may actually implement it on the server
side however you want. But the API you communicate to your clients
should be in terms of HTTP manipulations on XML documents addressed by
URIs, not in terms of method calls with parameters.
Your customers may well prefer a component-based interface to a REST
interface. Programmers are more used to APIs and APIs are better
integrated into existing programming languages. For client-side
programmers, REST is somewhat of a departure although for server-side
programmers it is not much different than what they have been doing for
the last several years.
The client side may get easier in the future. It may be possible to use
WSDL to map URIs to logical operations that can in turn be mapped to
method calls in a programming language. Although this is described in
the WSDL specification, implementations of this feature are few and far
between. Even so, RPC will likely always be easier than REST. If a
particular problem can be solved with RPC and future extensibility is
not an issue then you should certainly use the simpler approach.
HTTP is also not appropriate in some circumstances. Because HTTP runs on
top of TCP, it can have high latency. HTTP is designed primarily for the
kind of coarse-grained interactions that are used on the public
internet, not the kind of fine-grained ones that might be appropriate on
a single desktop, within a department or even in certain enterprise
situations. Once again, if DCOM or CORBA solves your fine-grained
problem then there is no reason to move to REST. In my opinion, REST
will dominate primarily in the world of partner-facing, external Web
Services.
Why REST is the next Generation
Let's say that ACME Inc sets up a major web service (like UDDI) using
the SOAP RPC philosophy. BARTEL Inc. sets up a competing web service
using the HTTP philosophy. Customers will gravitate to the REST-based
one because it will be simpler on almost every measurable axis: message
size, message complexity, number of concepts (URI versus a dozen other
naming schemes) and compatibility with their existing systems. The
service can be automatically and instantly accessible from any device
that can do HTTP and XML. The Context Problem will be much more
tractable. Management will appreciate the service's ease of maintenance,
testing and security.
But REST will really win out over the long term when the two services
try to evolve. The REST-based service uses the most flexible naming and
addressing scheme ever invented. It can instantly incorporate a
peer-to-peer model by allowing references to data on PCs. When they
invent a way to make data on cell phones URI-addressable, every cell
phone will be able to integrate data with the service.
The rhetoric around web services describes them as "like the web, but
for machine to machine communications". They are said to be a mechanism
for publishing processes as the Web published data. REST turns the
rhetoric into reality. With REST you really do think of Web Services as
a means of publishing information, components and processes. And you
really do use the technologies and architecture that make the Web so
effective.
----- Original Message -----
From: "Paul Prescod" <paul@...>
> The first part is at xml.com. I'd like comments on the second part to be
> published later this week. Thanks in advance!
> ====
> REST, Resource Modeling and the Real World
>
> In the last article I described a new model for Web Services
> construction. It is called REpresentational State Transfer and applies
> the principles of the Web to transaction-oriented services, rather than
> publishing-oriented sites. When we apply the strategy in the real world,
> we do so using Web technologies such as URIs, HTTP and XML. Unlike the
> current generation of Web Services technologies, however, we make those
> three technologies central rather than peripheral. We rethink our web
> service interface in terms of URIs, HTTP and XML. It is this rethinking
> that takes our web services beyond the capabilities of the first
> generation.
>
> In this article I want to discuss the applicability of several industry
> buzzwords such as reliability, workflow, orchestration, security,
> asynchrony, auditing and so forth. Intuitively, it seems that the Web
> technologies are not sophisticated enough to handle the requirements for
> large-scale inter-business commerce. Those who think of HTTP as a
> simple, unidirectional GET and POST protocol will be especially
> surprised to learn how sophisticated it can be.
>
> Quick Review
>
> REST is a model for distributed computing. It is the one used by the
> world's biggest distributed computing application, the Web. When applied
> to web services technologies, it usually depends on a triumvirate of
[mike] 'triumvirate' - quite the ten-dollar word, how about 'trio'
> technologies designed to be extremely extensible: XML, URIs and HTTP.
> XML's extensibility should be obvious to this most, but the other two
> may not be.
>
> Similarly there are an infinite possible of possible URIs.
[mike] Similarly to what?
> But, more
> important, they can apply to an infinite number of logical entities
> called "Resources". URIs are just their addresses.
[mike] it'd be neat to have a 'sidebar' talking about 'names .vs. addresses'
> Some REST advocates
> call the process of bringing your applications into this model Resource
> Modeling. This process is not yet as formal as object oriented modeling
> or entity-relation modeling but it is related to those. The strength and
> flexibility of REST comes from the creative use of URIs.
[mike] 'creative' implies un-designed, how about 'consistent' or 'strong' or
'intelligent' or something positive.
>
> HTTP's extensibility stems primarily from the ability to distribute any
> payload with predefined or new headers using predefined or (on occasion)
> new methods. What makes HTTP really special among all protocols,
> however, is its implicit understanding of URIs and resources.
[mike] is it 'implicit understanding' or 'central focus'/whatever?
> URIs are
> the defining characteristic of the Web: the glue that makes it work and
> scale. HTTP as a protocol keeps them front and center by defining all
> methods as operations on URI-addressed resources.
>
> Auditing and Securing REST Web Services
>
> The most decisive difference between web services and previous
> distributed computing problems is that web services must be designed to
> work across organizational boundaries. Of course, this is also one of
> the defining characteristics of the Web. This difference has serious
> implications with respect to security, auditing and performance. At the
> core of the Web's solution to these problems is the same construct that
> is at the core of the Web's solution to everything: URIs. By modeling
> the right combination of resources, addressed through URIs, we can build
> extremely secure systems.
>
> In the previous article I discussed how it is possible to use ACLs to
> secure services which use URIs as their organizational model.
> Administrators can apply ACLs to the service itself and to every
> document that passes through the service, because each of them would
> have a URI. As two business partners work their way through a process,
> each step would be represented by a new document with an attached ACL.
> Other partners (or auditors) could be given access to this document
> later merely by manipulating the ACLs. Another model for security is
> called capabilities. This less popular model is more flexible than ACLs
[mike] popular -> prevalent (it isn't as widely known, so 'popularity' isn't
quite correct - KragenS might be able to provide more detail on how it ties
in with ReST)
> and is nevertheless compatible with second-generation Web Services.
>
> In the REST model, both business partners would have a shared view of
> the URI-space representing the process. Rather than sending each other
> business documents through an email-style pipe, they would put them on
> mutually visible websites with shared URIs and passwords. These could be
> easily checked for discrepancies. Third parties can be brought into the
> process (perhaps for auditing) merely by pointing them at one or both of
> the URIs. Standard HTTPS and HTTP authentication and authorization would
> be sufficient to keep intruders from also being able to look at the
> documents.
>
> Of course HTTP-based Web Services can go through firewalls easily. But
> that is the only point of similarity with RPC tunnels through HTTP such
[mike] 'rpc tunnels through http' -> 'rpc tunneling through http' ('tunnel'
is both verb and noun, would be nice to clarify)
> as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
> are being very explicit about what is going on. Your system
> administrator can look at her logs to determine what services are
[mike] 'her' -> 'the' (overly p.c. is distracting for me...)
> running and who is accessing them. She can disable PUT or POST to make
> certain parts of the service read-only. She can use standard filtering
> and hacker detection tools. When you use HTTP you and the system
> administrator are on the same team.
>
> Conversely, when you tunnel XML-RPC or SOAP through a firewall, you are
> deliberately subverting her work and reducing the efficacy of her tools.
> Because you are hiding your real actions in the XML body, you make it
> much harder for her to use standard filtering tools. This greatly
> expands the opportunity for new security holes!
>
> Service Context
>
> People building web services often complain that the "tricky bit" of web
> services is maintaining shared context. For instance, context might
> include:
>
> Where are we in this business process?
> What transactions have we done in the past?
> Are there any resources that I promise to hold for you?
> Are there any notifications I promise to deliver to you later?
> What permissions do you have?
>
> There are three main ways that two partners can share context. One is to
> send the entire context with every message. This is obviously not very
> scalable. As the relationship deepens the context will grow larger and
> larger. Another option is to merely require each partner to keep context
> privately and presume that the other partner has the same idea of
> context. As you can imagine, this is quite unreliable. A network hiccup
> or programming bug could make the contexts diverge. The mechanism used
> on the Web today is to assign URIs to the context. For instance on
> Expedia there is a "My Itinerary" URI for each individual. Within that,
> every purchase you have recently made has its own URI. While you are
> purchasing a new ticket, each step in the process is represented by
> another URI.
>
> The same principle applies to business-to-business processes. Of course
> there will be some differences. Typically the canonical format for
> context in a business process with be XML. HTML will be generated as a
> view on that XML. But do not underestimate the importance of that
> human-readable view! Business partners will probably be careful to store
> a copy of the context in case of network outage, programming bug or
> outright fraud.
>
> This is precisely what the HTTP and the REST model were designed to
> allow. Remember that REST stands for REpresentational State Transfer.
> The HTTP client transfers the state (the context) from the server to the
> client using a representation like XML or HTML (depending on its needs).
> Context information can be linked together with XLink or RDF.
[mike] A bit esoteric a bit quick for the typical crowd - may need to start
slow with just mentioning 'urls' and 'href' attributes, and get into
XLink/XPointer/etc later (I don't know how RDF is a linking enabler..)
> Each bit
> of it can be individually secured using ACLs or capabilities. This
> mechanism for handling context seems so obvious to me as to be near
> inevitable.
>
> Orchestration
>
> Every method that can be invoked on a resource or service is a possible
> connector between the client and the service. If there are a hundred
> methods then there are a hundred connectors. If every service has a
> hundred different methods then your connections become very complex -
> essentially point-to-point integrations rather than reusable patterns.
>
> There are various systems in the computing world that have proven the
> power of having just a few methods rather than many. For instance, every
> true Unix hacker knows that the command line is incredibly powerful
> because it is possible to pipe data from one process to another using
> the redirection "methods", ">", ">>", "<". The other Unix command line
> tools act as standardized filters and transformers connected by these
> methods.
>
> Similarly, if you think of a SQL table as a resource, the methods SQL
> makes available are only SELECT, UPDATE, INSERT and DELETE. The rest of
> SQL is a set of transformers and filters that allow you to combine these
> methods into services. .NET My Services has Query, Insert, Replace,
> Update and Delete. As I showed in the last article, UDDI has get_*,
> delete_* and save_*. This pattern is ubiquitous.
[mike] 'this pattern is ...' -> 'this pattern of a small number of methods
on a large amount of data is ...' (can't hurt to re-iterate the point of
rest)
>
> HTTP has GET, PUT, POST and DELETE. Anything that can be done with SOAP
> RPC or any other RPC can be done with those four methods. In fact, it is
> precisely because HTTP has few methods that HTTP clients and servers can
> grow and be extended independently without confusing each other. Rather
> than invent new methods they find ways to represent new concepts in data
> structures (increasingly XML data structures) and headers.
>
> Now that we've boiled down our system to these basic methods, it turns
> out that we have the beginnings of a web service coordination,
> orchestration and assembly language. I could imagine defining a new web
> service as easily as:
>
> i = GET http://www.stockquotes.com/xmlquotes?IBM
> m = GET http://www.stockquotes.com/xmlquotes?MSFT
> if i > m:
> WITH AUTHENTICATION $myuserid $mypassword
> POST http://www.etrade.com/stocks/IBM
> else:
> POST http://www.etrade.com/stocks/MSFT
>
> Or maybe we don't need a new language. Perhaps we could incorporate
> these principles into existing scripting languages. The point is that
> unifying the method vocabulary of the web provides tremendous
> opportunities for simplifying interactions. Nobody learning a new web
> service would ever have to learn the semantics of the various methods
> again. Web services can be combined through simple Unix-style pipes: GET
> this, GET that, transform, PUT there.
>
> Of course there is no free lunch. Using someone else's web service
> requires you to understand their data structures (XML vocabulary and
> links between documents). But this is true whether we use REST or SOAP
> RPC. RPC APIs merely hide the problem behind an extra layer of
> non-standardization. First you must figure out the method names
> available. Then you must still figure out the data structures that may
> be used as parameters. And then behind those data structures is the
> implicit data model of the web service. UDDI has an implicit relational
> data model. .NET My Services has a concept of a "virtual document".
[mike] 'virtual document'? really? I gotta check that out...
> The
> whole thing would be simpler if the implicit data model was directly
> exposed as XML documents available as URI-addressed resources through
> HTTP. This in no way dictates the underlying implementation but it is
> based upon a shared, web-wide data model that allows for easy
> coordination!
>
> Once you begin to orchestrate multiple web services, transaction
> processing becomes much harder. HTTP does not have a magical solution to
> this problem but neither do specifications such as SOAP or ebXML. The
> solutions proposed by the OASIS Business Transactions working group are
> currently protocol agnostic and should work fine with HTTP, once a
> binding is formalized. A more complete analysis of their integration
> with REST would be an interesting project, but it has not been done yet.
>
> Asynchrony
>
> People often complain that HTTP is not asynchronous. Unfortunately they
> often mean different things by that term. Most often they compare it to
> SMTP as an example of an asynchronous protocol. But you could make the
> case that both are synchronous or asynchronous depending on how you
> define those terms. Both are synchronous in that you cannot send a
> message without waiting for a reply from the server. If an SMTP server
> application is badly written, it can hold a connection open for hours,
> just as a badly written HTTP web service might. Similarly, both can be
> considered asynchronous in the sense that servers (HTTP or SMTP) never
> know when they will get a request from a client.
[mike] 'get' -> 'receive' (get might imply proactive processing or polling)
> Requests are not
> coordinated in advance. If one HTTP server makes a request to another
> then it is exactly as synchronous or asynchronous as one SMTP server
> making a request to another.
>
> Email is asynchronous not primarily because of SMTP itself, but the
> collection of software that does store-and-forward, failure notification
> and replies. In an XML web services world, much of this must be
> rewritten to deal with URIs so as to manage shared context. For
> instance, every message that passes through a web service should
> probably be given a persistent HTTP URI for auditing purposes.
> Similarly, the reply-to header should refer to an HTTP resource, not an
> email address. Although early web services will of course build on
> whatever software is already available, the vast majority of it will be
> written from scratch. I feel that it would make little sense to spend
> the effort adapting a non-Web integrated protocol like SMTP to the Web
> rather than merely using HTTP.
>
> Still, it would require extensions to HTTP to offer all of the features
> of SMTP (in addition to HTTP's own unique features). Primarily, HTTP
> needs a concept of "callback" or "notification". Although this has been
> done many times in many places, there is no single standardized way to
> do this. Software dealing with notifications is not as reusable as other
> HTTP-based software modules. There is work under progress to correct
> this situation, under the name "HTTPEvents". Second, HTTP needs concepts
> of explicit and implicit store and forward relays, transformational
> intermediaries and return paths. These may be borrowed from SOAP headers
> and SOAP Routing. In fact, some REST proponents believe that this is the
> only part of SOAP that is strongly compatible with the Web and HTTP.
>
> In summary, various kinds of asynchrony are certainly possible in HTTP.
> Many commercial applications have been built using HTTP in a
> peer-to-peer, asynchronous fashion, by companies as large as Microsoft
> to as small as KnowNow. But there is active effort standardizing the
> approach taken on the REST list.
>
> Reliability
>
> Networks are inherently unreliable and the Internet is an extreme case
> of this. You must build network-based software to cope with failure no
> matter what protocol you are using. Nevertheless, a combination of
> software and protocols can make message delivery more reliable than it
> would otherwise be. What most people ask for is that a message be
> delivered if at all possible, and be delivered at most once. If it is
> not possible to deliver then it should be reported to the application.
>
> Writing reliable-delivery software with HTTP is relatively easy. Thanks
> to the guarantees of TCP, you can always know for sure if you received
> an appropriate response. If you did not, then in many cases it is safe
> to repeat the message send, due to the principle of idempotency.
[mike] another sidebar with concrete examples and 'idempotency' would be
good here...
> In
> other cases it takes a slight permutation of the service to make it one
> that builds upon idempotency. Although this is not rocket science, a
> full description does take more than a couple of paragraphs.
>
> The bottom line is that software written on top of HTTP can make all of
> the same guarantees that expensive message queuing software can. Once
> you have done that, the only difference is that the message queuing
> software builds reliability around a proprietary protocol that cannot
> (typically) be used between business partners! If you would like to use
> the message queuing software within your single organization then you
> can easily tunnel HTTP on top of it and get the best of both worlds.
>
> Case Studies
>
> Despite its advantages, HTTP-based, URI-centric resource modeling is not
> a common way of thinking about networking issues and REST-based web
> services are not very common. On the other hand, useful, scalable,
> public RPC-based web services are also quite difficult to find. The most
> obvious examples of HTTP-based web services are actual web sites. Any
> site that presents a purchasing process as a series of web pages can
> trivially be changed to do the same thing with XML. People who go
> through this process get all of the benefits of REST web services and
> none of the expense of re-implementing their business logic around a
> SOAP-RPC model.
>
> Two businesses that have created (admittedly simple) REST web services
> are Google and O'Reilly. Google offers to its subscribers the ability to
> have search results published as XML rather than HTML. This makes it
> easy to build various sorts of sophisticated programs on top of Google
> without worrying about shifting HTML formats. Unfortunately the public
> version of Google no longer supports the XML feature. Presumably there
> was some danger it would undermine the banner-based business model!
> Nevertheless, REST was a natural fit for Google. Essentially all they
> had to do was change their HTML generating code to XML and they had a
> Web Service instead of a Web Site.
>
> The Meerkat Example
>
> O'Reilly's Meerkat is one of a very few useful, public web services.
> Unlike the majority of the services described on XMethods, Meerkat is
> used by thousands of sites every single day.
>
> Meerkat uses the three foundation technologies of second-generation web
> services. It uses a standardized XML vocabulary: RSS. Meerkat would
> never have become as powerful and scalable if it had invented its own
> vocabulary. It absolutely depends on the fact that it can integrate
> information from hundreds of sites that use the RSS vocabulary and the
> HTTP protocol.
>
> In addition to using HTTP and RSS, Meerkat uses URIs as its addressing
> scheme. It has a very sophisticated URI-based "API" described here:
> http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html
>
> Meerkat's content is also available through an XML-RPC API described in
> http://www.xml.com/pub/a/2001/07/18/excerpt/xml-rpc.html. Before the
> REST philosophy was popularized it was not clear that Meerkat's
> HTTP/XML-based interface was already a complete web service! It would be
> an interesting project to compare and contrast these two interfaces in a
> formal essay.
>
> One interesting point, however, is that all of Meerkat's content
> aggregation is done through HTTP, not XML-RPC or SOAP. It would be
> ludicrous to suggest that every content publisher in the world should
> not only support XML-RPC and SOAP but also some particular set of
> methods. This would be the situation if instead of inventing the RSS
> vocabulary the world had standardized the "RSS web service interface."
>
> To be fair, HTTP's advantages would have been less pronounced if
> Meerkat's interaction with these sites had required two-way
> communication instead of a simple one-way information fetch.
> Nevertheless, there is nothing particularly difficult about using HTTP
> in a two-way fashion. It is a virtue of HTTP that it is much easier than
> other models for one-way ("data publishing") services and not much
> harder to use for bi-directional, transactional services.
>
> Meerkat shows that when many sites share an XML vocabulary, a protocol
> and a URI namespace, new services arise organically. It is arguably the
> first equivalent in the Web Services world to a large-scale, distributed
> service like Yahoo. Meerkat's success suggests strongly that the most
> important enabler of large-scale, distributed web services will be
> common XML vocabularies.
>
> REST limitations
>
> There is no free lunch. REST is not a panacea. The biggest problem most
> will have with REST is that it requires you to rethink your problem in
> terms of manipulations of addressable resources instead of method calls
> to a component. Of course you may actually implement it on the server
> side however you want. But the API you communicate to your clients
> should be in terms of HTTP manipulations on XML documents addressed by
> URIs, not in terms of method calls with parameters.
>
> Your customers may well prefer a component-based interface to a REST
> interface. Programmers are more used to APIs and APIs are better
> integrated into existing programming languages. For client-side
> programmers, REST is somewhat of a departure although for server-side
> programmers it is not much different than what they have been doing for
> the last several years.
>
> The client side may get easier in the future. It may be possible to use
> WSDL to map URIs to logical operations that can in turn be mapped to
> method calls in a programming language. Although this is described in
> the WSDL specification, implementations of this feature are few and far
> between. Even so, RPC will likely always be easier than REST. If a
> particular problem can be solved with RPC and future extensibility is
> not an issue then you should certainly use the simpler approach.
[mike] 'use' -> 'consider' (don't recommend an approach that is short term
and non-interoperable)
>
> HTTP is also not appropriate in some circumstances. Because HTTP runs on
> top of TCP, it can have high latency.
[mike] 'high' is relative, give some concrete numbers so people don't make
decisions based on the wrong assumptions
> HTTP is designed primarily for the
> kind of coarse-grained interactions that are used on the public
> internet, not the kind of fine-grained ones that might be appropriate on
> a single desktop, within a department or even in certain enterprise
> situations. Once again, if DCOM or CORBA solves your fine-grained
> problem then there is no reason to move to REST. In my opinion, REST
> will dominate primarily in the world of partner-facing, external Web
> Services.
>
> Why REST is the next Generation
>
> Let's say that ACME Inc sets up a major web service (like UDDI) using
> the SOAP RPC philosophy. BARTEL Inc. sets up a competing web service
> using the HTTP philosophy. Customers will gravitate to the REST-based
> one because it will be simpler on almost every measurable axis: message
> size, message complexity, number of concepts (URI versus a dozen other
> naming schemes) and compatibility with their existing systems. The
> service can be automatically and instantly accessible from any device
> that can do HTTP and XML. The Context Problem will be much more
> tractable. Management will appreciate the service's ease of maintenance,
> testing and security.
>
> But REST will really win out over the long term when the two services
> try to evolve. The REST-based service uses the most flexible naming and
> addressing scheme ever invented. It can instantly incorporate a
> peer-to-peer model by allowing references to data on PCs. When they
> invent a way to make data on cell phones URI-addressable, every cell
> phone will be able to integrate data with the service.
>
> The rhetoric around web services describes them as "like the web, but
> for machine to machine communications". They are said to be a mechanism
> for publishing processes as the Web published data. REST turns the
> rhetoric into reality. With REST you really do think of Web Services as
> a means of publishing information, components and processes. And you
> really do use the technologies and architecture that make the Web so
> effective.
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> Obviously one does not want to lock resources on the public internet > based on a client's promise to finish a transaction that they may never > get around to finishing. Nevertheless, I can see no harm in allowing a > client to submit several requests that they would like to be executed > atomically when and if the commit message does come through. If the > message doesn't, then you just throw away the requests after a timeout. 2PC is one form of implementing transactions between disparate parties, but it's not the only way. So assuming you just want some notion of a "transaction", there's a number of options. It also depends how much of "ACID" you need. I recall that even in SQL92, they broke down some of the transaction opacity that was prevalent in 89. As I mentioned offline, I had at one time considered a CHECKPOINT/ RESTORE method pair, where you'd get an etag like thing that represented the resource's state at some point in time. RESTORE with this tag would return to the resource to that state with the intention of rolling back everything since the time it was created ... unless it didn't want to. I think there's lots of interesting work to be done there. I haven't had much interest in transactional systems for some time, but I know lots of people do. 8-) I figure that any general solution to this problem will have to look a lot like a compensating transaction, where you make your best effort to fix stuff up, but if that doesn't work, you manage it as part of your app, in the same way you manage 5xx errors with HTTP. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Mike Dierken" wrote:
>
> [mike] 'triumvirate' - quite the ten-dollar word, how about 'trio'
Fine.
> > technologies designed to be extremely extensible: XML, URIs and HTTP.
> > XML's extensibility should be obvious to this most, but the other two
> > may not be.
> >
> > Similarly there are an infinite possible of possible URIs.
> [mike] Similarly to what?
Similarly URIs are extensible. I'll clarify that.
> > But, more
> > important, they can apply to an infinite number of logical entities
> > called "Resources". URIs are just their addresses.
> [mike] it'd be neat to have a 'sidebar' talking about 'names .vs. addresses'
Might be a distraction.
> > Some REST advocates
> > call the process of bringing your applications into this model Resource
> > Modeling. This process is not yet as formal as object oriented modeling
> > or entity-relation modeling but it is related to those. The strength and
> > flexibility of REST comes from the creative use of URIs.
> [mike] 'creative' implies un-designed, how about 'consistent' or 'strong' or
> 'intelligent' or something positive.
"pervasive"
> > HTTP's extensibility stems primarily from the ability to distribute any
> > payload with predefined or new headers using predefined or (on occasion)
> > new methods. What makes HTTP really special among all protocols,
> > however, is its implicit understanding of URIs and resources.
> [mike] is it 'implicit understanding' or 'central focus'/whatever?
"built-in support for"
>...
> > later merely by manipulating the ACLs. Another model for security is
> > called capabilities. This less popular model is more flexible than ACLs
> [mike] popular -> prevalent (it isn't as widely known, so 'popularity' isn't
> quite correct - KragenS might be able to provide more detail on how it ties
> in with ReST)
Okay, prevalent.
>...
> > Of course HTTP-based Web Services can go through firewalls easily. But
> > that is the only point of similarity with RPC tunnels through HTTP such
> [mike] 'rpc tunnels through http' -> 'rpc tunneling through http' ('tunnel'
> is both verb and noun, would be nice to clarify)
Okay.
> > as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
> > are being very explicit about what is going on. Your system
> > administrator can look at her logs to determine what services are
> [mike] 'her' -> 'the' (overly p.c. is distracting for me...)
This isn't the only reference to "her". Eventually I'll need to use a
pronoun. Shame about the English language. ;) The truly PC use "hir".
Which is more distracting: "She" or "(S)he"? Yes, I know they are both
distracting...which is MORE.
http://www.vexen.co.uk/words.html#HIR
> > delete_* and save_*. This pattern is ubiquitous.
> [mike] 'this pattern is ...' -> 'this pattern of a small number of methods
> on a large amount of data is ...' (can't hurt to re-iterate the point of
> rest)
Okay.
> > know when they will get a request from a client.
> [mike] 'get' -> 'receive' (get might imply proactive processing or polling)
Okay.
> > Writing reliable-delivery software with HTTP is relatively easy. Thanks
> > to the guarantees of TCP, you can always know for sure if you received
> > an appropriate response. If you did not, then in many cases it is safe
> > to repeat the message send, due to the principle of idempotency.
> [mike] another sidebar with concrete examples and 'idempotency' would be
> good here...
I will provide a URI.
> > not an issue then you should certainly use the simpler approach.
> [mike] 'use' -> 'consider' (don't recommend an approach that is short term
> and non-interoperable)
If that's what you need....sometimes I use XML, but others Word.
Sometimes REST but other times RPC.
> > HTTP is also not appropriate in some circumstances. Because HTTP runs on
> > top of TCP, it can have high latency.
> [mike] 'high' is relative, give some concrete numbers so people don't make
> decisions based on the wrong assumptions
Okay, I'll try to be more explicit.
Paul Prescod
How the web be different if HTTP had been designed so that there was a way built-in for the client to become the server and vice versa... Paul Prescod
> How the web be different if HTTP had been designed so that there was a > way built-in for the client to become the server and vice versa... Hard to say. I don't know that firewall admins would have let a method like "TURN" be used, but had it been used for neat stuff, and the server-in-the-browser implementations didn't have any gaping security holes, it may have accelerated the move to the "Two Way Web". MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
So does anyone mind if I take this out: "The message MAY contain a header called "Requested-Expiration". It should be a time value that represents the time that the Subscriber Application would like the subscription to persist." and this: "Expiration: The response to the Subscription MUST include a header called "Subscription-Expiration". This indicates the time that the subscription expires. The subscriber application MAY renew the subscription before this time. If it does not, the publisher MAY stop sending notifications after that time. The publisher MAY also remove the Subscription URI." and this: Renewal: The subscriber MAY renew a Subscription by making another Subscription Request. I will leave this in: "Each notification response MUST include a "Continue-Subscription" header. The value associated with this header MUST be the string "true". If the header is not present, the publisher MUST remove the subscription." And subscriptions will be either one-shot or infinite, depending on how you look at it. ========== Should there be a way for the publisher to tell the subscriber when it (for whatever reason) will cease giving notifications? Sort of like the old unix sysadmin announcement: "Going offline NOW!" One way to handle this is to have the client register another URI, the "subscription-cancellation URI". Another is to have a special HTTP method. Another is to just not worry about it. Applications can handle that out of band. I think I like that last option... Paul Prescod
This all works for me. Paul Prescod wrote: > So does anyone mind if I take this out: > > "The message MAY contain a header called "Requested-Expiration". It > should be a time value that represents the time that the Subscriber > Application would like the subscription to persist." > > and this: > > "Expiration: The response to the Subscription MUST include a header > called "Subscription-Expiration". This indicates the time that the > subscription expires. The subscriber application MAY renew the > subscription before this time. If it does not, the publisher MAY stop > sending notifications after that time. The publisher MAY also remove the > Subscription URI." > > and this: > > Renewal: The subscriber MAY renew a Subscription by making another > Subscription Request. > > I will leave this in: > > "Each notification response MUST include a "Continue-Subscription" > header. The value associated with this header MUST be the string "true". > If the header is not present, the publisher MUST remove the > subscription." > > And subscriptions will be either one-shot or infinite, depending on how > you look at it. > > ========== > > Should there be a way for the publisher to tell the subscriber when it > (for whatever reason) will cease giving notifications? Sort of like the > old unix sysadmin announcement: "Going offline NOW!" > > One way to handle this is to have the client register another URI, the > "subscription-cancellation URI". Another is to have a special HTTP > method. Another is to just not worry about it. Applications can handle > that out of band. I think I like that last option... > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Lucas Gonze wrote:
>
> About the notification message definition:
> "A notification message must have the following headers:
> Watched-URI: (URI of the watched resource)
> Subscription-URI: URI of the subscription object"
>
> I believe that the Watched-URI and Subscription-URI are not properly a required
> part of the notification message. In the idempotent notification model the
> Subscriber URI contains the entire content of the callback. There are several
> reasons.
>
> 1) It is not properly a subscriber URI but a notification URI. This follows
> from the fact that the sink receives notifications via PUT. If you PUT multiple
> notifications to the same URI, and they contain data related to different
> subscriptions, they will wipe one another out.
Right now the spec says:
"The HTTP method used for the notification is up to the application."
As you've urged I'm trying not to over-constrain. Mark Baker feels like
it makes sense to use PUT and POST in some circumstances. I actually
prefer NOTIFY. I don't see the harm in allowing choice. The only thing
I'll go do right now is add:
" but the method must not be GET, HEAD or any other method that is
defined to be safe (side-effect-free)."
> 2) If the subscription URI in the notification is used as the callback address
> for renewing/deleting/pending the subscription, or if the Watched-URI is used as
> the callback address for picking up further events, then an attacker can rewrite
> these headers to contain the target URI of a distributed denial of service
> attack. To prevent rewriting, the notification message would have to be either
> signed or encrypted, and if the sink has to handle signed or encrypted messages,
> it can't be a plain vanilla HTTP server. So the sink MUST NOT use either the
> Watched-URI or Subscription-URI as the callback address for
> renewing/deleting/pending the subscription.
I see your problem. But also look at it from the opposite point of view.
Directing clients at an alternate server (i.e. mirror) is a useful form
of load balancing.
I'm not convinced that the DOS is a real problem. In order to generate
1000000 hits on the target machine ("take that capitalist bastards!")
you'd have to generate 1000000 notifications. Why wouldn't you just
directly make the 1000000 GET connections and be done with it? Maybe for
obfuscation but the point remains that the number of hits you generate
is in the same ballpark as the number of notifications you make so it is
really hard to make a serious hit.
> 3) If the Watched-URI and Subscription-URI in a notification message are used by
> the sink to identify the resource in question, an attacker can eavesdrop to
> discover any meaningful data within those URIs. For example the
> Subscription-URI may hold enough information to modify a subscription. If the
> Subscription-URI had been obtained within the context of an HTTPS connection,
> including it within an uncrypted notification message would disclose a secret.
Arguably you should use real authentication rather than just hoping that
URIs don't leak out.
>...
> I don't mean to block off whatever the utility of the notification headers is,
> though. Explanations of the intended use of those headers would help in finding
> an alternative way to meet the need...
There are three virtues. 1. a notification message gives you enough
information to know what is going on even if you didn't play games with
the subscription URI. 2. this is very useful for the email binding where
people usually don't like to invent hundreds of email addresses. 3. the
server can do a form of load-balancing so that they don't slashdot
themselves.
If we ignore the first two and say that only 3 is important then we
could remove the subscription URI and make the Watched-URI a MAY.
This could be used to solve 2:
http://developer.netscape.com/viewsource/husted_mailto/mailto.html
And I guess 1 is more of a theoretical problem. So I suggest the
following:
"
A notification message MAY have the following headers:
Watched-URI: (URI of the watched resource)
The Watched-URI may be any valid URI for the resource that generated the
notification. It need not be the original URI but it must refer to the
same resource. If the client wants to retrieve a representation of the
resource it SHOULD use this URI, not the original one. This will allow
publishers to do a simple form of load balancing.
"
Paul Prescod
> I'm not convinced that the DOS is a real problem. In order to generate
> 1000000 hits on the target machine ("take that capitalist bastards!")
> you'd have to generate 1000000 notifications. Why wouldn't you just
> directly make the 1000000 GET connections and be done with it? Maybe for
> obfuscation but the point remains that the number of hits you generate
> is in the same ballpark as the number of notifications you make so it is
> really hard to make a serious hit.
This is an elegant and useful bit of reasoning.
The only remaining bit of DDoS (after the above) is that the watcher can
be tricked into generating watches against DDoS targets, given that a
watch often entails a polling loop. Is this really a problem? You can
argue that a watcher actually reduces hits, given that it can act as an
aggregator for multiple clients' individual polling loops. ...
Hmmm. There's a general problem of watched resources not wanting to be
watched. Maybe they don't have the bandwidth to sustain polling loops,
maybe they're huge files. It seems to me that there's an existing
mechanism for handling this -- robots.txt. Interesting.
Lucas Gonze wrote: > >... > > Hmmm. There's a general problem of watched resources not wanting to be > watched. Maybe they don't have the bandwidth to sustain polling loops, > maybe they're huge files. Yes, you could have a situation where a third party notification purposely or accidentally causes a major load on some server. But I am disclined to deal with that in the spec: 1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there are some sites (e.g. dynamically generated using TeX) where even a FoRK posting could kill them. 2. Server can limit connections (admittedly suboptimal "solution") 3. Very hard to engineer maliciously on a large scale because where did you find all of those subscription URIs? You'd have to do a hell of a lot of sniffing and hope that the subscription URIs are static. etc. etc. 4. Not a real "security hole" in the sense that it doesn't expose data, causes no harm at all to the client and it won't seriously harm a well-written server either. > ... It seems to me that there's an existing > mechanism for handling this -- robots.txt. Interesting. robots.txt is similar but too different to be directly reused in my opinion. The one is about crawlers. The other is about subscribers. I don't think that they are the same... Paul Prescod
an interesting related nugget: eBay successfully argued in court that a spider used by a competitor to aggregate eBay's (among other auction sites') listings was causing damage by overloading their servers, despite the fact that eBay's listings were accessed via GET. Legal retardation aside, is there potential legal risk to a third party watcher? EG, the above aggregator could just as well have been a notification service of the kind we are discussing here. > > Hmmm. There's a general problem of watched resources not wanting to be > > watched. Maybe they don't have the bandwidth to sustain polling loops,o > > maybe they're huge files. > > Yes, you could have a situation where a third party notification > purposely or accidentally causes a major load on some server.
Lucas Gonze wrote: > > an interesting related nugget: > > eBay successfully argued in court that a spider used by a competitor to > aggregate eBay's (among other auction sites') listings was causing damage > by overloading their servers, despite the fact that eBay's listings were > accessed via GET. > > Legal retardation aside, is there potential legal risk to a third party > watcher? EG, the above aggregator could just as well have been a > notification service of the kind we are discussing here. Yes, a third party watcher could be considered a kind of robot that wastes resources. But I'm not inclined to worry about it until it becomes a problem. If legals had any say in the design of the Web it wouldn't exist. After all, people are constantly "wasting resources" downloading things they weren't authorized to download. If the Web was not so damn useful the legals would have shut it down years ago. Paul Prescod
M. Prescod said: > Yes, you could have a situation where a third party notification > purposely or accidentally causes a major load on some server. But I am > disclined to deal with that in the spec: I would leave the default as saying that all resources are watchable until they opt-out, the same as with crawlers. On the worldos.com site 99% of bandwidth was spiders downloading the complete tarball, which was a pain in the ass for my provider, who is a decent guy with not a lot of money. I was happy to be able to use robots.txt as a courtesy to him. Note that I'm not arguing about what you put in HttpEvents, which is none of my business. > robots.txt is similar but too different to be directly reused in my > opinion. The one is about crawlers. The other is about subscribers. I > don't think that they are the same... > > Paul Prescod Well, they're both bots that are too dumb to know the difference.
Lucas Gonze wrote: > >... > > I would leave the default as saying that all resources are watchable until > they opt-out, the same as with crawlers. On the worldos.com site 99% of > bandwidth was spiders downloading the complete tarball, which was a pain > in the ass for my provider, who is a decent guy with not a lot of money. > I was happy to be able to use robots.txt as a courtesy to him. Agreed. But robots are stupid. You point them at one web page and they traverse the whole damn web. On the other hand, every watched URI is watched because someone, somewhere explicitly asked to watch it. If someone set up a robot that FOUND URIs to watch then I would agree it should obey the robots.txt. > Note that I'm not arguing about what you put in HttpEvents, which is none > of my business. I want you to make it your business. If you see someting I don't, I want to hear about it. Paul Prescod
> > ... It seems to me that there's an existing > > mechanism for handling this -- robots.txt. Interesting. > > robots.txt is similar but too different to be directly reused in my > opinion. The one is about crawlers. The other is about subscribers. I > don't think that they are the same... > > Paul Prescod It strikes me that crawlers and watchers are closely related. A watcher does a push notification while a crawler does a pull. A primary usecase of notifications is for watched resources to get changes indexed faster, while at the same time reducing overhead for pollers.
Paul Prescod wrote: > 1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there > are some sites (e.g. dynamically generated using TeX) Good lord. Nobody's really doing that, are they? ;-) jb
Lucas Gonze wrote: > an interesting related nugget: > > eBay successfully argued in court that a spider used by a competitor to > aggregate eBay's (among other auction sites') listings was causing damage > by overloading their servers, despite the fact that eBay's listings were > accessed via GET. Likewise, part of the final shutdown of Clickfeed was due to a restatement of their terms-of-service followed by a fairly aggressive legal posture they took along the same lines. :-/ jb
Jeff Bone wrote: > > Paul Prescod wrote: > > > 1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there > > are some sites (e.g. dynamically generated using TeX) > > Good lord. Nobody's really doing that, are they? ;-) Maybe not yet. But I've heard some people use JavaScript on the server side and that's almost as bad! Paul Prescod
Idea I've been noodling.... ==== Abstract The basic model of a REST Web Service is that services are described as webs of documents. Typically the documents will be dynamically generated but that is not necessarily the case. Just as with services based on COM, CORBA or SOAP, it would be nice to have a declaration of a service's behaviour in advance so that reliable software can be constructed with less testing. Insofar as a service consists of documents, especially XML documents, XML schemas provide a partial description of the service. What they do not describe is the transitions from one document to another. That's what SWSBL does. It is intended to be the IDL/WSDL for HTTP web services. Just as with IDL it may one day make sense to "bind" SWSBL into a statically typed programming language to make the construction of type-incorrect client software more difficult. Model Think of a web service as a web of document types. The "find airline seat" document points to the "reserve seat" document through a URI. That document points to the "purchase seat" document through a URI and so forth. Each document has associated with it an XML Schema but also a behaviour description (or perhaps just a fragment of a behaviour description ). The "root" behaviour description for a service asserts that a particular URI references a service that conforms to a particular behaviour description. As you move from document to document following links, each link is strongly and statically typed by the Behaviour Description. A failure to conform is a runtime error, just as with non-validation against an XML Schema or WSDL service description. Sometimes the client wants to send information to the server. HTTP allows you to do this either by POSTing to a document or PUTting to a URI provided by the server. So beyond being strongly typed, each URI must have associated with it a set of possible methods and inputs. Think of this as a 4-tuple: * HTTP method * query parameters * HTTP headers * body content (often XML in some vocabulary) SWSBL will help the service provider to define these valid inputs in advance so that client software can be reliably constructed. Sometimes you have an option of PUT and/or POST and/or DELETE so we must have multiple possible input actions associated with each URI. The input to PUT is likely to be very different than the input to POST and DELETE or GET have no body inputs. SWSBL will allow that. Once the HTTP request has been made, a response comes back. In order to build robust, statically typed, services we want to know what valid range of responses are legal. So for each sort of input, a range of valid outputs may be described. These consist of HTTP response and body content (perhaps constrained to one or more XML vocabularies). If a statically typed programming language has data binding then one can imagine that each "type" of input maps to a particular method and the result of the method would be either an XML DOM or the statically typed result of the data binding. (e.e. IPurchaseOrder instead of IDOMDocument). To make this binding easier, input types should be named, similar to operations in WSDL. The fundamental difference between this model and WSDL's is that this is about interactions between web service components (every page is a component) whereas WSDL is about describing a single web service component (only one SWSBL page).
I really like the idea. Discovery is a missing piece with REST and HTTP - at least in the statically defined way you describe. I also like that the design /starts/ with lots of documents and lots of services, rather than just one as in wsdl. mike ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, February 14, 2002 2:24 PM Subject: [rest-discuss] Idea: Simple Web Service Behaviour Language > Idea I've been noodling.... > ==== > Abstract > > The basic model of a REST Web Service is that services are described as > webs of documents. Typically the documents will be dynamically generated > but that is not necessarily the case. Just as with services based on > COM, CORBA or SOAP, it would be nice to have a declaration of a > service's behaviour in advance so that reliable software can be > constructed with less testing. > > Insofar as a service consists of documents, especially XML documents, > XML schemas provide a partial description of the service. What they do > not describe is the transitions from one document to another. That's > what SWSBL does. It is intended to be the IDL/WSDL for HTTP web > services. Just as with IDL it may one day make sense to "bind" SWSBL > into a statically typed programming language to make the construction of > type-incorrect client software more difficult. > > Model > > Think of a web service as a web of document types. The "find airline > seat" document points to the "reserve seat" document through a URI. That > document points to the "purchase seat" document through a URI and so > forth. Each document has associated with it an XML Schema but also a > behaviour description (or perhaps just a fragment of a behaviour > description ). The "root" behaviour description for a service asserts > that a particular URI references a service that conforms to a particular > behaviour description. > As you move from document to document following links, each link is > strongly and statically typed by the Behaviour Description. A failure to > conform is a runtime error, just as with non-validation against an XML > Schema or WSDL service description. > > Sometimes the client wants to send information to the server. HTTP > allows you to do this either by POSTing to a document or PUTting to a > URI provided by the server. So beyond being strongly typed, each URI > must have associated with it a set of possible methods and inputs. Think > of this as a 4-tuple: > > * HTTP method > * query parameters > * HTTP headers > * body content (often XML in some vocabulary) > > SWSBL will help the service provider to define these valid inputs in > advance so that client software can be reliably constructed. > > Sometimes you have an option of PUT and/or POST and/or DELETE so we must > have multiple possible input actions associated with each URI. The input > to PUT is likely to be very different than the input to POST and DELETE > or GET have no body inputs. SWSBL will allow that. > > Once the HTTP request has been made, a response comes back. In order to > build robust, statically typed, services we want to know what valid > range of responses are legal. So for each sort of input, a range of > valid outputs may be described. These consist of HTTP response and body > content (perhaps constrained to one or more XML vocabularies). If a > statically typed programming language has data binding then one can > imagine that each "type" of input maps to a particular method and the > result of the method would be either an XML DOM or the statically typed > result of the data binding. (e.e. IPurchaseOrder instead of > IDOMDocument). To make this binding easier, input types should be named, > similar to operations in WSDL. > > The fundamental difference between this model and WSDL's is that this is > about interactions between web service components (every page is a > component) whereas WSDL is about describing a single web service > component (only one SWSBL page). > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Paul Prescod wrote: > Sometimes the client wants to send information to the server. HTTP > allows you to do this either by POSTing to a document or PUTting to a > URI provided by the server. So beyond being strongly typed, each URI > must have associated with it a set of possible methods and inputs. Think > of this as a 4-tuple: > > * HTTP method > * query parameters > * HTTP headers > * body content (often XML in some vocabulary) > Jesus, this is scary. I was thinking about this on the drive home today, in the sense of abstract models for the Web. I was coming from the direction of modeling requests and responses directly --- two kinds of tuples, one a request-type tuple and another a response-type tuple. The request tuple Q is < namespace, base-uri, query-uri, method, headers, body > It's important to capture namespace (aka the Host: header, elevated to first-class status due to its primary role in dispatching requests arriving at a given node) and the base-uri so that you can model the behavior of intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a different Host: than the actual server, also important for virtual hosts, etc. A response tuple S is then something like < response-code, headers, body > A resource is then viewed as a function R: Q --> time --> S, and a server (node) is viewed as a generic function N: Q --> R. (Sorry for the Haskell-like notation if it's confusing. X --> Y is a unary function that maps X into Y, X --> Y --> Z is a curry function that takes X into a function that takes Y into Z. Perhaps more intuitively, it's a 2-ary function that takes X and Y into Z.) The point of all of these contortions in my mental exercise was to arrive at a concise way to specify the semantics of the Web in a manner that would enable dataflow-like composition --- or any sort of compositional algebra of operations on --- various Web resources, transformations, and so on. The Web needs a shell language, and this could be the start of its theoretical underpinnings. Anyway, Paul, I think you're on an interesting track with this! jb
Jeff Bone wrote: > >... > > < namespace, base-uri, query-uri, method, headers, body > > > It's important to capture namespace (aka the Host: header, elevated to > first-class status due to its primary role in dispatching requests arriving > at a given node) and the base-uri so that you can model the behavior of > intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a > different Host: than the actual server, also important for virtual hosts, > etc. A response tuple S is then something like I don't understand base-uri and I'm not sure if I need it for my app. If you're saying that you need to separate out query parameters from the base URI then I agree. Query parameters are in the domain of the application whereas the base URI is opaque. So for my language you need to be able to fiddle query parameters, just as HTML forms do. Whereas the rest of the URI comes from the server and you just leave that alone. Paul Prescod
I have been lurking on the REST conversations since Mark Baker
started them on FoRK, and even before then on the distributed objects
mailing list.
I think you-all are changing minds all over the place, and you have
my sincere thanks and congratulations.
I have been trying to pick my time to try to join the conversation.
After a few false starts, maybe this SWSBL topic is a good opening
I really like Paul Prescod's recent articles. He's starting to try to
work with business concepts like Purchase Orders, which are part of
my domain.
However, I see this also happen a lot in other Web Service examples:
The business logic behind the examples is often not very realistic,
and so the solutions may not be realistic either.
I think I can provide some realistic business examples, and learn
something about how to model them as REST resources.
I'm not sure how deep you-call want to get into business processes,
but I have some time to discuss the issues in the next week or two
and so will put the question on the table now. Please forgive the
long message. It contains some info on where I'm coming from, some
comments on business processes, and a couple of RESTification
attempts.
I'm coming from heavy involvement with ebXML and its follow-on
activities in eBTWG:
http://www.ebxml.org
http://www.ebtwg.org
These groups are trying to define standards for B2B collaborations.
The background of many of the participants is traditional EDI, which
means peer-to-peer document transfer. They assume that the documents
just flow over the wire from one internal business system to another
and never surface as Web resources. Thus you will see ebXML projects
like the Registry act like private database systems when they would
have better as catalogs of Web resources. (Similar to UDDI.)
My goal in joining your discussion is to take some of the business
concepts from ebXML and RESTify them. I hope to influence ebXML and
related efforts to move in the REST direction.
I find it fairly natural to model business objects as suites of Web
resources. (Paul Prescod: refering to one of your recent opponents
on the xml-dev list, I think it is perfectly feasible to model almost
everything in any business application system (ERP, CRM, etc.) in Web
resources.)
I'm having some trouble getting the business *conversations*
RESTified correctly, though, and maybe you can help.
For example:
The business protocol for a Order is Offer-Acceptance.
A Purchase Order is an offer to buy.
To be binding, it must be explicitly accepted by the supplier.
The offer must have a time constraint - it is not good forever.
So a Purchase Order as a Web resource is also an element in a dialog
between Customer and Supplier.
The offer-acceptance protocol for a Purchase Order in RosettaNet and
ebXML includes stages of requesting and responding messages with
timeouts:
1. The Customer places the Purchase Order.
2. The Supplier sends a receiptAcknowledgment quickly signifying both
receipt and schema validation.
3. The Supplier sends an acceptance or rejection (for which they
would typically have more time). Acceptance means contract formation
or binding - a Purchase Order is a type of contract.
4. The Customer sends a receiptAck of the acceptance or rejection.
There are reasons for these signals. If the receiptAck times out,
the Customer may retry or go to another Supplier without wasting any
more time. If the acceptance times out, the offer failed. B2B
orders are usually not like consumer ones where the customer prepays
using a credit card. B2B orders are often postpaid, on credit. So
business state alignment is important: meaning both parties must
agree explicitly and deterministically on whether the order was
accepted (or not).
"Business state alignment" implies that a Purchase Order has a state
model: for example, pending, accepted, rejected, fulfilled, etc.
(That was not a complete list of states, by the way.)
Allowed actions will be constrained by PO state: for example, a PO
in the "fulfilled" state cannot be canceled; a "rejected" order
should not be fulfilled. In other words, orchestration of actions is
conditioned by resource state. (Not by message sequence.)
ebXML (among other initiatives) is attempting to express the
orchestration rules as XML documents. Which means the business
process can become a Web resource as well as the business objects. I
think this is very similar to what Paul is trying to do with SWSBL,
except that (1) it may be more complex than what you have in mind,
and (2) the ebXML guys for the most part do not have a Web resource
model in their collective mind.
Ok, one feeble attempt to model this all as hierarchies of REST
resources:
ProductCatalog
Product102
PurchaseOrders
PO203
OrderLines
Deliveries
Payments
TransactionLog
NegotiationTransactions
DeliveryTransactions
PaymentTransactions
ProblemResolutionTransactions
PurchasingProcess
ActivityModel
ProcessStages
NegotiationStage
DeliveryStage
PaymentStage
ProblemResolution
ObjectModels
PurchaseOrder
StateModel
Delivery
StateModel
Payment
StateModel
TransactionPatterns
Offer-Acceptance
Notify-Confirm
(Note: Notify-Confirm is the protocol for deliveries and payments.)
My current vague idea for RESTifying the conversations is for the
participants to Post or Put documents to the TransactionLog, which
will process them according to the state of the related business-
object-resource (following the rules of the Purchasing Process) and
possibly change the state of the resource accordingly, while adding
the document to the TransactionLog.
Timeouts and acks might be Notifications.
One really interesting issue is where do the Web resources live?
That is, who hosts them: Customer, Supplier or trusted 3rd party?
The realities of business say:
(a) both parties want their own copies in their own internal systems
and neither fully trusts the other to maintain an "official" version;
(b) trading partner relationships are usually unbalanced, that is,
one partner is dominant, and the dominant partner would most
naturally host the Web resources.
All three of the possible hosts can be found in practice:
3rd parties like CommerceOne and Ariba;
customer hosts like big companies who publish Web orders for their
smaller suppliers;
big suppliers who provide Web ordering facilities for their customers.
I have not seen the business processes as Web resources yet.
Here is another attempt to RESTify some business objects, assembled
by one of my business partners from anonymized real-world cake mix
contracts:
http://homepage.interaccess.com/~linkage/Contracts/CakeMix.htm
Don't look critically at the HTML - the author is a supply chain
manager, not a technical person. Just look at how easy he found it
to RESTify this stuff.
Correcting the hierachy so it indents properly, two dots per level: ProductCatalog ..Product102 PurchaseOrders ..PO203 ....OrderLines ....Deliveries ....Payments ....TransactionLog ......NegotiationTransactions ......DeliveryTransactions ......PaymentTransactions ......ProblemResolutionTransactions PurchasingProcess ..ActivityModel ....ProcessStages ......NegotiationStage ......DeliveryStage ......PaymentStage ......ProblemResolution ..ObjectModels ....PurchaseOrder ......StateModel ....Delivery ......StateModel ....Payment ......StateModel ..TransactionPatterns ....Offer-Acceptance ....Notify-Confirm (sorry about that)
> The background of many of the participants is traditional EDI, which > means peer-to-peer document transfer. They assume that the documents > just flow over the wire from one internal business system to another > and never surface as Web resources. Thus you will see ebXML projects > like the Registry act like private database systems when they would > [work] better as catalogs of Web resources. (Similar to UDDI.) The referent of "similar" in that statement was unclear: I meant that UDDI shares the unfortunate tendency of ebXML to divorce themselves from "the Web" and try to carve out a separate space operating by other rules.
RFC 2616 is unclear about whether and how to mix application and transport
status codes. For example, status code 205 goes all the way up to the UI
level:
205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset
the document view which caused the request to be sent. This response
is primarily intended to allow input for actions to take place via
user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The
response MUST NOT include an entity.
It's important to be able to distinguish transport errors from application
errors, since a request might be be legal HTTP but have illegal parameter
values as far as the resource is concerned. And it's very useful to use
the response headers to communicate application status, because otherwise
the application needs to define a new format within the message body, and
the message body may be reserved for other information.
SOAP et al already have definitions for application status codes and SOAP
et al are really useful for application-level envelopes, if not for
node-level semantics, but Joe Schmoes's app shouldn't have to depend on
them just to communicate application status codes. So I'm going to
propose a strawman for application status codes in the response headers.
I don't mean to create a "standard" for interop. I do mean to solicit
comments and discussion of how appropriate it is use response headers for
application-level info, and of how good the proposed scheme is.
Proposal for application status codes: An application can return status
codes in response headers titled "Application-Response-Code." There can
be 0 or more such response headers. The value of a
Application-Response-Code field may contain three elements, a numeric
field code, a textual explanation, and a text value to say the object of
the error. The fields are comma delimited. Commas are illegal values in
the numeric field code or the textual explanation. The commas are
required -- a well-formed Application-Response-Code will always have at
least two. The meaning of Application-Response-Code is orthogonal to the
meaning of the HTTP status code; there is no requirement that the HTTP
status code be 200 OK, for example.
Thoughts?
- Lucas
Paul Prescod wrote: > Jeff Bone wrote: > > > >... > > > > < namespace, base-uri, query-uri, method, headers, body > > > > > It's important to capture namespace (aka the Host: header, elevated to > > first-class status due to its primary role in dispatching requests arriving > > at a given node) and the base-uri so that you can model the behavior of > > intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a > > different Host: than the actual server, also important for virtual hosts, > > etc. A response tuple S is then something like > > I don't understand base-uri and I'm not sure if I need it for my app. > > If you're saying that you need to separate out query parameters from the > base URI then I agree. Right, right. The difference between what I was describing and what you're talking about --- the reason my model includes the base-uri --- is that we're doing different things. I'm looking at ways to precisely describe the semantics of Web interaction in general, therefore I've got to capture notions like "server," "host namespace" (for diambiguating virtual hosts, describing proxy behavior, etc.) and so forth. Not clear that you need those, though perhaps they don't hurt. jb
bhaugen32 wrote: > >... > > I'm having some trouble getting the business *conversations* > RESTified correctly, though, and maybe you can help. I think we can be mutually helpful here! I may have to be short today, though. Other stuff to do. > For example: > The business protocol for a Order is Offer-Acceptance. > A Purchase Order is an offer to buy. > To be binding, it must be explicitly accepted by the supplier. > The offer must have a time constraint - it is not good forever. > > So a Purchase Order as a Web resource is also an element in a dialog > between Customer and Supplier. > > The offer-acceptance protocol for a Purchase Order in RosettaNet and > ebXML includes stages of requesting and responding messages with > timeouts: > 1. The Customer places the Purchase Order. POST. > 2. The Supplier sends a receiptAcknowledgment quickly signifying both > receipt and schema validation. Response to POST. Generates a new URI representing the eventual target of its acceptance or rejection. Customer uses HTTPEvents to WATCH the new URI (call it /acceptance). > 3. The Supplier sends an acceptance or rejection (for which they > would typically have more time). Acceptance means contract formation > or binding - a Purchase Order is a type of contract. A notification comes through that the client should check /acceptance because something has changed at the URI. The customer sees that /acceptance says <accept/> (with a date, digital signature, contract, list of things supplied, etc.) > 4. The Customer sends a receiptAck of the acceptance or rejection. Customer POSTs their ack with a digital signature and a URI pointing back to /acceptance. > There are reasons for these signals. If the receiptAck times out, > the Customer may retry or go to another Supplier without wasting any > more time. If the acceptance times out, the offer failed. B2B > orders are usually not like consumer ones where the customer prepays > using a credit card. B2B orders are often postpaid, on credit. So > business state alignment is important: meaning both parties must > agree explicitly and deterministically on whether the order was > accepted (or not). That's where the digital signatures and URIs help. > "Business state alignment" implies that a Purchase Order has a state > model: for example, pending, accepted, rejected, fulfilled, etc. > (That was not a complete list of states, by the way.) You might think of those as different kinds of resources, pending_po, accepted_po, rejected_po, fulfilled_po. Because they all have URIs, you can say: "LOOK, I rejected that PO. Here's the URI." Of course one cannot necessarily trust one's business partner so you need to have a mirror on your side also. > Allowed actions will be constrained by PO state: for example, a PO > in the "fulfilled" state cannot be canceled; a "rejected" order > should not be fulfilled. In other words, orchestration of actions is > conditioned by resource state. (Not by message sequence.) Another good reason to have separate resources. A fullfilled_PO will simply reject the cancellation POST. > ebXML (among other initiatives) is attempting to express the > orchestration rules as XML documents. Which means the business > process can become a Web resource as well as the business objects. I > think this is very similar to what Paul is trying to do with SWSBL, > except that (1) it may be more complex than what you have in mind, > and (2) the ebXML guys for the most part do not have a Web resource > model in their collective mind. Agreed. I'll have to look at the rest of your stuff later. I think it is important to show real business examples. I admit that I think in terms of technology and not business. I just know from what I hear from business people that the technological problems are similar to more standard protocol problems. Maybe we could work together sometime on an article about the intersection of ebXML and REST. I think that the ebXML crowd should be fertile ground for REST thought. Many of them are old SGML heads who would understand the benefits of linking. Others probably have a sense that the web services world is going in the wrong direction and would like to see something going in the right one. Paul Prescod
I just found out about this forum and this discussion, in particular.
--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> Python's urlparse is broken; it assumes that you can only
> parameterise the last path segment, not every path segment. As a
> result,
> http://www.example.com/foo;bar/baz?bat
> gets parsed as
> ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')
I'd like to note that Python 2.2 provides an additional call,
urlparse.urlsplit(), that avoids the assumption that only the last
path segment can be parameterized; the bug in urlparse.urlparse() is
also fixed in that version:
>>> import urlparse
>>> urlparse.urlsplit('http://www.example.com/foo;bar/baz?bat')
('http', 'www.example.com', '/foo;bar/baz', 'bat', '')
>>> urlparse.urlparse('http://www.example.com/foo;bar/baz?bat')
('http', 'www.example.com', '/foo;bar/baz', '', 'bat', '')
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
Fantastic! This is great news, and I'll be upgrading to 2.2
immediately.
Cheers & thanks,
On Fri, Feb 15, 2002 at 02:26:41PM -0500, Fred L. Drake, Jr. wrote:
>
> I just found out about this forum and this discussion, in particular.
>
> --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> > Python's urlparse is broken; it assumes that you can only
> > parameterise the last path segment, not every path segment. As a
> > result,
> > http://www.example.com/foo;bar/baz?bat
> > gets parsed as
> > ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')
>
> I'd like to note that Python 2.2 provides an additional call,
> urlparse.urlsplit(), that avoids the assumption that only the last
> path segment can be parameterized; the bug in urlparse.urlparse() is
> also fixed in that version:
>
> >>> import urlparse
> >>> urlparse.urlsplit('http://www.example.com/foo;bar/baz?bat')
> ('http', 'www.example.com', '/foo;bar/baz', 'bat', '')
> >>> urlparse.urlparse('http://www.example.com/foo;bar/baz?bat')
> ('http', 'www.example.com', '/foo;bar/baz', '', 'bat', '')
>
>
> -Fred
>
> --
> Fred L. Drake, Jr. <fdrake at acm.org>
> PythonLabs at Zope Corporation
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
Mark Nottingham
http://www.mnot.net/
Paul Prescod <paul@p...> wrote: > > "Business state alignment" implies that a Purchase Order has a state > > model: for example, pending, accepted, rejected, fulfilled, etc. > > (That was not a complete list of states, by the way.) > > You might think of those as different kinds of resources, pending_po, > accepted_po, rejected_po, fulfilled_po. Because they all have URIs, you > can say: "LOOK, I rejected that PO. Here's the URI." Of course one > cannot necessarily trust one's business partner so you need to have a > mirror on your side also. > > > Allowed actions will be constrained by PO state: for example, a PO > > in the "fulfilled" state cannot be canceled; a "rejected" order > > should not be fulfilled. In other words, orchestration of actions is > > conditioned by resource state. (Not by message sequence.) > > Another good reason to have separate resources. A fullfilled_PO will > simply reject the cancellation POST. I'm trying to keep an open mind, but having trouble accepting the idea of separate resources for a PO depending on its state. But maybe I don't understand your proposal. Questions: 1. Do you mean that the PO changes its identity depending on its state? (POs should not change their identity.) 2. Do mean that the history of PO-states-as-resources is persistent? That accepted_po and fulfilled_po co-exist? In which case, what is to prevent one from canceling the accepted_po and ignoring the fulfilled_po? (A PO should be in one and only one state at a time.) From another angle: 3. Is there something un-RESTful in your view about a PO resource that knows its own state and can respond to transactions accordingly? I mean, is there some essential REST difference between "PO in fulfilled state" that rejects cancellations and "fulfilled_po" that that rejects cancellations? Thanks, Bob Haugen
Reading this bit of rfc 2616... 10.2.2 201 Created The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead. It's not clear to me what this stuff means: The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. What are the resource characteristics? Is that the mime type of the resource created? Does this mean that the mime type of the resource created goes in the Content-Type response header? Thanks in advance.
Reading this bit of rfc 2616... 9.5 POST If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30). ...I don't understand what it means for the response entity to describe the status of the request, aside from setting the response status code, which is already known to be 201. Any of you high priests care to help clue me in?
Lucas Gonze wrote: > >... > > It's not clear to me what this stuff means: > The response > SHOULD include an entity containing a list of resource > characteristics and location(s) from which the user or user agent can > choose the one most appropriate. The entity format is specified by > the media type given in the Content-Type header field. > > What are the resource characteristics? Is that the mime type of the > resource created? Does this mean that the mime type of the resource > created goes in the Content-Type response header? Here's how I interpret it: when you create an entity you need to return a reference to the entity not just in the header but also in the body (e.g. an HTML page that says "click here to see your post" or an XML page that has a URI attribute). In order for the client to select among the potentially numerous URIs for the object, you should describe the reason that there are multiple URIs and the advantages of each. Paul Prescod
Good call -- your interpretation strikes me as correct. So, in the case where there is no need for a user decision (e.g. with a single response), there would be no need for metadata about resource characteristics. On Sun, 17 Feb 2002, Paul Prescod wrote: > Lucas Gonze wrote: > > > >... > > > > It's not clear to me what this stuff means: > > The response > > SHOULD include an entity containing a list of resource > > characteristics and location(s) from which the user or user agent can > > choose the one most appropriate. The entity format is specified by > > the media type given in the Content-Type header field. > > > > What are the resource characteristics? Is that the mime type of the > > resource created? Does this mean that the mime type of the resource > > created goes in the Content-Type response header? > > Here's how I interpret it: when you create an entity you need to return > a reference to the entity not just in the header but also in the body > (e.g. an HTML page that says "click here to see your post" or an XML > page that has a URI attribute). In order for the client to select among > the potentially numerous URIs for the object, you should describe the > reason that there are multiple URIs and the advantages of each. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > >
Lucas Gonze wrote: > > Good call -- your interpretation strikes me as correct. > > So, in the case where there is no need for a user decision (e.g. with a > single response), there would be no need for metadata about resource > characteristics. Agreed. Paul Prescod
Lucas Gonze wrote: > > Reading this bit of rfc 2616... > > 9.5 POST > > If a resource has been created on the origin server, the response > SHOULD be 201 (Created) and contain an entity which describes the > status of the request and refers to the new resource, and a Location > header (see section 14.30). > > ...I don't understand what it means for the response entity to describe > the status of the request, aside from setting the response status code, > which is already known to be 201. I think this is similar to the other issue. There should be HTML or XML or ... of the form "I created this thing for you. Here it is." Paul Prescod
I have written up the conversations on one-shot notifications in a detailed way and posted it on the web at http://www.gonze.com/http-notifications.html and http://www.gonze.com/http-notifications.txt
Lucas Gonze wrote:
>
> I have written up the conversations on one-shot notifications in a
> detailed way and posted it on the web at
> http://www.gonze.com/http-notifications.html and
> http://www.gonze.com/http-notifications.txt
It looks great but a few details:
1. I don't see how the client knows WHERE to POST to the server. It may
have a priori knowledge but it may not. HTTPEvents allows the server to
tell the client where to POST through a header that is available on a
GET or HEAD. It also allows the server to generate a URI that obviates
the need for the Watched-Resource-URI. This should be step "0". My
mental model was that you could surf the web and the browser would tell
you (discreetly) when a watchable resource popped up. Same for Google.
It could spider around subscribing to things. If a particular
application wants to skip this step, it may, if it already has an
appropriate URI.
2. I think you overspecify the structure of the notification.
* arguably methods should be application dependent...
* I strongly feel that the input parameters should be application
dependent!
* It should be possible for the response to trigger a
re-subscription through a magic header
* "URI MUST change for each Step 1" - depends on the security level
of the app. Should not be overspecified.
> Attackers are prevented from altering the meaning of a Step 4 (Notification)
> by the following means: the only data transmitted in the Step 4
> (Notification) is the fact that a pre-arranged callback URI has been
> activated. The meaning of that URI is left entirely up to the sink, which
> generates it, and to any information exchanged during a Step 1
> (Subscription).
I think this is overspecified. The client and server might prefer to use
a signature.
> Attackers are prevented from tricking a sink into believing that a Step 4
> (Notification) has happened by the following means: the callback URI itself
> is a secret until the source invokes it in the Step 4 (Notification), the
> callback URI MUST be hard to guess (for example, by being a 50 character
> random string), and the callback URI is never used more than once.
There is hardly any harm in being "tricked" into re-fetching the
resource too soon. This just complicates the implementation of the
client side of the protocol for little benefit.
3. I haven't thought through all of the race condition issues and I'm
glad you have. But consider whether there are If-modified-since or
e-tags tricks you can use to avoid the contortions of inventing new URIs
and forcing a certain order of steps. I don't have time to think about
it right now but something seems inelegant about the level of effort you
need to go to to avoid race conditions.
Anyhow, the GET step should be optional because you may not care about
the current state of the resource. You only want to know if it changes.
For instance there may be a gateway that emails the user when the
resource changes. The gateway doesn't want to fetch the resource every
time. The user will fetch it when the user wants it.
You seem not to have dealt with something on my todo list for
HTTPEvents, container sub-resource changes.
Paul Prescod
Hey Paul, > 1. I don't see how the client knows WHERE to POST to the server. It may > have a priori knowledge but it may not. HTTPEvents allows the server to > tell the client where to POST through a header that is available on a > GET or HEAD. Yup -- this strikes me as useful, so there's an analog down in "Enabling Bot Inclusion", along with another possible alternative. > It also allows the server to generate a URI that obviates > the need for the Watched-Resource-URI. This should be step "0". My > mental model was that you could surf the web and the browser would tell > you (discreetly) when a watchable resource popped up. Same for Google. > It could spider around subscribing to things. If a particular > application wants to skip this step, it may, if it already has an > appropriate URI. If I understand this right, are you thinking the watched resource and the watcher are the same thing? > 2. I think you overspecify the structure of the notification. Well, I was trying to do an experiment more than to write a standard. I wanted to know exactly what a callback design would have to do, what the hard problems would be, where the low-hanging fruit would be, etc. So the high level of detail is about getting a really clear picture of the problem set. To the degree that I _was_ trying to write a recipe for implementors, it's not so much a standard as a debugged algorithm. For example, anything that's a MUST is there because otherwise a critical feature won't work. It happens that the language of standards is great for writing meta-programs, that's the only reason I used it. > * arguably methods should be application dependent... > * I strongly feel that the input parameters should be application > dependent! ...again, I defer to my experiment+recipe intent, vs. an intent to standardize. > * It should be possible for the response to trigger a > re-subscription through a magic header I definately agree and spent a while working on that, but found that it led me into turf where there's a persistent subscription to manage, and didn't want to open up that can of worms. In the short term it turned out that having the source delete the sub once expiration is over or a notification has been sent was a big advantage. so, basically, figuring out how to do the re-sub automatically would be a big win but I was hard pressed enough to do the minimum reasonably well that had to put off the whole issue of persistence. > There is hardly any harm in being "tricked" into re-fetching the > resource too soon. This just complicates the implementation of the > client side of the protocol for little benefit. I will mull over this for a little while. > 3. I haven't thought through all of the race condition issues and I'm > glad you have. But consider whether there are If-modified-since or > e-tags tricks you can use to avoid the contortions of inventing new URIs > and forcing a certain order of steps. I don't have time to think about > it right now but something seems inelegant about the level of effort you > need to go to to avoid race conditions. > > Anyhow, the GET step should be optional because you may not care about > the current state of the resource. You only want to know if it changes. > For instance there may be a gateway that emails the user when the > resource changes. The gateway doesn't want to fetch the resource every > time. The user will fetch it when the user wants it. Optionalness: good point. Will do. If-modified-since etc is also a good thing, and I will dig around to bring this within the algorithm. > You seem not to have dealt with something on my todo list for > HTTPEvents, container sub-resource changes. More? (Sorry to post that big chunk of text and run, but I have a new consulting gig starting today and so will be out of touch til late evening.) - Lucas
> >I think it is important to show real business examples. I admit that I >think in terms of technology and not business. I just know from what I >hear from business people that the technological problems are similar to >more standard protocol problems. I also really like the grounding in real business examples - especially a 'complex' message exchange like a purchase order and acknowledgment. My current job is heavily into that at the moment as well. A tricky line to draw is whether when using HTTP, the HTTP request/respones messages are exactly equivalent to business documents (a purchase-order in a POST, and a purchase-order-ack in the response) or whether HTTP messages are delivery vehicles and the business documents span http messages (a response to a POST is only a 'delivery acknowledgement' and the purchase-order-ack is delivered to the sender somehow else (notification, new request, etc.) I'm using the approach of transferring business documents between queues using http messages carrying soap formatted data, the http and soap responses only talk about successfull delivery - the content of the messages describe the 'success/failure' of the business transaction. mike _________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.com
"Mike Dierken" <mdierken@h...> wrote: > I also really like the grounding in real business examples - especially a > 'complex' message exchange like a purchase order and acknowledgment. My > current job is heavily into that at the moment as well. > A tricky line to draw is whether when using HTTP, the HTTP request/respones > messages are exactly equivalent to business documents (a purchase- order in a > POST, and a purchase-order-ack in the response) or whether HTTP messages are > delivery vehicles and the business documents span http messages (a response > to a POST is only a 'delivery acknowledgement' and the purchase- order-ack is > delivered to the sender somehow else (notification, new request, etc.) Depends on the context and conditions of business relationship. 1. "I am the big dog and you will accept my order regardless." Purchase-order-acceptance could be the HTTP response. 2. Supplier needs some time to decide whether to accept order or not. HTTP response is receipt-ack only, Purchase-order-acceptance is delivered separately and later. Requester must associate later response with original request to close transaction. 3. Negotiated order: supplier may be allowed to propose changes to order - later delivery, split deliveries, substitute product, etc. Response to original order could be rejection-with-counter-offer- pending; Counter-offer starts a new transaction. > I'm using the approach of transferring business documents between queues > using http messages carrying soap formatted data, the http and soap > responses only talk about successfull delivery - the content of the messages > describe the 'success/failure' of the business transaction. A. How do you handle timeouts? B. How do you handle order fulfillment? C. Are these B2B? D. If B2B, what kind of items? Supplies? Products for resale? Components for manufacture? Business services? Other? Thanks, Bob Haugen
Lucas Gonze wrote: > >... > > If I understand this right, are you thinking the watched resource and the > watcher are the same thing? No. The watched resource can POINT to a watcher that knows how to watch it. That doesn't mean that you can't watch it if it does NOT point to such a watcher. But if you use a third-party watcher then of course you may lose notification granularity. > > 2. I think you overspecify the structure of the notification. > > ... > > To the degree that I _was_ trying to write a recipe for implementors, it's > not so much a standard as a debugged algorithm. For example, anything > that's a MUST is there because otherwise a critical feature won't work. > It happens that the language of standards is great for writing > meta-programs, that's the only reason I used it. Isn't interoperability between independently authored clients and servers a goal? If so, it is defacto a standard, if not a defacto standard. ;) > > * arguably methods should be application dependent... > > * I strongly feel that the input parameters should be application > > dependent! > > ...again, I defer to my experiment+recipe intent, vs. an intent to > standardize. Even so, your "recipe" could say: "you could do X with these security implications" as opposed to "you must do X because that's the most secure way." >... > I definately agree and spent a while working on that, but found that it > led me into turf where there's a persistent subscription to manage, and > didn't want to open up that can of worms. Not clear on why a re-sub is the same as a persistent subscription to manage....but if you leave the notification response body structure undefined then maybe we can figure it out through experimentation. >... > so, basically, figuring out how to do the re-sub automatically would be a > big win but I was hard pressed enough to do the minimum reasonably well > that had to put off the whole issue of persistence. Fair enough. Time is finite. >... > > You seem not to have dealt with something on my todo list for > > HTTPEvents, container sub-resource changes. > > More? If I have a resource "/foo" and somebody does a POST to it to create "/foo/bar" (yes, URIs are opaque but you know what I mean...a subresource is created). Does that trigger a notification for "foo"? It would be confusing to go look at "/foo" and see that it is exactly as you left it. (because POSTing doesn't necessarily change the resource). At one point I thought that it was important to have a feature to handle this but thinking about it now I think the way to handle it is to have "/foo" be a resource with a representation that points to all of its sub-resources. Then it is intuitive that a change to a sub-resource triggers a notification and it is relatively easy to figure out what sub-resource appeared or disappeared by "diffing" your cached copy against the sub-resources. But you could only figure out if a sub-resource was mutated if the entity body had something like hashes or last-modified-times for each sub-resource in it. So I'm inclined to encourage you not to worry about it... Paul Prescod
Thought this exchange where I came to some agreement with Dave Winder might be interesting. http://aspn.activestate.com/ASPN/Mail/Browse/Plain/xml-dev?period=200202 Dave Winer says: > Paul those are good compelling points, had they been raised before we built > an infrastructure for XML-RPC and SOAP at the script level. > > Earlier this month we finally implemented the top of the stack, something > called SCNS or Simple Cross-Network Scripting, which makes calling a web > service as simple as calling a procedure (yes it looks a little different, > and that's good, imho, people should know when they're making a networked > call. Paul Prescod says: > REST is admittedly not about cross-network scripting. REST is about > building web services. Here's what I see as the difference: with > cross-network scripting you are trying to hide many of the differences > between making a local call and making a remote call. That's great for > ease of use but it sacrifies a bunch of stuff in terms of > addressability, scalability, peformance and potentially security. I am > totally in favour of this trade-off where it makes sense. I advocate > XML-RPC as a viable alternative to REST with the caveat that I am > nervous about its reliance on "ASCII" and a few other things like that. > > REST is about taking the networking issues most seriously. This means > that the interface to networked code is different than to local code. > Not harder, but different. Both client and server have to think > differently when they access networked code. You could paper over the > differences on the client side with an OO library but this might > introduce performance or reliability problems. > > In my mind, web services are about doing the sorts of things we couldn't > do with COM or CORBA (otherwise why invent a new buzzword) so I don't > see XML-RPC (or SOAP RPC) as a Web Services technology. I am happy to > promote XML-RPC as a cross-network scripting tool, however, and I have. Dave Winer says: > BTW, thanks for the positive energy -- I feel much better about this stuff > now that it isn't all or nothing, as some people have cast it in the past. > > I will look for an opportunity to define an interface, in public, both ways. Paul Prescod
> > A. How do you handle timeouts? The sender has a queue & stale messages will kick back a notification into an 'outer workflow' manager. > B. How do you handle order fulfillment? It's out of band for our app - we just delivery the docs. If a business document is defined for 'shipping notice' or 'delivery status' or whatnot, we'll deliver those. > C. Are these B2B? Yes - bigco to smallbiz (hub & spoke today, Tomorrow The World (tm)) > D. If B2B, what kind of items? Supplies? > Products for resale? Components for manufacture? > Business services? Other? Don't know... currently mainly accounting types of docs for any industry, product or service.
"S. Mike Dierken" <mdierken@h...> wrote: > > B. How do you handle order fulfillment? > It's out of band for our app - we just delivery the docs. If a business > document is defined for 'shipping notice' or 'delivery status' or whatnot, > we'll deliver those. Got any ideas on how you might RESTify this app? Possibly relevant excerpt from REST Wiki FAQ: <quote> A good test of REST-fulness (though not complete by any means, since HTML forms fail) is, can I do a GET on the URLs that I POST to, and if so, do I get something that in some way represents the state of what I've been building up with the POSTs? For ebXML, the answer is "no". ebXML assumes that the POSTed documents disappear into each trading partner's internal business systems. However, the business process would actually work better if it was treated like a Web resource, for example an order resource, where all of the subsequent POSTs such as shipments, payments, etc. became sub-resources. Amazon puts your order on a Web page where you can track its status. B2B ecommerce is sometimes not so nice. </quote>
I had a much better idea of how to do static service declarations (as per IDL or WSDL) for REST web services: http://www.prescod.net/wrdl.html It reflects the underlying Web Architecture much more clearly than my old proposal did. It is consequently simpler. It has first-class concepts of "resource", "representation", "method", "input" and "output". Methods are HTTP methods like PUT, GET, DELETE, YOURMETHOD. Inputs are like HTTP method inputs: headers, query params and body (the URI is implied by the resource!). Outputs are like HTTP outputs: status code, headers and body. Resources know what representations they support and you can navigate from resource to resource through hyperlinks without worrying about the XML or HTML syntax of the representation (unless you want to). Following a hyperlink is a type-safe operation. That's about all the concepts in it. A rough proposal for an API (Java-ish syntax to prove it isn't biased towards dynamic languages) is provided. Everything is statically type checked just as with IDL or WSDL. Of course in Python everything would be done at runtime and thus save a build step. When I implement it I think it will be a really cool tool. Until then, I think it is a useful pedagogic tool for those working on REST Zen. If *you* want to implement it before I get around to it, in whatever language, please do. I'll work with you to clear up any fuzzy parts of the spec. Paul Prescod
> > Got any ideas on how you might RESTify this app? Yes - i've segregated the main 'methods' into.... post, reply, notify and get (there will probably be a put also) - so a small number of methods on a large number of resources. The reply happens after an initial response of 'accepted' (unless there is an immediate failure) and the notify is a (currently optional) status update about that business document (like if a manual approval process was successful). With a high fidelity access to a business system these notifications would be common. But they are purely optional for 'value added' capabilities. The 'notify' identifies the 'resource' that it is 'about'. mike
Interesting! I've been thinking about APIs and frameworks that encourage the use of REST ever since my experiment with RESTifying a Web/LDAP gateway (which resulted in Wallal [1]). I see some similarities between the back-of-a-napkin sketches I've done and what you propose here, but I was thinking more in terms of just mapping resources <-> objects. [1] http://www.mnot.net/wallal/ On Tue, Feb 19, 2002 at 04:57:00PM -0800, Paul Prescod wrote: > I had a much better idea of how to do static service declarations (as > per IDL or WSDL) for REST web services: > > http://www.prescod.net/wrdl.html > > It reflects the underlying Web Architecture much more clearly than my > old proposal did. It is consequently simpler. > > It has first-class concepts of "resource", "representation", "method", > "input" and "output". Methods are HTTP methods like PUT, GET, DELETE, > YOURMETHOD. Inputs are like HTTP method inputs: headers, query params > and body (the URI is implied by the resource!). Outputs are like HTTP > outputs: status code, headers and body. Resources know what > representations they support and you can navigate from resource to > resource through hyperlinks without worrying about the XML or HTML > syntax of the representation (unless you want to). Following a hyperlink > is a type-safe operation. > > That's about all the concepts in it. > > A rough proposal for an API (Java-ish syntax to prove it isn't biased > towards dynamic languages) is provided. Everything is statically type > checked just as with IDL or WSDL. Of course in Python everything would > be done at runtime and thus save a build step. > > When I implement it I think it will be a really cool tool. Until then, I > think it is a useful pedagogic tool for those working on REST Zen. If > *you* want to implement it before I get around to it, in whatever > language, please do. I'll work with you to clear up any fuzzy parts of > the spec. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Nottingham http://www.mnot.net/
I really like the idea of this - especially hashing things out via code... ----- Original Message ----- From: Paul Prescod <paul@...> To: <rest-discuss@yahoogroups.com>; <xml-dev@...>; xml-sig <xml-sig@...> Sent: Tuesday, February 19, 2002 4:57 PM Subject: [rest-discuss] REST made more concrete still > I had a much better idea of how to do static service declarations (as > per IDL or WSDL) for REST web services: > > http://www.prescod.net/wrdl.html > > It reflects the underlying Web Architecture much more clearly than my > old proposal did. It is consequently simpler. > > It has first-class concepts of "resource", "representation", "method", > "input" and "output". Methods are HTTP methods like PUT, GET, DELETE, > YOURMETHOD. Inputs are like HTTP method inputs: headers, query params > and body (the URI is implied by the resource!). Outputs are like HTTP > outputs: status code, headers and body. Resources know what > representations they support and you can navigate from resource to > resource through hyperlinks without worrying about the XML or HTML > syntax of the representation (unless you want to). Following a hyperlink > is a type-safe operation. > > That's about all the concepts in it. > > A rough proposal for an API (Java-ish syntax to prove it isn't biased > towards dynamic languages) is provided. Everything is statically type > checked just as with IDL or WSDL. Of course in Python everything would > be done at runtime and thus save a build step. > > When I implement it I think it will be a really cool tool. Until then, I > think it is a useful pedagogic tool for those working on REST Zen. If > *you* want to implement it before I get around to it, in whatever > language, please do. I'll work with you to clear up any fuzzy parts of > the spec. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
akuchlin@... wrote:
>
> On Tue, Feb 19, 2002 at 04:57:00PM -0800, Paul Prescod wrote:
> >http://www.prescod.net/wrdl.html
>
> Hmmm... I'm trying to wrap my head around this.
It's very rough right now. Release early and often. It's changed its
name three times this week. ;) More a direction to get people thinking
then something clearly implementable.
> * In the example, purchaseOrder has the query string declared as type
> integer. In the invocation example, at no point is this integer parameter
> supplied.
Yeah, I didn't align the examples. That's confusing. For now I'll
mention that fact and then later I'll go through and do that.
> * I don't understand the match attribute of 'representation'; does it mean
> that "if the XPath expression returns a non-empty set of nodes, the
> document is considered to match this representation type. The set
> of matching nodes is then discarded, having served its purpose."
Now that you mention it, the equivalent in XSLT is not exactly match but
"test"
http://www.w3schools.com/xsl/xsl_if.asp
I'll add a pointer to that for those who don't know XSLT.
> * I also don't understand the sentence about " This is not a problem
> because representations are only checked in a boolean fashion..."
> This doesn't clarify what happens if a document matches multiple
> representation types; is it considered to be all of those matching types,
> or just one of them?
At the time I wrote that it really didn't matter. It's like a type check
of whether a thing is an integer or a float. As long as it matches you
don't really care. Once the API is flushed out we might start caring
because coding is easier if you can ask "what's this I've got" instead
of looking at the elements and attributes. But then maybe that should be
left to an orthogonal (but integrated) XML data binding layer.
> * How do you know when a new resource has been created in response to
> some request? Is that indicated in the returned document in some way
> dependent on its schema? (Say, if it has a <new-resource> element in it.)
> Or is it an HTTP header or something like that?
Have to think a little bit more about that to check whether I've got it
right...
The only methods that really create new resources are PUT and POST. PUT
always creates a new resouce unless it fails. POST returns a Location:
header. I've been back and forth over and over again on whether this
needs to be declared in advance and what it means for the API.
View 1:
The Location: header is probably irrelevant...the representation
returned by POST should point to the new thing that's created. Do you
care whether it really, really created something new or if it happened
to point to something it already had?
View 2:
HTTP privileges a particular URI in the entity as the "location" URI. I
think that logically everything else in the entity is just wrapping
around that main URI. So "creation" is important and should have
first-class support.
This minute View 2 is stronger in my mind.
> * In the 'po' representation type, what are the approve and cancel
> references intended to be, semantically? Are they resources that you could
> POST to in ordr to approve or cancel the order, or something else?
Yes, they are sort of trigger resources. Since REST-style denies you the
luxury of attaching arbitrary methods to resource you "run out" of
methods sometimes. So you either
a) pull this trick
b) do RPC (POST a do-what-I want)
or
c) think of a noun-ification of what you want and POST it. As in post a
"CANCELLED-PO resource". I'm not sure if this is really different than
RPC.
I think this trick is best because when we get event-handling and
orchestration integrated you'll be able to set up a chain of events so
that when resource A changes it triggers a POST to one of these trigger
resources. So you could say that when the boss's digital signature
resource appears in one place the approval method is triggered
automatically.
> (Having them be xsltResources makes it really unclear what they're
> supposed to be.)
Typo. I'll change those to "digitalSignatureResource" to be more
realistic. And really they could respond to PUT instead of POST. This
make sense to you:
<resourceType name="digitalSignature"
representations="some-dsig-standard">
<method name="PUT"/>
</resourceType>
> * Am I going to have to invent 187 different schemas for an application?
> Say a resource has a bunch of subresources: an owner, a history, etc.
> Some of these might use an existing schema -- RDF, HTML, whatever --
> but some might return something simple or ad hoc, such as just a
> string or an integer. Do I have to dress up this return value as:
>
> <dummy-root>http://newuri/</dummy-root>
> <dummy-root>35</dummy-root>
>
> Or could I declare "treat the body of this action as a string/integer/
> new URI"?
Several answers to this:
1. I would expect these minor sub-resources to be grouped into a single
logical object. REST encourages coarse-grained, not fine-grained
interactions -- big difference from RPC.
2. I may one day add WebDAV support. WebDAV is very REST-y in that it is
an HTTP extension even if it is not perfectly REST-y. And it has a
first-class notion of properties.
3. But even to do that ad-hoc stuff you don't need 187 schemas. You can
use the XML-RPC or SOAP encoding or WDDX schema for hundreds of ad-hoc
apps. Or just define a schema where <xsd:integer> is of type
<xsd:integer> etc.
4. You could also use MIME-RPC media-types instead of XML at all.
http://www.mime-rpc.com/protocol.html
> I have a project currently specified as a set of XML-RPC interfaces;
> RESTifying it will make an interesting thought experiment.
Cool. I don't always suggest switching from XML-RPC to REST, though. The
terminology I use (now) is that XML-RPC is better for "cross-network
scripting" and REST is for building big, long-lived, scalable,
extensible apps.
I'll fix those bugs. Pedagogic ones are more important at this stage
than ambiguities because it is more a thought experiment than a real
spec.
Paul Prescod
akuchlin@... wrote:
>
>...
>
> REST version:
> GET master/list_services
> Returns a list of services as the body.
> XXX should the optional 'application argument be a URL parameter? Then
> you'd do "GET master/list_services;scope" to get all the microscope
> services. Or should it be the query string?
Good question. I think that the answer is:
* URIs are mostly opaque. This gives you tremendous flexibility as an
application designer. If you relate to resources through a URI then you
could actually move one resource physically to another mean and just
update the link.
* ;-parameters are opaque. So if you use them, you are saying that
client software should NOT understand what the stuff after the semicolon
means.
* ?-parameters are not opaque. You're saying that it's okay for the
client to try to understand tha part of the URI and fiddle with the part
after the ? mark.
Practically speaking you could use "?" if you want to allow an HTML
forms client to work with this stuff. That's a way of thinking through
whether you mean for it to be opaque.
> XXX how should the returned result, which are (service ID, application
> ID, host, port) 3-tuples, be encoded? As an XML-RPC array of structs?
> As a little custom XML schema?
No real advice. Depends on whether you are trying to make life really
easy for the client (xmlrpc.decode()) or whether you want to have other
people elsewhere on the Web support your little "schema" (in which case
a formal definition woudl be better) and whether you think message
self-descriptiveness is important or not. A merger might look like:
<array role="service_description"><int role="id">..</int><int
role="host">...</int>...</array>
Costs and benefits to everything. Also consider an element with three
attributes. Compact, very readable and trivial to work with in a DOM.
But then again, maybe this resource should just be *hyperlnks* to the
services. You could have an optimized "report" sub-resource for fetching
batch data, but I like the idea that Matisse server could incorporate
services described on other people's boxes just by reference. Part of
the benefit of REST. You might not take advantage of it but another
Mattise interface implementor might. ;) Build a web of Matisse's!
> \begin{methoddesc}{get_service}{service}
> Returns a struct (= a Python dictionary or a Java \class{Vector}
> instance) with information about the given service. The contents of
> the struct are explained below. \var{service} is a string containing
> a service ID.
> \end{methoddesc}
>
> REST version: GET master/service;service ID. Returns an HTTP body,
> encoded using the same schema/form as list_services().
I'd use "/" instead of ";" to indicate hierarchy but it doesn't matter
much.
> Interface: Login
>
> \begin{methoddesc}{get_service_ticket}{user_id, password, service_id}
> If the user ID and password are correct, returns a string containing a
> ticket for the given service. If they're wrong, it will raise a fault
> with the fault code 1 and fault string ``IncorrectPassword''.
> \var{user_id}, \var{password}, \var{service_id} are all strings.
> \end{methoddesc}
>
> REST version: POST master/get_service_ticket. This must be HTTP
> authenticated with the username (meaning a human-friendly ID as
> opposed to a URI?) and password. The body is the service ID. Returns
> an authorization ticket as the body.
> XXX should the service ID be specified as a query string?
> XXX or should this be a subset of the service's URI, so you'd access
> master/(service ID)/get_ticket, instead?
Yes, I like this latter one. *BUT* /-separated URIs are opaque so to be
REST-y you need to have service_ids point to their ticket granting
components. The client shouldn't just paste together the URI. Once again
the virtue is that you can put the ticket granting component on any box
on the Web. Plus spiders can follow the links but not guess your URI
conventions.
Should the ticket be a resource? Here's are arguments in favor: the
client can DELETE when it is done with it. When we add notifications to
HTTP, the client could WATCH it to see if the server DELETEs it because
the client is kicked off or something. A client that is kicked off could
do a GET to see if the authorization ticket disappeared or was just
replaced.
Of course, like anything, you need to decide when more REST is more
effort for not enough gain.
> Interface: Authorization
>
> \begin{methoddesc}{check}{user_id, service_id}
> Returns a Boolean value. Returns true if the user \var{user_id}
> is permitted to access the service identified by \var{service_id}.
> \end{methoddesc}
>
> REST version: POST master/check_auth
> XXX how should the two parameters be passed? (XML-RPC again?)
Why not query params?
I notice you have multiple top-level URIs. I think you should have a
Matisse.xml which is a tiny vocabulary that points to them for the URI
opacity reason I've given before. One day you may move some methods off
for load reasons or something and you can do that by just redirecting a
URI. Plus this is a simple form of interface introspection.
> Interface: MetadataStore
>
> \begin{methoddesc}{get_cache_location}{ticket, metadata}
> \var{ticket} and \var{metadata} are both strings. Returns a string
> containing an FTP URL; the data should be stored to this URL.
>
> (Rationale for choosing FTP: it's standard, it seems hard to improve
> on it for shipping data at high speed, and the DPSS code supports it.)
> \end{methoddesc}
Does anyone use "NETBLT"? Someone pointed me at it a few months back.
> REST version: POST master/get_cache_location. The body is your
> authorization ticket. The returned body is the new URI for the data
> time. HTTP PUT the content to the URI to store the data; HTTP PUT the
> metadata to URI/metadata to store it.
> XXX what if you crash after getting the new URI? You now have an empty
> resource. Can this all be done in one HTTP operation?
Sure. Shove as much data as you want down the POST. Maybe it's mildly
non-HTTP-ish to create two resources with a single POST but it is very
mild. If you want to be a purist, use HTTP POST and then a PUT for the
metadata. Have the data time URI point to its metadata.
Method names that start with "get_" bother me because they seem RPC-ish.
Ones that start with get_ and do a POST kind of freak me out. ;) Maybe
generate_data_time or something. Why is this a POST at all instead of a
GET (perhaps dynamic)?
> Interface: MetadataSearch
>
> \begin{methoddesc}{search}{ticket, condition1, condition2, ...}
> Returns a list of metadata IDs that match all of the given conditions.
>
> ... full description deleted ...
> \end{methoddesc}
>
> REST version: No equivalent is attempted. You could let Google crawl
> the URIs for your data, build RDF or topic maps or whatever you like.
> This interface goes away and is replaced by the panoply of search
> technologies available for the Web.
ZEN!
Of course you can always provide a search facility if you want using
query params. There's nothing wrong with it if you can implement it more
efficiently server side.
> Interface: Preferences
>
> \begin{methoddesc}{get_preferences}{ticket, service/application}
> Retrieve a string containing preferences information.
> \end{methoddesc}
> \begin{methoddesc}{set_preferences}{ticket, service/application, prefdata}
> Store the string \var{prefdata} containing preferences information.
> \end{methoddesc}
>
> REST version: easy! To get preferences, POST
> user-URI/prefs/applicationID, passing an authorization ticket as the
> body. To set preferences, PUT to the same URI, passing the preference
> data in the body.
If authorization tickets are resources then you can do a GET of the same
form as this:
user-URI/prefs/applicationID?URI_encoded_authorization_URI....
GET and PUT go nicely together. ;)
Paul Prescod
Paul Prescod <paul@p...> wrote: >I didn't align the examples. That's confusing. For now I'll > mention that fact and then later I'll go through and do that. I think it would help me understand a lot better if you showed the resulting Web resource hierarchy. I'm still confused by a previous version where (I thought) you intended to model states of purchase orders by changing the PO identity. I'm still not clear about exactly what you meant, or if that idea is still part of the proposal. It would also be useful if you showed how the PO gets accepted. Purchase orders represent contractual bindings between buyer and seller and should be explicitly accepted in some way (according to some explicit rules). (I agree that representing the rules in linked XML business process scripts is the right way to do it.) (I assume "approved" is internal, the boss's approval, and not the same as "accepted" by the seller.) One more sort-of side issue: we found in ebXML that digital signatures could not be used (all by themselves) to indicate acceptance, because they are used for so many other purposes. (Rejections should be signed, too.) The content of the signed document or message should explicitly declare its intent. Thanks, Bob Haugen
On Tue, Feb 19, 2002 at 09:17:49PM -0800, Paul Prescod wrote:
>3. But even to do that ad-hoc stuff you don't need 187 schemas. You can
>use the XML-RPC or SOAP encoding or WDDX schema for hundreds of ad-hoc
>apps. Or just define a schema where <xsd:integer> is of type
><xsd:integer> etc.
It seems to me that you'd need two very simple schemas to handle these
ad-hoc bits. One is simply for data structures in your programming
language, and could be XML-RPC (but there's no None in it!), SOAP, or
a language-independent xml_pickle (aren't there a few such
proposals?). Another would be a schema for specifying what sublinks a
resource makes available; this might be your REST specification
schema, or something else.
--amk (www.amk.ca)
Non-masochists, please delete this article NOW.
-- Aaron Watters, 20 Jan 1995
Paul, note that I only mailed my note to the XML-SIG. To explain all
this to rest-discuss readers: I took a set of XML-RPC interfaces and
tried writing out a REST equivalent. My RESTification is described at
http://www.amk.ca/conceit/rest-version.html, and I posted a version of
it to the Python XML-SIG, which is what Paul is replying to.
Thrashing onward...
On Wed, Feb 20, 2002 at 05:00:05AM -0800, Paul Prescod wrote:
>Practically speaking you could use "?" if you want to allow an HTML
>forms client to work with this stuff. That's a way of thinking through
>whether you mean for it to be opaque.
OK, so let's make a few decisions and remove some of those XXX's.
I'll use the query string for this purpose, and will use XML-RPC's
serialization format for bodies that return an arbitrary little data
structure.
>But then again, maybe this resource should just be *hyperlnks* to the
>services. You could have an optimized "report" sub-resource for fetching
So what would these hyperlinks be written in? HTML, generic XLink,
something custom? Aha! You just have to give them names, so it would
be OK to just say <link name='ticket' href='.../ticket'/>. Your
programming language binding would then let you do something like:
serv = Service(<uri>)
ticket = serv.ticket.GET(username, password)
Hm... I'm starting to get that itchy implementing feeling.
>> REST version: GET master/service;service ID. Returns an HTTP body,
>> encoded using the same schema/form as list_services().
>
>I'd use "/" instead of ";" to indicate hierarchy but it doesn't matter
>much.
Of course, when you use '/', the resulting URL
<master>/service/serviceId looks just like the URI for that service!
That actually makes things simpler; got a service URI? Just hit it to
find where that service lives. And <service URI>/ticket can then be
how you get a ticket for that service, and <service
URI>/check_auth?user_id is how you check whether a user can access
that service.
>Should the ticket be a resource? Here's are arguments in favor: the
>client can DELETE when it is done with it. When we add notifications to
>HTTP, the client could WATCH it to see if the server DELETEs it because
>the client is kicked off or something. A client that is kicked off could
>do a GET to see if the authorization ticket disappeared or was just
>replaced.
Interesting possibilities, but they'd make this REST version way more
complicated than the XML-RPC version. More powerful, too, of course
-- the WATCH idea is particularly neat -- but I want to stay close to
the original version's capabilities.
>> REST version: POST master/check_auth
>> XXX how should the two parameters be passed? (XML-RPC again?)
>
>Why not query params?
How about just this: POST <service URI>/check_auth?user_id, returning
an XML-RPC encoded Boolean. And the interface gets a little bit
simpler, again.
>I notice you have multiple top-level URIs. I think you should have a
>Matisse.xml which is a tiny vocabulary that points to them for the URI
>opacity reason I've given before. One day you may move some methods off
>for load reasons or something and you can do that by just redirecting a
>URI. Plus this is a simple form of interface introspection.
So this could potentially be as simple as just name/URI pairs since
these are just hyperlinks, right?. Return types and all that could be
added later, but aren't mandatory.
>> XXX what if you crash after getting the new URI? You now have an empty
>> resource. Can this all be done in one HTTP operation?
>
>Sure. Shove as much data as you want down the POST. Maybe it's mildly
>non-HTTP-ish to create two resources with a single POST but it is very
>mild. If you want to be a purist, use HTTP POST and then a PUT for the
>metadata. Have the data URI point to its metadata.
I think I like the POST+PUT approach. Putting two resources, data +
metadata, in a single POST isn't practical because the data might be
very large, say a couple of gigabytes.
>Method names that start with "get_" bother me because they seem RPC-ish.
>Ones that start with get_ and do a POST kind of freak me out. ;) Maybe
>generate_data_time or something. Why is this a POST at all instead of a
>GET (perhaps dynamic)?
Revised REST version: POST <master>/new_cache_location?<ticket>. The
body is the data to be stored. You will be returned a Location:
header with the new URI for the data object. GET from the new URI to
get a URI for the metadata (probably URI/metadata); HTTP PUT the
metadata to store it.
>> Interface: MetadataSearch
>> REST version: No equivalent is attempted. You could let Google crawl
>> the URIs for your data, build RDF or topic maps or whatever you like.
>> This interface goes away and is replaced by the panoply of search
>> technologies available for the Web.
>Of course you can always provide a search facility if you want using
>query params. There's nothing wrong with it if you can implement it more
>efficiently server side.
Then again, if I have private data that I don't want Google to index
for all the world to see, using HTTP+URIs doesn't buy me much. And
even if they're public, Google doesn't index arbitrary XML documents.
(Stray thought: I wonder if you could crawl the world's XML documents
and efficiently support an XPath query over them all?)
>> Interface: Preferences
>> REST version: easy! To get preferences, POST
>> user-URI/prefs/applicationID, passing an authorization ticket as the
>> body. To set preferences, PUT to the same URI, passing the preference
>> data in the body.
I'm not sure whether preferences are a property of the user, indexed
by application, or a property of the application indexed by user. If
the latter, then GETting/PUTting to <service-URI>/prefs?<URI-encoded
ticket> works nicely.
Hmmm... there are no more XXX's in my text, the rewritten REST version
now uses GET instead of POST in many places, and in fact the
new_cache_location method is the only one left that uses POST. The
REST version is beginning to seem fairly clean, and roughly comparable
in complexity to the XML-RPC version, given the right set of
client-side abstractions. Interesting...
--amk (www.amk.ca)
But are not the dreams of poets and the tales of travellers
notoriously false?
-- H.P. Lovecraft, "The Street"
After reading Paul Prescod's REST article on XML.com I was
instantly converted :-). I'm trying to apply REST principles to
a provisioning interface I'm working on. The interface creates
typical VISP (virtual ISP) services such as a website or email
account.
At the highest level I've defined what I call a profile, it looks
something like this:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<profile username="user1">
<website domain="www.customer.com">
<!-- the path (below) is mainly useful for customers that
don't get their own domains, in which case it would
typically be /username
-->
<path>/</path>
<password>secret1</password>
<storage-space>15</storage-space> <!-- MB -->
<bandwidth>50</bandwidth> <!-- MB/day -->
</website>
<email-domain domain="customer.com" type="standard">
<email-account local-part="me">
<password>secret2</password>
<storage-space>5</storage-space> <!-- MB again -->
<email-alias alias="myself"/>
</email-account>
</email-domain>
</profile>
</viml>
Which provisions
- The website http://www.customer.com/
with FTP access using the given password
- The email address me@...
with POP3 access using the given password
- The email alias myself@...
which really goes to me@...
An email domain can also have type="backup" which means it
accepts mail for relay only, i.e., the customer has their own
mail server and uses us as backup.
URIs have the form:
http://server/visp/serviceid/vispid/identifier
That's a little difficult to understand, so here's an example:
http://server/visp/website/xyz/user1
^^^^^^^^^^^^^^^^^^
Fixed
In this case the serviceid is website, the vispid is xyz, and
the identifier is user1. The idea is that you can make the
identifier more complex to drill down to only one component of
the profile, e.g., to refer to the alias in the example above:
http://server/visp/email-alias/xyz/user1/customer.com/me/myself
Now when the XYZ client wants to provision some services for a
new user who's signed up, they need to create the services.
At the moment, for the above example, this would mean doing
the following PUTs with the given data:
PUT /visp/website/xyz/user1/www.customer.com
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<website domain="www.customer.com">
<path>/</path>
<password>secret1</password>
<storage-space>15</storage-space>
<bandwidth>50</bandwidth>
</website>
</viml>
PUT /visp/email-domain/xyz/user1/customer.com
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<email-domain domain="customer.com" type="standard"/>
</viml>
PUT /visp/email-account/xyz/user1/customer.com/me
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<email-account local-part="me">
<password>secret</password>
<storage-space>5</storage-space>
</email-account>
</viml>
PUT /visp/email-alias/xyz/user1/customer.com/me/myself
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<email-alias alias="myself"/>
</viml>
Some things can be updated, for example, the storage space or
password for a website, others must be deleted and recreated,
like email aliases.
Problems I have with my own design:
- If I were a client I would expect to be able to send a
whole profile and have everything provisioned at once.
This is not insurmountable, just more effort (and some
thinking about transactional guarantees, if any).
- There is redundant data in each request that is already in
the URI. This means extra processing on both sides, and an
extra check on my side -- and what do I do if there's a
mismatch?
- For an update (POST) it's not always clear what can and
can't change. For example, when updating a website you can
change the password but not the path. In the case of an alias
you can't even do an update. I see problems ahead.
I feel like I'm almost there, but I'm still missing something.
Any comments or suggestions for improvement welcome.
-- Andrew
"Inggs, Andrew" wrote: > >... > URIs have the form: > > http://server/visp/serviceid/vispid/identifier > > That's a little difficult to understand, so here's an example: > > http://server/visp/website/xyz/user1 > ^^^^^^^^^^^^^^^^^^ > Fixed > > In this case the serviceid is website, the vispid is xyz, and > the identifier is user1. The idea is that you can make the > identifier more complex to drill down to only one component of > the profile, e.g., to refer to the alias in the example above: > > http://server/visp/email-alias/xyz/user1/customer.com/me/myself If client applications are supposed to care about the structure of the URI then you should use query parameters. The /s/s/s/s/ part of the URI is supposed to be opaque to client software. Only the server knows or cares what the slashes mean. The best way to establish hierarchy is through XML documents where the parent has hyperlinks to the children and they have hyperlinks to their children and so forth. Consider, for example, how easy it becomes to write a spider that slurps up the structre and moves it. (if you consider that a good thing...otherwise forget I said it. ;) > Now when the XYZ client wants to provision some services for a > new user who's signed up, they need to create the services. > At the moment, for the above example, this would mean doing > the following PUTs with the given data: > > PUT /visp/website/xyz/user1/www.customer.com > > <?xml version="1.0" encoding="iso-8859-1"?> > <!DOCTYPE viml SYSTEM "viml.dtd"> > <viml> > <website domain="www.customer.com"> > <path>/</path> > <password>secret1</password> > <storage-space>15</storage-space> > <bandwidth>50</bandwidth> > </website> > </viml> I would use a POST for two reasons. First, uses of PUTs to brand new URIs that the client creates are not opaque. Second, you don't have to duplicate the data, as you noticed. PUTs are okay for creating new things when there is a good reason for the client to "own" the namespace as in a content management situation. >... > Problems I have with my own design: > > - If I were a client I would expect to be able to send a > whole profile and have everything provisioned at once. > This is not insurmountable, just more effort (and some > thinking about transactional guarantees, if any). POST can handle that. > - There is redundant data in each request that is already in > the URI. This means extra processing on both sides, and an > extra check on my side -- and what do I do if there's a > mismatch? POST can handle that. > - For an update (POST) it's not always clear what can and > can't change. For example, when updating a website you can > change the password but not the path. In the case of an alias > you can't even do an update. I see problems ahead. Actually, you should use *PUT* for updates and POST for creating new stuff. It's helpful to read the definitions of the major methods here: http://www.w3.org/Protocols/rfc2068/rfc2068 Anyhow, are your update problems really any different than validation problems? Trying to update a password is logically impermissable so you return an error, just like if you tried to put an integer where a phone number should go. Hope those ideas help. Paul Prescod
The subject article, at http://www.xml.com/lpt/a/2002/02/20/rest.html is really excellent. This comment is just a minor quibble. In the article, Paul Prescod wrote: "Once you begin to orchestrate multiple web services, transaction processing becomes much harder. It is very difficult for the client to get the various services to have a common view of a "transaction" so that a failure on any service causes a complete rollback on all of them. HTTP does not have a magical solution to this problem but neither do specifications such as SOAP or ebXML. The solutions proposed by the OASIS Business Transactions working group are currently protocol agnostic and should work fine with HTTP." ebXML does have a business transaction protocol. It is the same as the RosettaNet PIP protocol, and has also been used previously in telecommunications. The documents describing it are way too complicated for their own good, but the protocol is fairly simple. It is a two-party set of stereotyped messages with timeouts that either succeed completely or fail completely. The goal is business state alignment instead of database transactions. An example of business state alignment: the Purchase Order was either accepted or rejected or the transaction failed due to a timeout. The OASIS Business Transaction group dismisses the ebXML/RosettaNet transaction protocol as too simplistic (last I saw). They provide for multi-party transactions, which ebXML/RosettaNet do not. On the other hand, we in ebXML have not found any multi-party business process so far that could not be broken down into orchestrated sets of two-party commitments and thus two-party transactions. ebXML business transactions are described in: http://homepage.interaccess.com/~linkage/COOL.ppt http://www.ebxml.org/specs/ebBPSS.pdf http://www.ebtwg.org/projects/documentation/bioreference/pdf/Chapter9_ Patterns.pdf -Bob Haugen
Andrew, Paul --- I think this is a great thread! It's nice to see somebody looking at RESTifying an already-designed XML-RPC interface with a possible eye towards implementation instead of simply as a thought experiment. And the idea about language binding is *juicy...* (Hint, hint, Andrew. ;-) Just a few comments, with the proviso that my understanding of Matisse is limited to a single read-through of the REST and RPC specs. > <service > URI>/check_auth?user_id is how you check whether a user can access > that service. This is more an aesthetics-of-naming comment than anything else, but it seems to me that there's a more "resourceful" way to model this. How about <serviceURI>/users GET returns a collection of authorized users for this service ...and optionally.... POST of <something?> if authorized adds a user to this service, creating a new userID PUT of <something?> if authorized replaces the collection of authorized users <serviceURI>/users/userID GET returns a struct describing the user, if it exists and is authorized; 404 means not authorized ...and optionally... POST / PUT update or replace user by userID DELETE removes a user Note that while the controversy rages on over whether URI and verbs (e.g. "check_auth") are in some way incompatible, the more I work through these things the more I find that (a) verbs-as-resources usually aren't necessary, and (b) URI-izing what are otherwise parameters to methods / verbs generally results in the exposure of domain objects as interesting resources in their own right. > Interesting possibilities, but they'd make this REST version way more > complicated than the XML-RPC version. More powerful, too, of course > -- the WATCH idea is particularly neat -- but I want to stay close to > the original version's capabilities. Ignoring WATCH, it's still probably useful to consider whether making tickets into resources adds some value to what you're doing.... IMO but admittedly at first glance, it would seem that making authentication / authorization tickets first-class citizens of URI space is a powerful idea. > How about just this: POST <service URI>/check_auth?user_id, returning > an XML-RPC encoded Boolean. And the interface gets a little bit > simpler, again. Cf. above comments about URI-izing users, user_ids, etc. While it makes the interface slightly larger, it seems much more RESTful and flexible to me without adding a whole lot to implementation complexity or bulk. > >Sure. Shove as much data as you want down the POST. Maybe it's mildly > >non-HTTP-ish to create two resources with a single POST but it is very > >mild. If you want to be a purist, use HTTP POST and then a PUT for the > >metadata. Have the data URI point to its metadata. > > I think I like the POST+PUT approach. Putting two resources, data + > metadata, in a single POST isn't practical because the data might be > very large, say a couple of gigabytes. Call me a purist, but it seems that this is the correct way to do this. Having the metadata be a subresource of the data URI, hyperlinking them, and operating on them independently via separate methods adds much flexibility. (Think: it could then be possible to eventually use content negotiation to return different representations of the data URI's metadata... yummy. :-) > Revised REST version: POST <master>/new_cache_location?<ticket>. The > body is the data to be stored. You will be returned a Location: > header with the new URI for the data object. GET from the new URI to > get a URI for the metadata (probably URI/metadata); HTTP PUT the > metadata to store it. Yup. Nitty aesthetic naming suggestion: how about <master>/cache instead of all that new_cache_location stuff? > Then again, if I have private data that I don't want Google to index > for all the world to see, using HTTP+URIs doesn't buy me much. Well, not necessarily true. The benefit is that you've got all your domain objects named and structured and accessible via a generic interface, which makes integrating with / extending these things much, much easier. There's lots of benefits to this besides making this stuff Google-friendly. > I'm not sure whether preferences are a property of the user, indexed > by application, or a property of the application indexed by user. If > the latter, then GETting/PUTting to <service-URI>/prefs?<URI-encoded > ticket> works nicely. I agree, and I think this is a better way to look at the problem. jb
I need a spec lawyer! ;-) So we've had various discussions of this
topic on this and other lists in the past, with various conclusions...
will somebody clear something up for me? Is the following:
http://foo.bar.com/users/joe@...
a valid HTTP URI or not? If so, what does it mean? Skipping straight
to the meat, my conclusion is that, grammatically per RFC 2396 and 2616,
the above probably *should* and is probably *intended* to be a valid URI
without an authority component --- i.e., the '@' sign is not used to
separate the elements of an authority component, but rather
"joe@..." is an opaque segment --- but strictly speaking it's
impossible to determine whether this is the case or not. Comments?
Dangers of using this form of URI? Etc.?
jb
--------
Details
--------
RFC 2396, 2.2:
Many URI include components consisting of or delimited by, certain
special characters. These characters are called "reserved", since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
The "reserved" syntax class above refers to those characters that are
allowed within a URI, but which may not be allowed within a
particular component of the generic URI syntax; they are used as
delimiters of the components described in Section 3.
3.2. Authority Component
Many URI schemes include a top hierarchical element for a naming
authority, such that the namespace defined by the remainder of the
URI is governed by that authority. This authority component is
typically defined by an Internet-based server or a scheme-specific
registry of naming authorities.
authority = server | reg_name
The authority component is preceded by a double slash "//" and is
terminated by the next slash "/", question-mark "?", or by the end of
the URI. Within the authority component, the characters ";", ":",
"@", "?", and "/" are reserved.
...but we're beyond the authority component, at least semantically, in
my example URI. It may be that some parsers incorrectly use the first @
symbol to identify the authority component... strictly, though, it
would appear that everything's good so far in using the @ sign in this
manner outside an authority component. Now to the meat of the matter.
By the grammar introduced in RFC 2396:
3.3. Path Component
The path component contains data, specific to the authority (or the
scheme if there is no authority component), identifying the resource
within the scope of that scheme and authority.
path = [ abs_path | opaque_part ]
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
Crosschecking this with RFC 2616:
3.2.1 General Syntax
...For definitive information on
URL syntax and semantics, see "Uniform Resource Identifiers (URI):
Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1738 [4] and RFC 1808 [11]). This specification adopts the
definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"host","abs_path", "rel_path", and "authority" from that
specification.
3.2.2 http URL
The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
So here's the sticky bit in interpreting this. An HTTP URI includes an
abs_path... which resolves to segments, not paths... however both
ultimately resolve to pchars, for which '@' is an acceptable character.
Here's the ambiguous bit: tracing from
abs_path -> path_segments -> segment -> pchar, params -> pchar
*it doesn't appear from the grammar defined in 3.2.2 that an authority
component may be included.* However, 2616 5.1.2 identifies a correctly
formed Request-URI as being:
Request-URI = "*" | absoluteURI | abs_path | authority
...which is even more mysterious, as it says you can pass an authority
component *but only as the only component of a Request-URI?*
My conclusion is that, grammatically per RFC 2396 and 2616,
http://foo.bar.com/users/joe@...
probably *should* and is probably *intended* to be a valid URI, but
strictly speaking it's impossible to determine whether in fact it is or
it isn't. Comments? Dangers of using this form of URI? Etc.?
jb
> From: Paul Prescod
>
> "Inggs, Andrew" wrote:
> >
> >...
[snip]
> > http://server/visp/email-alias/xyz/user1/customer.com/me/myself
>
> If client applications are supposed to care about the
> structure of the URI then you should use query
> parameters. The /s/s/s/s/ part of the URI is supposed to
> be opaque to client software. Only the server knows or
> cares what the slashes mean.
>
Is that the only consideration? I just felt that the /s
help to show the hierarchy -- but perhaps that's a bad
thing if that hierarchy were ever to change.
So my URIs become
http://server/visp/serviceid?...
with (all) possible query parameters:
v=<vispid>&u=<userid>&d=<domain>&lp=<local-part>&a=<alias>
maybe I should then make the query parameters more natural,
for example, an email address could be identified by
v=<vispid>&u=<userid>&e=<local-part>@<domain>
> The best way to establish hierarchy is through XML
> documents where the parent has hyperlinks to the
> children and they have hyperlinks to their children
> and so forth. Consider, for example, how easy it becomes
> to write a spider that slurps up the structure and moves
> it. (if you consider that a good thing...otherwise forget
> I said it. ;)
>
Sounds like a good idea, but feels like overkill for my
little application. Is there a standard for hyperlinking
in XML, or would that potentially be something a formal
REST architecture could define?
If I used query parameters and hyperlinks, would that make
sense, or should I go back to slashes then? For example:
<visp>
<user username="user1">
<website href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
<email-domain href="/visp/email-domain?v=xyz&u=user1&d=customer.com"/>
...
</user>
</visp>
or
<visp>
<user username="user1">
<website href="/visp/website/xyz/user1/www.customer.com"/>
<email-domain href="/visp/email-domain/xyz/user1/customer.com"/>
...
</user>
</visp>
> > Now when the XYZ client wants to provision some services for a
> > new user who's signed up, they need to create the services.
> > At the moment, for the above example, this would mean doing
> > the following PUTs with the given data:
> >
> > PUT /visp/website/xyz/user1/www.customer.com
> >
> > <?xml version="1.0" encoding="iso-8859-1"?>
> > <!DOCTYPE viml SYSTEM "viml.dtd">
> > <viml>
> > <website domain="www.customer.com">
> > <path>/</path>
> > <password>secret1</password>
> > <storage-space>15</storage-space>
> > <bandwidth>50</bandwidth>
> > </website>
> > </viml>
>
> I would use a POST for two reasons. First, uses of PUTs to brand new
> URIs that the client creates are not opaque. Second, you don't have to
> duplicate the data, as you noticed.
>
So I'd change the resource of what's specified in the URI to one
level up. I would add a user by "appending" to the VISP's list
of users. To create user1, I might do
POST /visp/users?v=xyz
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
<user username="user1/>
</viml>
> PUTs are okay for creating new things when there is a good reason for
> the client to "own" the namespace as in a content management
> situation.
>
Well, in a sense my clients own the namespace, in that they
choose the usernames, domains, etc. Or am I getting my
terminology wrong now?
> >...
> > Problems I have with my own design:
> >
> > - If I were a client I would expect to be able to send a
> > whole profile and have everything provisioned at once.
> > This is not insurmountable, just more effort (and some
> > thinking about transactional guarantees, if any).
>
> POST can handle that.
>
I'm not sure how changing to a POST solves this one. Perhaps
I should break the hierarchy out of the DTD and define everything
at the top level.
> > - There is redundant data in each request that is already in
> > the URI. This means extra processing on both sides, and an
> > extra check on my side -- and what do I do if there's a
> > mismatch?
>
> POST can handle that.
>
Yes.
> > - For an update (POST) it's not always clear what can and
> > can't change. For example, when updating a website you can
> > change the password but not the path. In the case of an alias
> > you can't even do an update. I see problems ahead.
>
> Actually, you should use *PUT* for updates and POST for creating new
> stuff. It's helpful to read the definitions of the major methods here:
>
> http://www.w3.org/Protocols/rfc2068/rfc2068
>
Yes, provided you look one level up. So to change the storage
space for a website one would do a PUT on the storage space
resource, rather than a POST to the website resource, which
would not have made it clear what one was trying to update.
I think this is what I was missing, I was thinking at
the wrong level of identification because I had specific
ideas about how POST and PUT should be used. I saw
adding a service as requiring a 201 (Created) response,
which I would get from a PUT.
> Anyhow, are your update problems really any different than
> validation problems? Trying to update a password is logically
> impermissable so you return an error, just like if you tried
> to put an integer where a phone number should go.
>
Absolutely, and as soon as you identify the password in
the URI, you can easily do that validation. Actually,
changing a password is allowed, but never mind that :-).
> Hope those ideas help.
>
Yes, thanks!
Regards,
Andrew
Hi, Paul. Great work on the draft. I was working on something similar a few months ago but lost momentum on it. Here's the thoughts that I had while reading your proposal. Can we see a full WRDL document as an example? An XML Schema would be nice, too. Will there be a way to bind URIs to resourceTypes in WRDL? Or are you not going down the route to avoid what WSDL has become? I can definitely see the benefits to NOT hardcoding a specific WRDL file to one set of URIs. Is WRDL strictly limited to sending and receving XML documents? I can understand reducing scope if it is. However, it might be very useful to allow for form-data inputs. I'd like to be able to do a GET on a resource that returns an HTML form so that I could do a POST interactively or (using WRDL) programmatically. Of course, if I was using WRDL, I wouldn't need to GET the resource for the HTML form. For uniformity, extra headers, query parameters, and form-data variables (if supported) should always be allowed. Should we leverage XML Schema datatypes for the types of inputs? Do types default to strings if unspecified? Not all languages support default values for parameters. Do we really need default and fixed? If it's fixed, why would it be an input? XML has a case for it but I'm does WRDL? Will there be a way to define input-sets (like XSLT's attribute-sets)? <input-set name="my-input-set"> <query name="my-int-query" type="int" /> <header name="my-string-header type="string" /> </input-set> <method name="GET"> <input use-input-sets="my-input-set" /> </method> If we allow something like input-sets, maybe instead of a representations attribute on the input element, there should be a body element (as a child of input) with a representations attribute just for uniformity. Will there me any sort of support for modularity? wrdl:include? You have a creates attributes on a POST method and also a created/@representations child element but only mention the creates attribute. Is there supposed to be only one of them? Is it representation or representationType? You have some representationType elements with match attributes (instead of test). Should we be able to specify an XML Schema for a representationType? I think that you're trying to do too much with simple binding references. Why not leverage some other specification? I think I would actually prefer WRDL to stay simple and not specify any binding mechanism at all. Binding to an XML document should be orthogonal to how you received it. Having said that, I have a few comments on references as they are written. If reference/@name is optional, how would you refer to it? Your sample API looks like the reference name gets converted into a method name. I think it should be required. reference/@match should is closer to XSLT's xsl:value-of/@select attribute than xsl:template/@match. match attributes are restricted to a subset of XPath that can only evaluate to node sets. Speaking of node sets, what if your reference's match (or select) attribute evaluates a node set? Does it return an array? Only if maxOccurs is greater than 1? These are the types of questions that I believe shouldn't be answered by WRDL. Should WRDL support HTTPEvents so that languages that support events can seamlessly subscribe to them? Or is that too SOAP-ish? I hope this helps. I'll be glad to work on an implementation as it gets hammered out. Jason
"Inggs, Andrew" wrote: > >... > > > Is that the only consideration? I just felt that the /s > help to show the hierarchy -- but perhaps that's a bad > thing if that hierarchy were ever to change. Right! That's exactly why the client shouldn't care about the URI hierarchy. >... > maybe I should then make the query parameters more natural, > for example, an email address could be identified by > > v=<vispid>&u=<userid>&e=<local-part>@<domain> I think that's okay but see Jeff Bone's recent post. ;) >... > Sounds like a good idea, but feels like overkill for my > little application. Is there a standard for hyperlinking > in XML, or would that potentially be something a formal > REST architecture could define? There are two standards (the nice thing about standards...) XLink and RDF. But they are probably overkill. I would just use an attribute with an "href". > If I used query parameters and hyperlinks, would that make > sense, or should I go back to slashes then? For example: > > <visp> > <user username="user1"> > <website href="/visp/website?v=xyz&u=user1&d=www.customer.com"/> > <email-domain href="/visp/email-domain?v=xyz&u=user1&d=customer.com"/> > ... > </user> > </visp> It all boils down to whether you expect the client to want to construct those URIs. If it will always use the XML files for navigation then you have complete freedom and would probably use the slashes. If the client is going to want to sometimes do navigation without going through the XML files then you should use query params. >... > So I'd change the resource of what's specified in the URI to one > level up. I would add a user by "appending" to the VISP's list > of users. Exactamundo! > ... To create user1, I might do > > POST /visp/users?v=xyz > > <?xml version="1.0" encoding="iso-8859-1"?> > <!DOCTYPE viml SYSTEM "viml.dtd"> > <viml> > <user username="user1/> > </viml> Right! > > PUTs are okay for creating new things when there is a good reason for > > the client to "own" the namespace as in a content management > > situation. > > > Well, in a sense my clients own the namespace, in that they > choose the usernames, domains, etc. Or am I getting my > terminology wrong now? I would say that your clients own their names and those names are combined by the server into the URI namespace. In a content management situation it is only the human being doing the publishing who knows why they put it in /financial instead of /development. > > >... > > > Problems I have with my own design: > > > > > > - If I were a client I would expect to be able to send a > > > whole profile and have everything provisioned at once. > > > This is not insurmountable, just more effort (and some > > > thinking about transactional guarantees, if any). > > > > POST can handle that. > > > I'm not sure how changing to a POST solves this one. Perhaps > I should break the hierarchy out of the DTD and define everything > at the top level. Sorry, I meant to say that a POST could actually create more than one resource. I don't think it violates HTTP semantics to have it do so. We could probably argue about that though. This issue of batch data sending has arisen before...there are three reasons to want it: 1. client convenience, 2. reducing network latency and 3. atomicity. >... > I think this is what I was missing, I was thinking at > the wrong level of identification because I had specific > ideas about how POST and PUT should be used. I saw > adding a service as requiring a 201 (Created) response, > which I would get from a PUT. Note that POST can generate a Created response too. Paul Prescod
Jason Diamond wrote: > > Hi, Paul. > > Great work on the draft. I was working on something similar a few months ago > but lost momentum on it. Here's the thoughts that I had while reading your > proposal. Thanks! > Can we see a full WRDL document as an example? An XML Schema would be nice, > too. Will do. But someday... > Will there be a way to bind URIs to resourceTypes in WRDL? Or are you not > going down the route to avoid what WSDL has become? I can definitely see the > benefits to NOT hardcoding a specific WRDL file to one set of URIs. Yeah, I don't know if I see the advantage. I do think it might be neat if there were an HTTP > Is WRDL strictly limited to sending and receving XML documents? No. It's just that it can only extract hyperlinks from XML. And of course XHTML.... > ... I can > understand reducing scope if it is. However, it might be very useful to > allow for form-data inputs. I'd like to be able to do a GET on a resource > that returns an HTML form so that I could do a POST interactively or (using > WRDL) programmatically. Of course, if I was using WRDL, I wouldn't need to > GET the resource for the HTML form. Right. So I'm not sure what you are asking for or if you are just thinking aloud. WRDL is for a client of the service figuring out its behaviour in advance. HTML form parameters are not necessary because the service description has the parameters in it. > For uniformity, extra headers, query parameters, and form-data variables (if > supported) should always be allowed. form-data variables are query parameters. > Should we leverage XML Schema datatypes for the types of inputs? Do types > default to strings if unspecified? Yes and yes. > Not all languages support default values for parameters. In some sense they all do. Remember that you will probably be generating a client library so the generated library can fill in the default values. > ... Do we really need > default and fixed? If it's fixed, why would it be an input? XML has a case > for it but I'm does WRDL? I just wanted to be the same as XML Schema. I think the case is about as strong or weak (both) as XML. You could define a WRDL for a service you didn't control in order to generate a client library. Maybe you want to hard-code a parameter. Not a majorly useful feature but not in XML either... > Will there be a way to define input-sets (like XSLT's attribute-sets)? Maybe. Have to see if there is a need for it. > <input-set name="my-input-set"> > <query name="my-int-query" type="int" /> > <header name="my-string-header type="string" /> > </input-set> > > <method name="GET"> > <input use-input-sets="my-input-set" /> > </method> > > If we allow something like input-sets, maybe instead of a representations > attribute on the input element, there should be a body element (as a child > of input) with a representations attribute just for uniformity. True. > Will there me any sort of support for modularity? wrdl:include? Yes, certainly. > You have a creates attributes on a POST method and also a > created/@representations child element but only mention the creates > attribute. Is there supposed to be only one of them? Yeah...but I don't remember which right now. You pick. ;) > Is it representation or representationType? You have some representationType > elements with match attributes (instead of test). I went back and forth on that one....representationType I guess. > Should we be able to specify an XML Schema for a representationType? Maybe you should be able to specify arbitrary extra validation information. > I think that you're trying to do too much with simple binding references. > Why not leverage some other specification? I think I would actually prefer > WRDL to stay simple and not specify any binding mechanism at all. Binding to > an XML document should be orthogonal to how you received it. Having said > that, I have a few comments on references as they are written. Really the question isn't binding to the XML document but binding to the *resource*. Subtle but important difference. Note that hyperlinks in WRDL are from resourceTypes to resourceTypes. A pure XML binding language would go from XML elements to XML elements. > If reference/@name is optional, how would you refer to it? Your sample API > looks like the reference name gets converted into a method name. I think it > should be required. Maybe that's just something you couldn't refer to. I could go eithre way. > reference/@match should is closer to XSLT's xsl:value-of/@select attribute > than xsl:template/@match. match attributes are restricted to a subset of > XPath that can only evaluate to node sets. Isn't that what I want? I want to get a node set representing a set of nodes to annotate. > Speaking of node sets, what if your reference's match (or select) attribute > evaluates a node set? Does it return an array? Only if maxOccurs is greater > than 1? Yeah, that's actually why I added the concept of maxOccurs. > ... These are the types of questions that I believe shouldn't be > answered by WRDL. But they are. ;) > Should WRDL support HTTPEvents so that languages that support events can > seamlessly subscribe to them? Or is that too SOAP-ish? Yes, WRDL should support subscription to HttpEvents. The client binding may or may not help you to actually respond to events. > I hope this helps. I'll be glad to work on an implementation as it gets > hammered out. Great! Paul Prescod
On Thu, Feb 21, 2002 at 04:40:56PM -0600, Jeff Bone wrote: > > I need a spec lawyer! ;-) I've been called that before. However, I wasn't specified as such. :) > So here's the sticky bit in interpreting this. An HTTP URI includes an > abs_path... which resolves to segments, not paths... however both > ultimately resolve to pchars, for which '@' is an acceptable character. > Here's the ambiguous bit: tracing from > > abs_path -> path_segments -> segment -> pchar, params -> pchar Right. > *it doesn't appear from the grammar defined in 3.2.2 that an authority > component may be included.* Whoa; what makes you say that? 3.2.2 constructs the authority in, with host [':' port ] I'd note that this BNF rule isn't used anywhere in 2616. It also appears to be specific to protocol use; it doesn't include fragment identifiers, for example. > However, 2616 5.1.2 identifies a correctly formed Request-URI as > being: > > Request-URI = "*" | absoluteURI | abs_path | authority > > ...which is even more mysterious, as it says you can pass an authority > component *but only as the only component of a Request-URI?* That's a bit weird, but I imagine it's left as a hook for future use (Apache doesn't seem to support it, for example). > My conclusion is that, grammatically per RFC 2396 and 2616, > > http://foo.bar.com/users/joe@... > > probably *should* and is probably *intended* to be a valid URI, but > strictly speaking it's impossible to determine whether in fact it is or > it isn't. Comments? Dangers of using this form of URI? Etc.? I don't understand what your concern above is, but my reading is that it's allowed, as per RFC2396 Section 3.3. -- Mark Nottingham http://www.mnot.net/
Paul Prescod wrote:
> >...
> > maybe I should then make the query parameters more natural,
> > for example, an email address could be identified by
> >
> > v=<vispid>&u=<userid>&e=<local-part>@<domain>
>
> I think that's okay but see Jeff Bone's recent post. ;)
>
Well query parameters should be escaped, but I think I'll
steer clear of that one :-).
> > [...] Is there a standard for hyperlinking in XML, or
> > would that potentially be something a formal REST
> > architecture could define?
>
> There are two standards (the nice thing about standards...)
> XLink and RDF. But they are probably overkill. I would just
> use an attribute with an "href".
>
I'll have a look at those then, thanks.
> > If I used query parameters and hyperlinks, would that make
> > sense, or should I go back to slashes then? For example:
[...]
>
> It all boils down to whether you expect the client to want to
> construct those URIs. If it will always use the XML files for
> navigation then you have complete freedom and would probably
> use the slashes. If the client is going to want to sometimes
> do navigation without going through the XML files then you
> should use query params.
>
Query parameters it is then. Is there a verdict about whether
both types are allow, but the client can only use slashes when
following hyperlinks, otherwise query parameters?
> > ... To create user1, I might do
> >
> > POST /visp/users?v=xyz
> >
> > <?xml version="1.0" encoding="iso-8859-1"?>
> > <!DOCTYPE viml SYSTEM "viml.dtd">
> > <viml>
> > <user username="user1/>
> > </viml>
>
> Right!
>
Say I create a website at the same time. In the response,
would it be OK for the domain attribute to be there as well
as the href?
...
<user username="user1">
<website domain="www.customer.com"
href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
</user>
...
Perhaps not make it a website element, but a generic link:
...
<user username="user1">
<child href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
</user>
...
<thinking-out-loud>
Oh no, then I'm going to have to define a separate doctype for
each of my services. Unless I add a type attribute.
</thinking-out-loud>
> > Well, in a sense my clients own the namespace, in that they
> > choose the usernames, domains, etc. Or am I getting my
> > terminology wrong now?
>
> I would say that your clients own their names and those
> names are combined by the server into the URI namespace.
> In a content management situation it is only the human
> being doing the publishing who knows why they put it in
> /financial instead of /development.
>
Agreed. The client owns some of the names, but I (the domain
name owner) am still saying how and where they can be used.
> > > >...
> > > > Problems I have with my own design:
> > > >
> > > > - If I were a client I would expect to be able to send a
> > > > whole profile and have everything provisioned at once.
> > > > This is not insurmountable, just more effort (and some
> > > > thinking about transactional guarantees, if any).
> > >
> > > POST can handle that.
> > >
> > I'm not sure how changing to a POST solves this one. Perhaps
> > I should break the hierarchy out of the DTD and define everything
> > at the top level.
>
> Sorry, I meant to say that a POST could actually create more than one
> resource. I don't think it violates HTTP semantics to have it
> do so. We could probably argue about that though.
>
> This issue of batch data sending has arisen before...there are three
> reasons to want it: 1. client convenience, 2. reducing network latency
> and 3. atomicity.
>
Yes, but 1 and 3 mean more work for me. But possibly not
as much as I first thought -- if I do the design right.
> >...
> > I think this is what I was missing, I was thinking at
> > the wrong level of identification because I had specific
> > ideas about how POST and PUT should be used. I saw
> > adding a service as requiring a 201 (Created) response,
> > which I would get from a PUT.
>
> Note that POST can generate a Created response too.
>
Yes, I saw that too late. I'm now thinking in a sort of
directory and file (or SQL INSERT and UPDATE) analogy and
that's helped me get out of my PUT = create mindset.
Thanks very much for your comments, I very much feel like I'm
getting somewhere!
Regards,
Andrew
Mark Nottingham wrote: > > *it doesn't appear from the grammar defined in 3.2.2 that an authority > > component may be included.* > > Whoa; what makes you say that? 3.2.2 constructs the authority in, > with > host [':' port ] > > I'd note that this BNF rule isn't used anywhere in 2616. Sorry, I was a bit ambiguous... the latter is what I meant. This rule isn't used and AFAICT there's no way to get to it from the rules that are directly used in 2616, -wrt- path segments. > That's a bit weird, but I imagine it's left as a hook for future use > (Apache doesn't seem to support it, for example). I think it's a bit underspecified. > I don't understand what your concern above is, but my reading is that > it's allowed, as per RFC2396 Section 3.3. My concern is just that, strictly from the spec, it's difficult to tell whether '@' is kosher in path segments. AFAICT it is, but the way the grammars interact between the two RFCs makes it difficult to give an authoritative answer; some regexp-based URI parsers I've seen get this wrong. Thanks for the comments, very helpful! jb
On that 'xml representation of http'... If you convert an http request (blob of text+stuff) into a collection of nodes that are addressable (ala groves) you can then point to different parts - which helps identify where data comes from and where data (parameters) go to. Having headers and body accessible this way allows for a single mechanism to do that addressing - you use xpath (or some other node addressing syntax) to point to a header just like pointing to the uri or method or status or body or whatever. Downloading a description of how to construct a request sounds like what wrdl is about - which to me is 'discovery' and really the only piece the soap approach has over the pure http approach (assuming doing http+xml). I don't know why http doesn't have this discovery piece - I hope wrdl becomes workable and popular. If a request or response blob is node addressable you can write simple maps the extract interesting properties. If the content is xml, you can extract them from the body as well. So on the server side, you can say 'username comes from (in xpath syntax) /request/header/authentication/user or /request/query/userid or wherever. This causes the set of names you want to extract (like 'username' or 'resource') to become the interface for interoperation and these little maps become mini-adapters. It'll only go so far in capability, but will help cover many situations. You'll also get into arguments about how fine grained to make the request and response. So what I'm thinking is downloading a 'template' of an HTTP request, with portions filled in (like the URL, etc.), and a separate 'interface def' provides names and pointers within that template. The 'interface def' could have 'username' (a mutually agreed upon set of names - probably from http concepts itself) and point to where that particular service expects the value to show up - sometimes people use HTTP auth, sometimes they use query terms, sometimes they use URIs, etc. Mike "on vacation sitting by the pool working through the glare" Dierken ----- Original Message ----- From: Paul Prescod <paul@...> To: S. Mike Dierken <mdierken@...> Sent: Tuesday, February 19, 2002 9:25 PM Subject: Re: [rest-discuss] REST made more concrete still > "S. Mike Dierken" wrote: > > > > Interesting... > > I've always wanted an xml representation of HTTP requests and responses... > > I'd avoid inheritence-through-containment (instance inheritence) initially - > > Don't follow. > > > I love the idea, but mutually exclusive options can pop up later. > > Don't follow. > > > --suggestion-- > > <purchaseOrder > > > <request method='GET'> > > <input name='itemtypes' type='integer' target='query' /> > > </request> > > <request method='POST' accepts="x-www-form-url-encoded" returns="ebxmlpo"> > > <input name='name' target='query' /> > > <input name='items' type='integer' target='query' /> > > </request> > > <request method='PUT' accepts='ebxmlpo cblpo'> > > </request> > > </purchaseOrder> > > I sort of understand this but don't understand any of your motivations. > For instance are you trying to make an XML equivalent to an HTML form? > That's quite different than what I'm after. In that the form is served > up at runtime but this thing is more about declaring things in advance > like a schema. > > Paul Prescod >
On Thursday 2002-02-21 at 08:40:51(+0000) Sean McGrath wrote:
> I recently gave a talk about the XPipe appoach to XML processing
> at the XML SIG of New York.
>
> The slides from the talk are available on http://xpipe.sourceforge.net at
> http://xpipe.sourceforge.net/BinaryStuff/xpipeny.ppt
>
Good stuff, thanks for sharing...
It strikes me that XPipe and REST are meant for each other.
Machine-to-machine REST is really about transformations on XML
documents.
Allan
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle http://www.intl-interfaces.com
adoyle@...
New (rough!) WRDL DTD. I'm just using a DTD because it is convenient. Eventually I will also provide schemas in various schema syntaxes once everything is firmed up. http://www.prescod.net/rest/wrdl.dtd Description of some of Meerkat's inputs in WRDL: http://www.prescod.net/rest/meerkat.wrdl WRDL spec with a few bug fixes and the link to the DTD and schema: http://www.prescod.net/rest/wrdl.html Paul Prescod
Very cool, Paul!
Does extension-method really need the "extension-" prefix? A simple "method"
name seems like it would convey the exact same information. Is HEAD an
extension method? It's defined in HTTP so I wouldn't think to call it that.
Do query elements always represent the parts of the URI after the question
mark? Even for POST? If so, that's why I was asking (in a previous message)
if there could be separate input elements (form? variable?) for form
variables that can be POSTed (using multipart/form-data) to a resource.
How is it possible to have query outputs? Or is that a typo in the DTD?
The content model for documentation and appinfo should be ANY so that we
could include structured content. Personally, though, I would prefer if
annotation's content model was ANY and there were no documentation or
appinfo elements. The distinction that XML Schema makes between human and
machine readable annotations seems entirely arbitrary to me. XML makes
content both human and machine readable at the same time!
It seems odd that representationType elements are contained by a
resourceTypes element.
You have some example representationType elements with match attributes. The
DTD says those should be called test.
I still think that the match attribute on reference elements should be
select. XSLT's match attribute defines a pattern that (usually) gets checked
as the processor recurses down the entire document. You could just as easily
extract the same information, albeit more efficiently, if you used normal
XPath expressions.
<representationType name="xslt" media-type="text/xsl"
match="/*[@xsl:version or @version]">
<reference name="includes" match="*/xsl:include/@href"
type="xsltResource"/>
<reference match="*/xsl:import/@href" type="xsltResource"/>
</representationType>
(The * is there because XSLT document elements can be either xsl:stylesheet
or xsl:transform.)
If you still want to scan the entire document you could always use an XPath
like "//foo".
A more realistic example for different representation types might be for the
different types of schemas that are out there:
<representationType name="xsd" media-type="application/xml"
test="xsd:schema">
<!-- ... -->
</representationType>
<representationType name="rng" media-type="application/xml" test="rng:*">
<!-- ... -->
</representationType>
<representationType name="sch" media-type="application/xml"
test="sch:schema">
<!-- ... -->
</representationType>
You say that WRDL doesn't care which representationType matches a
representation. Won't consumers of a WRDL-generated API want to know what
type of document was returned? Won't the WRDL-generated proxy want to know
so that it could validate the representation? It seems like things would be
easier all around if the first representationType that passed its XPath test
was the "winner".
Could you expound a little more on "the built-in support for navigation
through hyperlinks"? I don't follow that. How is that used in the API?
Thanks,
Jason
----- Original Message -----
From: Paul Prescod
To: rest-discuss@yahoogroups.com ; rael@...
Sent: Saturday, February 23, 2002 12:57 PM
Subject: [rest-discuss] Meerkat API in WRDL
New (rough!) WRDL DTD. I'm just using a DTD because it is convenient.
Eventually I will also provide schemas in various schema syntaxes once
everything is firmed up.
http://www.prescod.net/rest/wrdl.dtd
Description of some of Meerkat's inputs in WRDL:
http://www.prescod.net/rest/meerkat.wrdl
WRDL spec with a few bug fixes and the link to the DTD and schema:
http://www.prescod.net/rest/wrdl.html
Paul Prescod
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Jason Diamond wrote: > > Very cool, Paul! > > Does extension-method really need the "extension-" prefix? A simple "method" > name seems like it would convey the exact same information. Is HEAD an > extension method? It's defined in HTTP so I wouldn't think to call it that. Yeah, I haven't decided exactly what to do there. I don't want to confuse the DTD with the HTTP methods that don't have logical significance for a "web service." How about "other-method"? As this should be rarely used I don't think that the verbosity is a problem. > Do query elements always represent the parts of the URI after the question > mark? Yes. I think so. > ... Even for POST? If so, that's why I was asking (in a previous message) > if there could be separate input elements (form? variable?) for form > variables that can be POSTed (using multipart/form-data) to a resource. I see. On the one hand it seems like once I get into helping people to define the structure of the body I'm getting into a slippery slope. Next I'll be embedding schemas in WRDL. On the other hand I can see how it would be useful. I guess I'll add that. Should I call it <form-parameter>? > How is it possible to have query outputs? Or is that a typo in the DTD? Typo. > The content model for documentation and appinfo should be ANY so that we > could include structured content. Personally, though, I would prefer if > annotation's content model was ANY and there were no documentation or > appinfo elements. The distinction that XML Schema makes between human and > machine readable annotations seems entirely arbitrary to me. XML makes > content both human and machine readable at the same time! I'll think more about it. There is virtue in conforming to patterns set elsewhere...but I find it somewhat verbose myself. > It seems odd that representationType elements are contained by a > resourceTypes element. I guess I could call the top-level element "stuff". Or "wrdl". My thinking is that the goal is defining resource types and the representations are just a sort of property of the resources, like ports in WSDL. They aren't defined in the resources directly so they can be used in multiple places. > You have some example representationType elements with match attributes. The > DTD says those should be called test. True. Will fix. > I still think that the match attribute on reference elements should be > select. I see, you're thinking of the representationType as a template and using that as the "current node". I'm more thinking that we visit every node in the document and see if it matches any of the XPaths in any of the references. I presume that you usually will NOT care about proximity to the root so it should default to floating. > ... XSLT's match attribute defines a pattern that (usually) gets checked > as the processor recurses down the entire document. You could just as easily > extract the same information, albeit more efficiently, if you used normal > XPath expressions. I think the efficiency is the same because any smart processor could convert one form to the other. >... > If you still want to scan the entire document you could always use an XPath > like "//foo". I just feel like that will be the most common case so it should be the default. If you have any other arguments for select I'm open to them, though. I don't feel strongly about it. > A more realistic example for different representation types might be for the > different types of schemas that are out there: Good idea. > You say that WRDL doesn't care which representationType matches a > representation. Won't consumers of a WRDL-generated API want to know what > type of document was returned? That's why I wrote that bit about "This may change in the future.". I need to think about it more. What if a representation matches two representationTypes. Do I have to signal an error? Choose the first? Add priority attributes? > ... Won't the WRDL-generated proxy want to know > so that it could validate the representation? It seems like things would be > easier all around if the first representationType that passed its XPath test > was the "winner". Maybe that's simplest. XSLT throws an error. I'll have to think about it more. > Could you expound a little more on "the built-in support for navigation > through hyperlinks"? I don't follow that. How is that used in the API? "CustomerResource cust = por.references.customer()" What's happened there is that there was some XML that looked like <purchaseOrder> <customerURI href="http://...."/> or something like that. ... </purchaseOrder> Then there was a reference with the name "customer" that matched //customerURI/@href. And the referent was declared to be of type CustomerResource. So you navigated from the purchase order to the customer. And then you get a representation of the customer like this: DOMDocument cust = por.GET() Paul Prescod
Jason Diamond wrote: > >... > > It seems odd that representationType elements are contained by a > resourceTypes element. How about just "types". Paul Prescod
Hi. > I see. On the one hand it seems like once I get into helping people to > define the structure of the body I'm getting into a slippery slope. Next > I'll be embedding schemas in WRDL. On the other hand I can see how it > would be useful. I guess I'll add that. Should I call it > <form-parameter>? Don't add it for me. I was only asking out of curiosity. If you restrict the scope of WRDL to XML-based representations (which multi-part/form-data is not) then I think it will be a much simpler and manageable spec. > > ... XSLT's match attribute defines a pattern that (usually) gets checked > > as the processor recurses down the entire document. You could just as easily > > extract the same information, albeit more efficiently, if you used normal > > XPath expressions. > > I think the efficiency is the same because any smart processor could > convert one form to the other. The processor would have to have detailed knowledge of the representation type. How would it know to only look at the children of the document element for xsl:include elements (that's the only place they can appear)? Hmm. Now that I think about it, patterns like /*/xsl:include could easily be optimized. I'm with you now. > >... > > If you still want to scan the entire document you could always use an XPath > > like "//foo". > > I just feel like that will be the most common case so it should be the > default. If you have any other arguments for select I'm open to them, > though. I don't feel strongly about it. I take back what I said. I was trying to optimize prematurely. Using match is somewhat akin to XSLT's keys. Hmm. Now that I've said that, I think I really like it. In XSLT, you specify what pattern you should look for (with a match attribute) and what value (relative to each node that matched the pattern) is the "key" or name for that node (with a use attribute). By following that example, WRDL can have named sets of references where the names are stored in the representations so they don't have to be hardcoded in the WRDL file! > > ... Won't the WRDL-generated proxy want to know > > so that it could validate the representation? It seems like things would be > > easier all around if the first representationType that passed its XPath test > > was the "winner". > > Maybe that's simplest. XSLT throws an error. I'll have to think about it > more. Are you talking about what XSLT does when matching templates? The spec says that a processor can throw an error when multiple templates match a pattern with the same priority _or_ it can choose the last template that appears in the stylesheet. I think it'd be simplest to treat testing for multiple representation types like a xsl:choose/xsl:when. The first test that results in true gets evaluated. > > Could you expound a little more on "the built-in support for navigation > > through hyperlinks"? I don't follow that. How is that used in the API? > > "CustomerResource cust = por.references.customer()" > > What's happened there is that there was some XML that looked like > <purchaseOrder> > <customerURI href="http://...."/> or something like that. > ... > </purchaseOrder> > > Then there was a reference with the name "customer" that matched > //customerURI/@href. And the referent was declared to be of type > CustomerResource. So you navigated from the purchase order to the > customer. And then you get a representation of the customer like this: > > DOMDocument cust = por.GET() So references are always URIs? Now I get it! > > It seems odd that representationType elements are contained by a > > resourceTypes element. > > How about just "types". I like it. And if you decide to put your elements in a namespace then it could be wrdl:types. Thanks, Jason
Is it appropriate to send attachments to the list? If anybody's interested in seeing the code, just let me know. ----- Original Message ----- From: "Paul Prescod" <paul@...> To: "Jason Diamond" <jason@...> Sent: Sunday, February 24, 2002 4:22 AM Subject: Re: WRDL > I'll respond now and then we can forward the messages to the mailing > list if we decide to. > > Jason Diamond wrote: > > > > Hi, Paul. > > > > I'm sick so am stuck at home and thought I would take advantage of it and do > > some experimentation. I don't really start to understand something until I > > use it. And REST/WRDL is hard enough without something concrete for me to > > play with as it is. :-) > > > > I've hacked together some XSLT/C# to generate a proxy class from your > > meerkat.wrdl file. It doesn't do much yet but that will change. > > Great stuff! I don't suppose you'll buy my suggestion that you should > "regress" to Java for portability and popularity reasons. ;) Either way, > I'm very happy because I would want to see C# support eventually anyhow. > > > I don't know if you have the .NET Framework installed (or even if you run > > Windows) but if you do, you should be able to type nmake in the directory > > containing my attached files and it will generate the proxy (meerkat.cs), > > build a test executable that fetches the Eclectic XML posts for the past > > seven days, and then saves it to a file called response.xml. All the > > generated files are included just in case you can't build them. > > Seems logical to me. One virtue of the .NET framework is that it has > XPath built in. XPath would have to be an extra dependency in Java. But > you haven't gotten to the references bit yet... > > > >From an RPC point-of-view, I don't think that meerkat makes a really usable > > API. There's too many (mutually exclusive) parameters for the same endpoint. > > I suspect that it doesn't make a good REST service, either. Shouldn't each > > channel, mob, and profile have its own URI? > > Yes. At this point I'm just happy that there is any openly available > XML/URI/HTTP-based service, whether ot not it is well designed from a > REST point of view. Google had an XML service for a while but it's gone. > > One could also imagine talking to HTML, as it is possible to make a DOM > from HTML and in most toolkits it should be possible to search it with > an XPath. The tricky bit of course is distinguishing one href from > another. It looks to extract referenced links in Google it is relatively > safe to use this pattern: > > "<p><a href=" > > which would be an XPath like "the first node children of paragraphs > where the node is an 'a'" (as opposed to the first "a" children of > paragraphs). Some of Google's other href's have class attributes. > And of course the cache link always has the text "Cached". > > It would be really great to have a read-write web service but there are > reasons that people don't tend to open up read-write access to websites. > ;) I've been toying with the idea of a UDDI bridge. > > Looking at your home page you might consider REST services for POP3 or > DNS. Those would be really cool. POP3 especially, because there are many > people with a reverence for the mail system so over a few years I'd like > to recreate much of its infrastructure based on HTTP, not because I > really think HTTP will compete with SMTP/IMAP/POP commercially > (installed base is too large) but to show people who are building apps > that are "mail-like" that they can use HTTP. > > > By the way, the correct query name for the "flavor" parameter is "_fl". And > > shouldn't the value of that parameter be fixed to "xml" somehow so that we > > can always do XPath on the response? > > Good point. And yes. > > > Take a look at meerkat.cs. That's the file that was generated. The first > > thing that jumps out at me is that the query parameter names are extremely > > terse. Would an optional parameter to specify a more programmer-friendly > > name be appropriate? > > I considered that and then thought: "maybe we should just push this back > on service developers to make nicer URI parameter names." After all, _fl > isn't very friendly even in your browser bar. Still, your next point is > very important: > > > ... It might be more important for header inputs since > > those tend to have dashes in them and most programming languages don't > > support those in identifiers. > > Agreed. > > "friendly-name"? "api-name"? If api-names were required to be unique > across queries and headers then we could unify the queries and header > namespaces for languages where parameters matter (e.g. those with > optional arguments). > > Don't forget to provide an API for extra query and header parameters. > > > Do you have any ideas on how optional parameters could be handled for > > languages that don't support them (like C#)? I hacked in some checks for > > null and 0 but don't like that because with that we can never pass in null > > or 0 to a resource that allows those values. > > Yeah, 0 is a problem. > > > ... I can think of three other ways > > to get around this but they all involve a lot of work: > > > > - Add a boolean parameter for each optional parameter to the method > > signature. If false, the optional parameter is ignored. > > > > - Generate lots of overloads. (This doesn't seem usable, though.) > > > > - Generate some sort of "parameters" class. Like MeerkatGetInputs, perhaps. > > It could have getters, setters, and clearers for each parameter. It would > > keep track of which parameters were never set internally. An instance of > > that class would be passed into the method instead of all the parameters > > individually. > > > > These are all just implementation details and don't really affect WRDL but > > it's something to think about. > > The parameters class is not unlike the sort of message you have to build > to use .NET My services. As web services move more and more to > "messaging" style it will be pretty common. MeerkatPOSTInputs could also > hold the DOM for any XML inputs to POST or PUT. i.e. one property per > parameter/header and one for the bound XML document. > > <aside>There is a fundamental disconnect between languages that only > support ordered-parameter arguments and good networking "best practice" > where extensibility is paramount. RPC is bad enough architecturally > without making it even worse by making parameter orders significant as > SOAP and (especially!) XML-RPC services tend to. I don't really > understand why in this day and age, optional and named parameters are > considered a fancy language feature. IIRC, Ada had them in the > 80s.</aside> > > > I'm not doing anything with representations yet. I'm just returning a > > generic WebResponse. But I want to be able to extract the links from the > > response. In your meerkat.wrdl file, you have two references with the same > > names and patterns. Is that a mistake? And should they not have the leading > > slash? > > Right. Meerkat has a link and a url. I have a typo in the meerkate.wrdl. > > DTD is here: > > * http://www.oreillynet.com/meerkat/dtd/meerkat_xml_flavour.dtd > > You might as well send me Meerkat.wsdl when you've observed it to work. > ;) > > > This is what I suspect the reference for story links should look like: > > > > <reference name="story" match="story/link" resourceType="ANY" /> > > > > The problem is that there are multiple stories and, hence, multiple links. > > So I can return a collection of resources. But what if I wanted to extract a > > specific one? This is where I think my XSLT key analogy would be perfect. > > > > <reference name="story" match="story/link" use="preceding-sibling::title" > > resourceType="ANY" /> > > Now I get it. Excellent idea! You could even index the same URI by > multiple keys. It's a little bit more complicated than what I was > thinking but much more useful. > > BTW, I'd spell that "../title" The abbreviated form is a little bit more > readable and it's a little bit less dependent on ordering (in case the > DTD ever changes). > > >... > > Regarding representations: Generating code like your sample API might be > > difficult for type-safe languages. If multiple representationTypes can be > > returned from a method then we might be forced to have those methods return > > something like System.Object (C#) or java.lang.Object and have the > > programmers cast down to whatever they think the correct representation is. > > I hate that. > > I think your idea of specifying the representation type to get in the > method name is a good one. It's just a way of triggering the content > negotiation in a static-type-safe way. > > > Why exactly would you want to allow methods to return different types of > > representations anyways? The programmer probably knows exactly what type he > > wants, wouldn't you think? > > Which programmer are you talking about? The web service provider might > allow fetching data in RSS 0.9 versus RSS 1.0 versus XMLNews. Or they > might have a a biztalk PO versus an ebxml versus rosettanet. It is > probably useful for the semantic web not to give them all unique URIs > otherwise you need to somehow broadcast that they are "really" the same > thing (which you can do with RDF but still...). > > > ... I suppose that we could generate a separate > > method for each representation type that was possible. So the meerkat proxy > > might have GetXML, GetRSS, etc. We would just combine the method name with > > the representationType name. > > Yes, I like that idea. > > > OK, I think I've babbled for long enough. I hope you find these comments > > helpful. > > Very helpful! I appreciate all of your effort. The fact that our > instincts line up so well reinforces my believe that WRDL is pretty > logical -- it's like we're discovering it instead of creating it. > Basically it is just a concrete syntax for statically type declaring > bits of the existing web architecture. > > Paul Prescod >
Jason Diamond wrote:
>
>...
>
> Don't add it for me. I was only asking out of curiosity. If you restrict the
> scope of WRDL to XML-based representations (which multi-part/form-data is
> not) then I think it will be a much simpler and manageable spec.
Well there are only two "standardized" representations (other than
HTML), XML and form parameters so I think it may make sense to support
them both directly. I am thinking about a simple templating feature for
XML:
<foo bar="{height}">
<width>{width}</width>
</foo>
It probably doesn't make much sense to go beyond that.
>...
> Hmm. Now that I've said that, I think I really like it. In XSLT, you specify
> what pattern you should look for (with a match attribute) and what value
> (relative to each node that matched the pattern) is the "key" or name for
> that node (with a use attribute).
>
> By following that example, WRDL can have named sets of references where the
> names are stored in the representations so they don't have to be hardcoded
> in the WRDL file!
I didn't understand this the first time I read it, but I do now. You
want to allow the WRDL file to set up hashtables for the programmer
where the keys are generated from the XML (e.g. "title" elements for
Meerkat topics) and the values are references to resource objects. Good
idea!
I think I will also rename it to reference-type, because really we're
classifying references. Make sense to you?
<!ELEMENT reference-type (documentation?, appinfo?)>
<!ATTLIST reference-type name %Name; #REQUIRED
match %XPath; #REQUIRED
use %XPath; #REQUIRED
resourceType %QName; #REQUIRED>
>...
> Are you talking about what XSLT does when matching templates? The spec says
> that a processor can throw an error when multiple templates match a pattern
> with the same priority _or_ it can choose the last template that appears in
> the stylesheet.
>
> I think it'd be simplest to treat testing for multiple representation types
> like a xsl:choose/xsl:when. The first test that results in true gets
> evaluated.
In our other (offlist) discussion we agreed that the client should
explicitly ask for a representation. So I don't think we have to answer
this question. The test is almost superfluous...sanity checking at best,
cruft at worst. Originally the model was you'd get something back and
figure out what it was. But it's better to say what you want and be
confident you're going to get it.
Paul Prescod
Jason Diamond wrote:
>
> Is it appropriate to send attachments to the list?
Probably not.
> ... If anybody's interested in seeing the code, just let me know.
I think these bits are especially interesting. First there is a test
file. Second is a generated proxy. Obviously still only
preliminary...Jason hasn't done the references feature yet which is a
big one. And we've discussed pretty big API changes. Still cool to see
something runnable coming together.
Test file:
using System;
using System.IO;
using System.Net;
public class Test
{
static void Main()
{
meerkat m = new meerkat("http://meerkat.oreillynet.com/");
WebResponse webResponse = m.GET(
"xml", // flavor
null, // search for
null, // search what
555, // channel
"7DAY", // time period
0, // profile
0, // mob
0 // id
);
WriteResponse(webResponse, Console.Out);
}
}
API generated from (a bug-fixed version of) meerkat.wrdl with Jason's
XSLT:
using System;
using System.Net;
public class meerkat : WrdlResource
{
public meerkat(string uri) : base(uri)
{
}
public WebResponse GET(
string _fl,
string s,
string sw,
int c,
string t,
int p,
int m,
int i)
{
if (_fl != null) AddQuery("_fl", _fl);
if (s != null) AddQuery("s", s);
if (sw != null) AddQuery("sw", sw);
if (c != 0) AddQuery("c", c);
if (t != null) AddQuery("t", t);
if (p != 0) AddQuery("p", p);
if (m != 0) AddQuery("m", m);
if (i != 0) AddQuery("i", i);
Console.Error.WriteLine(Uri);
WebRequest webRequest = WebRequest.Create(Uri);
WebResponse webResponse = webRequest.GetResponse();
return webResponse;
}
}
public class WebPage : WrdlResource
{
public WebPage(string uri) : base(uri)
{
}
}
> > Great stuff! I don't suppose you'll buy my suggestion that you should > > "regress" to Java for portability and popularity reasons. ;) Either way, > > I'm very happy because I would want to see C# support eventually anyhow. If nobody steps up to do a Java version than I coud take a crack at that, too. I only chose C# since it comes with XPath support out of the box. I need an excuse to learn Jaxen, anyways. > > It would be really great to have a read-write web service but there are > > reasons that people don't tend to open up read-write access to websites. > > ;) I've been toying with the idea of a UDDI bridge. I'm working on one and will probably need help from the list to make sure I get it right. Think Radio meets REST. :-) > > I considered that and then thought: "maybe we should just push this back > > on service developers to make nicer URI parameter names." After all, _fl > > isn't very friendly even in your browser bar. Still, your next point is > > very important: > > > > > ... It might be more important for header inputs since > > > those tend to have dashes in them and most programming languages don't > > > support those in identifiers. > > > > Agreed. > > > > "friendly-name"? "api-name"? If api-names were required to be unique > > across queries and headers then we could unify the queries and header > > namespaces for languages where parameters matter (e.g. those with > > optional arguments). I don't know. I could go either way on this. It seems like an implementation detail that the spec shouldn't care about. Proxy generators could automatically transform names so that they're legal. Or developers could sneak in some qualified attributes on those elements with the names they prefer. Or they could support some sort of configuration that lets you rename inputs without modifying the WRDL. > > Don't forget to provide an API for extra query and header parameters. Good point. This is a good argument for the "Inputs" class we talk about below. > > The parameters class is not unlike the sort of message you have to build > > to use .NET My services. As web services move more and more to > > "messaging" style it will be pretty common. MeerkatPOSTInputs could also > > hold the DOM for any XML inputs to POST or PUT. i.e. one property per > > parameter/header and one for the bound XML document. > > > > <aside>There is a fundamental disconnect between languages that only > > support ordered-parameter arguments and good networking "best practice" > > where extensibility is paramount. RPC is bad enough architecturally > > without making it even worse by making parameter orders significant as > > SOAP and (especially!) XML-RPC services tend to. I don't really > > understand why in this day and age, optional and named parameters are > > considered a fancy language feature. IIRC, Ada had them in the > > 80s.</aside> Well, VB has them but you're not going to make me code in that, are you? ;-) It seems that the "Inputs" class is the best and most flexible approach. Not only does it support optional parameters which you can set in any order but you could also add arbitrary queries or headers. > > > <reference name="story" match="story/link" > use="preceding-sibling::title" > > > resourceType="ANY" /> > > > > Now I get it. Excellent idea! You could even index the same URI by > > multiple keys. It's a little bit more complicated than what I was > > thinking but much more useful. It does seem a tiny bit more complicated but I think a lot of flexibility is gained from it. With the match attribute, we'll probably have to process the entire tree anyways. The value grabbed using the use attribute just makes it easier for us to actually use that data once it's extracted. > > BTW, I'd spell that "../title" The abbreviated form is a little bit more > > readable and it's a little bit less dependent on ordering (in case the > > DTD ever changes). Good point. > > > Why exactly would you want to allow methods to return different types of > > > representations anyways? The programmer probably knows exactly what type > he > > > wants, wouldn't you think? > > > > Which programmer are you talking about? The web service provider might > > allow fetching data in RSS 0.9 versus RSS 1.0 versus XMLNews. Or they > > might have a a biztalk PO versus an ebxml versus rosettanet. It is > > probably useful for the semantic web not to give them all unique URIs > > otherwise you need to somehow broadcast that they are "really" the same > > thing (which you can do with RDF but still...). OK, I see what you're saying. These examples would surely be restricted to one representationType per representation, no? Would there be any cases where a single representation could match more than one? > > Very helpful! I appreciate all of your effort. The fact that our > > instincts line up so well reinforces my believe that WRDL is pretty > > logical -- it's like we're discovering it instead of creating it. > > Basically it is just a concrete syntax for statically type declaring > > bits of the existing web architecture. I was throwing around some ideas privately with Mark Baker a few months ago and some of them were very similar to yours. I was calling it HTTP-IDL (which I realize now is way to RPC-ish) but it was nowhere near as elegant as WRDL. Jason
> Well there are only two "standardized" representations (other than
> HTML), XML and form parameters so I think it may make sense to support
> them both directly. I am thinking about a simple templating feature for
> XML:
>
> <foo bar="{height}">
> <width>{width}</width>
> </foo>
>
> It probably doesn't make much sense to go beyond that.
This almost looks like XForms. They have an element that lets you specify
model instance data where elements get replaced with the actual form values
when the form gets submitted.
Would these be different kinds of inputs? You can certainly still have query
and header inputs. Maybe you don't need the {variables} in your template if
you put XPath expressions on the elements (variable? parameter?) that
specify these.
Would you be able to specify an output template as well?
I think this is really cool but I'm not sure if it's really necessary for
WRDL. At least for an initial release. By the way, do you have a list of
goals or requirements for the first release of WRDL? We certainly don't want
to succumb to feature creep or we might have to change the R to an S. ;-)
> I think I will also rename it to reference-type, because really we're
> classifying references. Make sense to you?
Sounds good. Are you switching to lisp-style identifiers instead of
camelCase? I don't care which one you use but they should probably be
consistent.
> <!ELEMENT reference-type (documentation?, appinfo?)>
>
> <!ATTLIST reference-type name %Name; #REQUIRED
> match %XPath; #REQUIRED
> use %XPath; #REQUIRED
> resourceType %QName; #REQUIRED>
Maybe the use attribute should be optional. I can imagine some resources
containing a list of references with no obvious key. And perhaps some
applications won't care about the keys.
Will the spec specify any sort of rules for compliant APIs? The question I
have now is this: should the collection of references maintain the same
order they were found in even if keyed? If so, we'd have to use a fancier
data structure than a Hashtable or Map since those usually destroy the
ordering. I would tend to think that the answer to this would be use but I
don't have any particular use cases to justify it.
Jason
This message is dedicated to the Canadian hockey teams. ;)
Jason Diamond wrote:
>
> > Well there are only two "standardized" representations (other than
> > HTML), XML and form parameters so I think it may make sense to support
> > them both directly. I am thinking about a simple templating feature for
> > XML:
> >
> > <foo bar="{height}">
> > <width>{width}</width>
> > </foo>
> >
> > It probably doesn't make much sense to go beyond that.
>
> This almost looks like XForms. They have an element that lets you specify
> model instance data where elements get replaced with the actual form values
> when the form gets submitted.
I could be wrong but I think their model is more complex and requires
sort of modifications to be made to the instance data. I was thinking
more about a bunch of named replacement parameters. Still it might make
sense to make reference to XForms somehow as an optional extra feature.
I'll delay the addition of both features to judge the need more.
> Would these be different kinds of inputs? You can certainly still have query
> and header inputs. Maybe you don't need the {variables} in your template if
> you put XPath expressions on the elements (variable? parameter?) that
> specify these.
Don't follow what you would do to put a "foo" attribute with value
extracted from a user-supplied variable called "bar" in the element
"blah" using XPaths. Here's what it looks like in my proposed model:
<blah foo="{bar}"/>
The thing that worries me is how to generate repeating structures.
Examplotron has an eg:occurs="+" attribute that says that a particular
structure is repeatable. But how does that translate into an API, as a
list of hashtables for that structure? I'll probably add this feature if
either a) I decide that the fixed-structure case is the common one,
rather than a repeating-structure case or b) I can find a clean, simple
way to handle the repeating structure case both in WRDL and the API.
> Would you be able to specify an output template as well?
It sort of makes sense. It might be a cheap, simple way of doing parsing
and data binding to hashtables or lists of hashtables. Maybe the
template parsing/serialization language is a different but related
language.
> I think this is really cool but I'm not sure if it's really necessary for
> WRDL. At least for an initial release. By the way, do you have a list of
> goals or requirements for the first release of WRDL? We certainly don't want
> to succumb to feature creep or we might have to change the R to an S. ;-)
The goal is to make it easy to statically pre-declare the structure of
XML and XHTML-based web services
> > I think I will also rename it to reference-type, because really we're
> > classifying references. Make sense to you?
>
> Sounds good. Are you switching to lisp-style identifiers instead of
> camelCase? I don't care which one you use but they should probably be
> consistent.
Good point. I guess camelCase is a little more compatible with non-lisp
languages.
> > <!ELEMENT reference-type (documentation?, appinfo?)>
> >
> > <!ATTLIST reference-type name %Name; #REQUIRED
> > match %XPath; #REQUIRED
> > use %XPath; #REQUIRED
> > resourceType %QName; #REQUIRED>
>
> Maybe the use attribute should be optional. I can imagine some resources
> containing a list of references with no obvious key. And perhaps some
> applications won't care about the keys.
True enough.
> Will the spec specify any sort of rules for compliant APIs? The question I
> have now is this: should the collection of references maintain the same
> order they were found in even if keyed? If so, we'd have to use a fancier
> data structure than a Hashtable or Map since those usually destroy the
> ordering. I would tend to think that the answer to this would be use but I
> don't have any particular use cases to justify it.
There should be some way to order them by position but it may not
require a special data structure. If you put a "documentPosition"
attribute on each reference/resource object then the application could
sort on that.
Paul Prescod
1. Namespace attribute added.
2. extension-method -> otherMethod, media-type to mediaType
3. content models that had "annotation" before now have just
"documentation" and "appinfo". "documentation" is a subset of HTML (real
HTML probably eventually)
4.representationType elements now have a "namespace" attribute and
"schema" sub-element. They have experimentally lost the "test"
attribute.
5. referenceType elements now have a "key" attribute which is like
xsl:key/@use in XSLT.
Diff:
<!ENTITY % Name "NMTOKEN">
<!ELEMENT types (resourceType|representationType)*>
+<!ATTLIST types xmlns CDATA #FIXED "http://www.prescod.net/rest/wrdl">
-<!ENTITY % methods "(GET?,POST?,PUT?,DELETE?,extension-method?)">
+<!ENTITY % methods "(GET?,POST?,PUT?,DELETE?, otherMethod?)">
<!ELEMENT GET (input?)>
<!ELEMENT POST (input?, output?)>
<!ATTLIST POST createdResourceType %QName; #IMPLIED>
<!ELEMENT PUT (input?, output?)>
<!ELEMENT DELETE (input?, output?)>
-<!ELEMENT extension-method (input?, output?)>
-<!ATTLIST extension-method name %Name; #REQUIRED
+<!ELEMENT otherMethod (input?, output?)>
+<!ATTLIST otherMethod name %Name; #REQUIRED
createdResourceType %QName; #IMPLIED>
<!ELEMENT input (query*, header*)>
<!ATTLIST input representations %QNames; #IMPLIED>
-<!ELEMENT query (annotation?)>
+<!ELEMENT query (documentation?, appinfo?)>
<!ATTLIST query name %Name; #IMPLIED
type %QName; #IMPLIED
default CDATA #IMPLIED
use (optional|prohibited|required) "optional">
-<!ELEMENT header (annotation?)>
+<!ELEMENT header (documentation?, appinfo?)>
<!ATTLIST header name %Name; #IMPLIED
type %QName; #IMPLIED
default CDATA #IMPLIED
use (optional|prohibited|required) "optional">
-<!ELEMENT representationType (reference*)>
+<!ELEMENT representationType (reference|schema)*>
<!ATTLIST representationType
name %Name; #IMPLIED
- media-type CDATA #IMPLIED
- test CDATA #IMPLIED>
+ namespace CDATA #IMPLIED
+ mediaType CDATA #IMPLIED>
-<!ELEMENT reference (annotation?)>
+<!ELEMENT referenceType (documentation?, appinfo?)>
-<!ATTLIST reference name %Name; #REQUIRED
- match CDATA #REQUIRED
+<!ATTLIST referenceType name %Name; #REQUIRED
+ match %XPath; #REQUIRED
+ key %XPath; #IMPLIED
resourceType %QName; #REQUIRED>
-<!ELEMENT annotation (appinfo|documentation)+>
-<!ELEMENT documentation (#PCDATA)>
-<!ELEMENT appinfo (#PCDATA)>
+<!ELEMENT documentation (#PCDATA|p|b|a)>
+<!-- in the future, just refer to HTML -->
+<!ELEMENT appinfo (ANY)>
+<!ELEMENT p (#PCDATA|b|a)>
+<!ELEMENT b (#PCDATA|a)>
+<!ELEMENT a (#PCDATA|b)>
+<!ATTLIST a href CDATA #REQUIRED>
Just noticed this in The Dissertation: http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm "The interaction method of sending representations of resources to consuming components has some parallels with event-based integration (EBI) styles. The key difference is that EBI styles are push-based. The component containing the state (equivalent to an origin server in REST) issues an event whenever the state changes, whether or not any component is actually interested in or listening for such an event. In the REST style, consuming components usually pull representations. Although this is less efficient when viewed as a single client wishing to monitor a single resource, the scale of the Web makes an unregulated push model infeasible." The part with 'whether or not any component is actually interested in or listening' would seem to be dealt with through subscriptions - which might imply that a regulated push model might be feasible.
> > * ?-parameters are not opaque. You're saying that it's okay for the > client to try to understand tha part of the URI and fiddle with the part > after the ? mark. Is this true? I thought even the ?query parts of the URI were opaque. With a POST you can have a URI with ?query as well as a body composed of name=value pairs - with overlapping names between the URI and body. Perhaps I'm just confused whether the 'resource' is identified ONLY by the uri 'path' or if it identified by the path+query. (and in html forms you can't specify whether some inputs are inserted into the uri or into the body) Mike "margarita anyone?" Dierken
"S. Mike Dierken" wrote: > > > > > * ?-parameters are not opaque. You're saying that it's okay for the > > client to try to understand tha part of the URI and fiddle with the part > > after the ? mark. > Is this true? > I thought even the ?query parts of the URI were opaque. Well they aren't opaque to the client, because the client had to generate them (e.g. an HTML form). And they aren't opaque to the servier, because the server has to interpret them. They probably should be opaque to most intermediaries. > ... With a POST you can > have a URI with ?query as well as a body composed of name=value pairs - with > overlapping names between the URI and body. The ones in the body are opaque to HTTP implementations by virtue of the fact that they are in the body. An HTTP implementation shouldn't be any more interested in the body than if it was PDF. IMHO. > Perhaps I'm just confused whether the 'resource' is identified ONLY by the > uri 'path' or if it identified by the path+query. (and in html forms you > can't specify whether some inputs are inserted into the uri or into the > body) The resource is identified by whatever goes after the method name. Paul Prescod
"S. Mike Dierken" wrote: > >... > > The part with 'whether or not any component is actually interested in or > listening' would seem to be dealt with through subscriptions - which might > imply that a regulated push model might be feasible. I agree. In fact I think it *is* feasible, until proven otherwise. ;) Paul Prescod
I have been thinking about the relationship between representation types and resource types. I believe that a resource type should entirely own a representation type. One shouldn't think of RSS as a representation, one should think of RSS_SiteSummary as a representation *of* the SiteSummary resource type. And therefore RSS_SiteSummary should be a sub-element of SiteSummary, not an independent element. Rationale: The primary purpose of representation types is to extract links for the resource type. It doesn't make sense to do this in the abstract. A particular representation needs to extract its links for a particular resource type. If the representation type is "purchase order" and the references it is expecting are "acceptance_URI, customer_URI and cancellation_URI" then the WRDL representation type needs to have exactly those reference types...like a Java implementation of an interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as a representation of another resource. In that context it will have different reference types so it will be for all intents and purposes a new representation. Paul Prescod
Does this still support re-using a representation between different resource types? I may have have a "folder" resources that I want represented with rss, or cdf voxml, or html or something else. I may have "bookmarks" resources that I want represented as rss, cdf, html, voxml, or something else. I may have have "news" resources that I want represented with rss, or cdf voxml, or html or something else. I may have "weblog" resources that I want represented as rss, cdf, html, voxml, or something else. ----- Original Message ----- From: "Paul Prescod" <paul@...> To: "Jason Diamond" <jason@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, February 25, 2002 5:54 PM Subject: [rest-discuss] WRDL change > I have been thinking about the relationship between representation types > and resource types. I believe that a resource type should entirely own a > representation type. One shouldn't think of RSS as a representation, one > should think of RSS_SiteSummary as a representation *of* the SiteSummary > resource type. And therefore RSS_SiteSummary should be a sub-element of > SiteSummary, not an independent element. > > Rationale: The primary purpose of representation types is to extract > links for the resource type. It doesn't make sense to do this in the > abstract. A particular representation needs to extract its links for a > particular resource type. If the representation type is "purchase order" > and the references it is expecting are "acceptance_URI, customer_URI and > cancellation_URI" then the WRDL representation type needs to have > exactly those reference types...like a Java implementation of an > interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as > a representation of another resource. In that context it will have > different reference types so it will be for all intents and purposes a > new representation. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
"S. Mike Dierken" wrote: > > Does this still support re-using a representation between different resource > types? > > I may have have a "folder" resources that I want represented with rss, or > cdf voxml, or html or something else. > I may have "bookmarks" resources that I want represented as rss, cdf, html, > voxml, or something else. > I may have have "news" resources that I want represented with rss, or cdf > voxml, or html or something else. > I may have "weblog" resources that I want represented as rss, cdf, html, > voxml, or something else. My argument is that rss_as_represntation_for_weblog is a different representation than rss_as_representation_for_news. Of course it is the same content-type. But in WRDL representations are more than content types. They also extract links (called "references") in the manner "expected" by the resource type. If your news and weblog resources have all of the same logical links to all of the same other types then they are probably actually the same resource type (or have some subtyping relationship which WRDL does not handle right now). Paul Prescod
I haven't done the representsations change I discussed before yet, but I
have got a preliminary WRDL implementation in Python[1]. It implements
enough of WRDL to talk to babelfish and Meerkat. Unfortunately there are
very few public, read/write, REST-based, XML-based web services so I
haven't bothered with PUT and DELETE yet. Input and output type checking
is also unimplemented. The code just trusts you.
One neat thing that IS implemented is input argument (paramter or
header) renaming and defaulting. This means that the programmer's API
can be much cleaner and easier to read than the stuff going across the
wire. The WRDL file does the translation from "language=en_es" to
"&l=en_es". Here's some sample Python code:
def main(url):
wrdl = Wrdl("meerkat.wrdl")
# bind a resource type to a URI
r = wrdl.newResource("meerkat",
"http://www.oreillynet.com/meerkat/")
# now GET that resource...any representation
res = r.GET_meerkat_xml_flavour( channel=555,
timePeriod="7DAY", search="Prescod")
# alternately, GET a particular representation
# (in this case "meerkat_xml_flavour")
res = r.GET_meerkat_xml_flavour( channel=555,
timePeriod="7DAY", search="Prescod")
text = res.body() # get resource body
assert text.find("Prescod")>0 # vanity assertion
# get a list of references (XML or HTML hyperlinks)
links = res.references("link")
assert len(links)>1 # sanity check
# download representation of first link
newres = links[0].GET()
# get the resource body for that link
text = newres.body()
assert text.find("Prescod")>0 #vanity assertion
wrdl = Wrdl("babelfish.wrdl")
s = wrdl.newResource("babelfish",
"http://babelfish.altavista.com/tr")
# do a POST
res = s.POST(text="Hello world", languages="en_es")
assert res.body().find("Hola")>0
# more specific way of POSTing:
res = s.POST_babelFormData_RETURNING_html(
text="Hello world", languages="en_es")
On the wire:
GET /meerkat/?_fl=xml&t=7DAY&c=555&s=Prescod HTTP/1.1\r\n'
Host: www.oreillynet.com\r\n'
Accept-Encoding: identity\r\n'
Accept: text/xml\r\n'
Content-type: */*\r\n'
\r\n'
GET /meerkat/?_fl=xml&t=7DAY&c=555&s=Prescod HTTP/1.1\r\n'
Host: www.oreillynet.com\r\n'
Accept-Encoding: identity\r\n'
Accept: text/xml\r\n'
Content-type: */*\r\n'
\r\n'
GET /archives/xml-dev/200202/msg01225.html HTTP/1.1\r\n'
Host: lists.xml.org\r\n'
Accept-Encoding: identity\r\n'
Accept: */*\r\n'
Content-type: */*\r\n'
\r\n'
POST /tr HTTP/1.1\r\n'
Host: babelfish.altavista.com\r\n'
Accept-Encoding: identity\r\n'
Content-Length: 49\r\n'
Accept: text/html\r\n'
Content-type: application/x-www-form-urlencoded\r\n'
\r\n'
lp=en_es&tt=urltext&urltext=Hello+world&doit=done'
POST /tr HTTP/1.1\r\n'
Host: babelfish.altavista.com\r\n'
Accept-Encoding: identity\r\n'
Content-Length: 49\r\n'
Accept: text/html\r\n'
Content-type: application/x-www-form-urlencoded\r\n'
\r\n'
lp=en_es&tt=urltext&urltext=Hello+world&doit=done'
[1] http://www.prescod.net/rest/wrdl.html
On Tue, Feb 26, 2002 at 07:19:57AM -0800, Paul Prescod wrote: > # now GET that resource...any representation > res = r.GET_meerkat_xml_flavour( channel=555, > timePeriod="7DAY", search="Prescod") Is that intended to be r.GET(channel=...)? Looks very cool. If you want a public CVS repository for it, I'd suggest using the pyxml.sourceforge.net one. --amk
I think I understand what you're saying and it does make sense. It might actually simplify things, too. Would you just move the reference elements to the content of the output element? Jason ----- Original Message ----- From: "Paul Prescod" <paul@...> To: "Jason Diamond" <jason@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, February 25, 2002 5:54 PM Subject: [rest-discuss] WRDL change > I have been thinking about the relationship between representation types > and resource types. I believe that a resource type should entirely own a > representation type. One shouldn't think of RSS as a representation, one > should think of RSS_SiteSummary as a representation *of* the SiteSummary > resource type. And therefore RSS_SiteSummary should be a sub-element of > SiteSummary, not an independent element. > > Rationale: The primary purpose of representation types is to extract > links for the resource type. It doesn't make sense to do this in the > abstract. A particular representation needs to extract its links for a > particular resource type. If the representation type is "purchase order" > and the references it is expecting are "acceptance_URI, customer_URI and > cancellation_URI" then the WRDL representation type needs to have > exactly those reference types...like a Java implementation of an > interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as > a representation of another resource. In that context it will have > different reference types so it will be for all intents and purposes a > new representation. > > Paul Prescod > > Yahoo! Groups Sponsor > ADVERTISEMENT > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > >
----- Forwarded message from Mark Nottingham <mnot@...> ----- Date: Mon, 25 Feb 2002 09:58:54 -0800 From: Mark Nottingham <mnot@...> To: Web Intermediaries List <webi@...> Subject: [Internet-Drafts@...: I-D ACTION:draft-nottingham-webi-warm-00.txt] User-Agent: Mutt/1.3.23i I'll reiterate the abstract; this is a straw-man proposal, to get discussion going. Cheers, ----- Forwarded message from Internet-Drafts@... ----- Date: Mon, 25 Feb 2002 06:24:02 -0500 From: Internet-Drafts@... Reply-To: Internet-Drafts@... To: IETF-Announce: ; Subject: I-D ACTION:draft-nottingham-webi-warm-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Web Active Resource Monitoring Author(s) : M. Nottingham Filename : draft-nottingham-webi-warm-00.txt Pages : 13 Date : 22-Feb-02 WARM is a straw-man proposal for a solution to the RUP requirements of the WEBI WG which reuses the Web Architecture (and HTTP). In particular, it provides a mechanism for distributing cache invalidations from HTTP servers to clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-webi-warm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nottingham-webi-warm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@.... In the body type: "FILE /internet-drafts/draft-nottingham-webi-warm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- -- Mark Nottingham http://www.mnot.net/ ----- End forwarded message ----- -- Mark Nottingham http://www.mnot.net/
http://zdnet.com.com/2100-1105-845220.html ===== Jim Ancona jim@... jancona@...
Jason Diamond wrote:
>
> I think I understand what you're saying and it does make sense. It might
> actually simplify things, too. Would you just move the reference elements to
> the content of the output element?
Let's invent some terminology. There are reference slots, which are
abstract, like abstract methods in a programming language, and there are
reference implementations, which are concrete and have XPaths into a
particular XML or XHTML format. So the abstract slots should be
associated with the output element. And the concrete implementations
should be associated with the representations. I haven't spec'ed any of
this but I'm guessing:
<output>
<references> <!-- abstract references -->
<referenceType
name="images"
type="graphicResourceType"
keyed="false"/>
<referenceType name="po"
type="purchaseOrderResourceType"
keyed="true"/>
</references>
<representation name="ebxml_transaction_catalog">
<reference name="images" match="img/@href"/>
<reference name="purchase_orders" match="/ebxmlpo"
key="../@number"/>
</representation>
</output>
Paul Prescod
On Tue, Feb 26, 2002 at 10:08:28AM -0800, Jim Ancona wrote: > http://zdnet.com.com/2100-1105-845220.html Hmph. The technical details of this are a bit over my head, but it's interesting to see one of the inventors of SOAP saying that Among the problems with HTTP, ... is the fact that it is a Remote Procedure Call (RPC) protocol .... This works for small transactions asking for Web pages, but when Web services start running transactions that take some time to complete over the protocol, the model fails. So has he now decided that SOAP was a bad idea too? If so, he doesn't say it. Also interesting: Microsoft has some ideas (on how to break the independence on HTTP)... Hmm, was Bob Cringely right (or close) when he predicted "The Death of TCP/IP?" http://www.pbs.org/cringely/pulpit/pulpit20010802.html Ah, but [Box again]: IBM has some ideas, and others have ideas. We'll see," he said. But, he added, "if one vendor does it on their own, it will simply not be worth the trouble." Of course not. Especially when it's a tiny, powerless vendor like Microsoft. Is it paranoid to smell a hidden agenda here? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Andrew Kuchling wrote: > > On Tue, Feb 26, 2002 at 07:19:57AM -0800, Paul Prescod wrote: > > # now GET that resource...any representation > > res = r.GET_meerkat_xml_flavour( channel=555, > > timePeriod="7DAY", search="Prescod") > > Is that intended to be r.GET(channel=...)? Yeah, I'll fix that. > Looks very cool. If you want a public CVS repository for it, I'd > suggest using the pyxml.sourceforge.net one. I'll probably do that when it settles down enough to have documentation etc. When you're done, will a demo version of your service be publicly available for me to try testing a WRDL against? Paul Prescod
Let's attribute it to ignorance FIRST and then malice later. Don's saying about HTTP what a lot of people are saying and thinking. What he doesn't realize is that the issues he has with HTTP are easy to solve but the solutions just aren't standardized. HTTPEvents deals with his complaint about long-running transactions and the concern about assymmetry isn't really thought through. Paul Prescod
Hello.
> <output>
> <references> <!-- abstract references -->
> <referenceType
> name="images"
> type="graphicResourceType"
> keyed="false"/>
> <referenceType name="po"
> type="purchaseOrderResourceType"
> keyed="true"/>
> </references>
>
> <representation name="ebxml_transaction_catalog">
> <reference name="images" match="img/@href"/>
> <reference name="purchase_orders" match="/ebxmlpo"
> key="../@number"/>
> </representation>
> </output>
I don't think the extra indirection is necessary. In fact, what I liked most
about your change was that it removed a level of indirection which is very
un-WSDL-like (which is good!).
The presence of the key attribute could indicate whether the reference is
keyed or not. The resourceType that the reference resolves to might as well
be on the reference element.
<output>
<referenceType
name='images'
resourceType='graphicResourceType'
match='img/@href'
/>
<referenceType
name='purchase_orders'
resourceType='purchaseOrderResourceType'
match='/ebxmlpo'
key='../@number'
/>
</output>
If resources can "return" multiple representations then you maybe you can do
this instead:
<output>
<representationType name='xhtml' test='/xhtml:html'>
<referenceType
name='images'
resourceType='graphicResourceType'
match='img/@href'
/>
</representationType>
<representation name='ebxmlpo' test='/ebxmlpo'
<referenceType
name='purchase_orders'
resourceType='purchaseOrderResourceType'
match='/ebxmlpo'
key='../@number'
/>
</representationType>
</output>
Of course, in the interest of modularity and reusability, I would think
about allowing you to define both representationTypes and referenceTypes as
children of the types document element.
<types>
<resourceType name='someResourceType'>
<output>
<representation ref='xhtml' name='web_page' />
<representation ref='ebxmlpo' />
</output>
</resourceType>
<representationType name='xhtml' test='/xhtml:html'>
<referenceType
name='images'
resourceType='graphicResourceType'
match='img/@href'
/>
</representationType>
<representation name='ebxmlpo' test='/ebxmlpo'
<reference ref='purchase_orders' name='purchase_orders' />
</representationType>
<referenceType
name='purchase_orders'
resourceType='purchaseOrderResourceType'
match='/ebxmlpo'
key='../@number'
/>
</types>
OK, so I went in re-added some extra indirection but it's strictly
syntactic. Notice that by making the type definitions and type references
different element types they can still be validated using a DTD or XML
Schema (unlike XML Schema until it gets co-constraints).
These are just rough ideas so feel free to tear them apart. :-)
Jason
What a tool. Here's one: "REST Discussion List Predicts Death of XML-RPC, SOAP-as-RPC, .NET, First-Gen Web Services, and Don Box's Career." It's amazing that otherwise apparently-smart people can fail to learn the same lessons over, and over... and over... and over... jb Jim Ancona wrote: > http://zdnet.com.com/2100-1105-845220.html > > ===== > Jim Ancona > jim@... jancona@... > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"We have to do something to make it (HTTP) less important," said Box. "If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests--I need a way to send a request to a server and not the get result for five days." That's what the response status of "Accepted" is meant for. Since there is currently no common way of getting the final response people think it can't be done. It can, but few other than Paul/etc. have blazed the trail. If we play our cards right with asynch http we can fill in the missing piece that the soap builders think requires a new protocol, and perhaps pop the hype bubble surrounding soap. Resource modelling applied to asynch communication isn't all that hard - put together some client and server apis and a few whitepapers and let technology evolution take its course. mike PS I'm not sure '...industry wide way...' is required or even good for a decentralized/evolutionary system like the Web. A few large pockets that are interoperable sounds good to me. ----- Original Message ----- From: "Jim Ancona" <jim@...> To: <rest-discuss@yahoogroups.com> Sent: Tuesday, February 26, 2002 10:08 AM Subject: [rest-discuss] Don Box predicts death of HTTP, film at 11 > http://zdnet.com.com/2100-1105-845220.html > > ===== > Jim Ancona > jim@... jancona@... > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Jeff Bone wrote: > > What a tool. Here's one: "REST Discussion List Predicts Death of XML-RPC, > SOAP-as-RPC, .NET, First-Gen Web Services, and Don Box's Career." It's > amazing that otherwise apparently-smart people can fail to learn the same > lessons over, and over... and over... and over... It boils down to this: very few people know how protocols work or how to design them. If a protocol doesn't have a gadget called "long-lived transactions" then clearly it can't do them. That's precisely why RPC is the wrong strategy. We will turn *everybody* into a protocol designers. A year ago I said that we need SOAP because it allows us to build protocols faster and we need more protocols for all of these new problem domains. I was totally wrong. Paul Prescod
Paul Prescod wrote: > That's precisely why RPC is the wrong strategy. We will turn *everybody* > into a protocol designers. A year ago I said that we need SOAP because > it allows us to build protocols faster and we need more protocols for > all of these new problem domains. I was totally wrong. Ditto, almost exactly. The amazing thing is how *clearly* that POV is wrong, post-facto. Hindsight's usually 20-20 (x 20-20), but in this case it's more like 20-5 (x 20-5). Or so it seems to me, jb
> From: Andrew Kuchling [mailto:akuchlin@...] <snip/> > Looks very cool. If you want a public CVS repository for it, I'd > suggest using the pyxml.sourceforge.net one. How about a language-neutral repository, instead? Maybe start a "REST tools" project at sourceforge and let people contribute implementations for different languages, rather than tying this completely to Python. I, for one, am a Java and COM/C++ developer.
On Tue, Feb 26, 2002 at 10:36:27AM -0800, Paul Prescod wrote:
>When you're done, will a demo version of your service be publicly
>available for me to try testing a WRDL against?
If I decide to try the REST approach, then sure, I'll try to arrange
that. The choice between REST and XML-RPC hasn't really been made in
my head yet, though. (But the existence of running WRDL toolkits in
Python, Java, &c., would certainly swing the odds in one direction,
though.)
--amk (www.amk.ca)
A burden shared is a ... something or other.
-- Bor, in "Terminus"
> Ditto, almost exactly. The amazing thing is how *clearly* that POV is wrong, > post-facto. Hindsight's usually 20-20 (x 20-20), but in this case it's more like > 20-5 (x 20-5). Or so it seems to me, Don't tell that to BEEP promoters. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
This message concerns itself with the issue of PUT vs. POST for
creating/updating resources. I'm trying to get a handle on some rules
of thumb for the time I want to actually apply REST...
Image the resource identified as http://foo.org/bar
Case 1. There is only a text/html representation and it's
static. There are no other representations. It's ok to PUT an
update to it. In fact you SHOULD or even MUST use PUT.
Case 2. There are 3 representations that can be retrieved using
conneg: text/html, image/jpeg, or text/xml, and you somehow
know that the html and jpeg representations are actually
mapped from the xml representation. Let's call this the
"ur-representation". Then you could conceivably PUT the xml
representation. But it would not be sufficient to PUT the
image or html representation since the underlying resource
would be unable to generate the other representations from
either the image or the html.
Case 3. The client knows nothing about the resource's static nature nor about
its ur-representation. You can't PUT to it. You MUST use
POST. In fact, this kind of resource can't be created without
a "Processing Block" [1] which implies an already existing
resource.
So perhaps the rules or thumb (ROT) are:
ROT 1. "To update/create a resource having only a single exposed
representation, your design MUST allow for PUT of the
ur-representation."
ROT 2. "To update/create a resource having multiple exposed
representations, your design SHOULD allow for PUT of the
ur-representation"
However in case 2/rule 2 aren't we violating the implicit contract of
PUT which is that there is no significant transformational process
involved? RFC 2616 Section 9.6 [2] says
"The PUT method requests that the enclosed entity be stored under
the supplied Request-URI."
So perhaps the conclusion really is that you can only PUT to a static
resource that exposes only a single representation.
Interestingly, 2616 leaves a back door open:
"A single resource MAY be identified by many different URIs. For
example, an article might have a URI for identifying "the current
version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI might result
in several other URIs being defined by the origin server."
I.e. the PUT could cause a "shift" of resource identifiers like
"http://foo.org/bar-current" and/or the creation of identifiers like
"http://foo.org/bar-previous". Then that implies that it's OK to have
a higher-order process do stuff in response to a PUT. That leaves me
back at the stage where use of PUT or POST are equally defensible in
Case 2.
Some other material that might help with this conclusion seems only to
keep things as muddy:
Let's look at something most people are probably familiar with by now,
the REST Wiki [3]. There have been discussions about how it would be
good to be able to apply REST to maintaing a Wiki [4].
I read the arguments on that page about PUT vs. POST but am still left
with some vague uneasiness. It seems to me that the debate hinges on
the definition of resource and representation and on what I believe is
ambiguous treatment of the topic in Fielding's dissertation [5]. The
crux of the debate seems to be based on the fact that GET returns
representations and PUT was originally designed to create/replace
representations; but things like Wikis require a processing block
(c.f. [1] - Section 3.) to stitch the new/changed page back into the
Wiki. Someone (it's a bit hard to follow attribution) on [4] states
"The entity in the PUT request may be the response to a later GET
request, but if not, it is an alternate representation of the same
resource, which is the important thing from a REST POV"
But that seems to me to sidestep the issue. Can updating/creating an
alternate representation of a resource cause all other representations
of that resource to change? Wishful thinking says "yes" because we
want the beneficial side-effect of PUTting a representation to a
resource to include the cache invalidation of previous GETs from that
resource.
Lets see what Fielding has to say. Fielding defines the term resource
in [6]
"More precisely, a resource R is a temporally varying membership
function MR(t), which for time t maps to a set of entities, or
values, which are equivalent. The values in the set may be resource
representations and/or resource identifiers."
He goes on to say
"REST components perform actions on a resource by using a
representation to capture the current or intended state of that
resource and transferring that representation between components."
That sure does sound like PUTting "intended state" should affect the
resource itself. Next he says
"For example, remote authoring of a resource requires that the
author send a representation to the server, thus establishing a
value for that resource that can be retrieved by later requests. If
the value set of a resource at a given time consists of multiple
representations, content negotiation may be used to select the best
representation for inclusion in a given message."
This is all tantalizingly vague. He does not connect the dots between
the two sentences. I.e. what happens to the representation to affect
the resource and its subsequent exposed representations. And is
further complicated by some statements near the end of section 5.4.
"The interaction method of sending representations of resources to
consuming components has some parallels with event-based integration
(EBI) styles. The key difference is that EBI styles are push-based."
Then he goes on to talk about how C2 "could operate in REST's pull
style". Is not a PUT of a representation a push? If so, then we're
still left wondering.
Moving along to Section 6 [7] we find out that all the representations
you can GET from a web server do not suffice to recreate a
resource. (He certainly does not talk about ur-resources.)
"attempts to mirror the content of a Web server as files will fail
because the resource interface does not always match the semantics
of a file system, and because both data and metadata are included
within, and significant to, the semantics of a representation. Web
server content can be replicated at remote sites, but only by
replicating the entire server mechanism and configuration, or by
selectively replicating only those resources with representations
known to be static"
When he talks about caching in Section 6.3.3.2, we find out that maybe
something can be PUT, but that representation cannot simply be picked
up by an intermediary cache. The implication is that the cache should
flag its content as invalid because
"An HTTP cache cannot assume that what gets written through it is the
same as what would be retrievable from a subsequent request for that
resource, and thus it cannot cache a PUT request body and reuse it
for a later GET response. There are two reasons for this rule: 1)
metadata might be generated behind-the-scenes, and 2) access control
on later GET requests cannot be determined from the PUT request."
He does not mention that alternate representations may be generated by
the PUT.
I'm also a bit curious about all the emphasis on cacheability. I
understand the need for caching. I understand why GET should be
idempotent. But given that we know nothing about the actual cache
topologies being deployed, it's a little hard to figure out how
effectively a single PUT from a single client to a resource can
invalidate more than a fraction of the cached representations of that
resource. It would seem more logical to me that caching services would
have to develop some additional handshaking to ensure timely cache
coherence. And I suspect that there are often caches from competing
cache service providers in play. It's unlikely they will talk to each
other as they see random "PUT"s flying by.
So the bottom line is that I'm still at odds with when to PUT and when
to POST, but I'm leaning towards my rules of thumb above.
Thanks for listening...
====
[1] http://www.ietf.org/internet-drafts/draft-baker-http-resource-state-model-01.txt
[2] http://www.ietf.org/rfc/rfc2616.txt?number=2616
[3] http://internet.conveyor.com/RESTwiki/moin.cgi
[4] http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest
[5] http://www.ebuilt.com/fielding/pubs/dissertation/abstract.htm
[6] http://www.ebuilt.com/fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
[7] http://www.ebuilt.com/fielding/pubs/dissertation/evaluation.htm
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle http://www.intl-interfaces.com
adoyle@...
On Wed, Feb 27, 2002 at 04:37:08PM -0500, Allan Doyle wrote:
>ROT 2. "To update/create a resource having multiple exposed
> representations, your design SHOULD allow for PUT of the
> ur-representation"
>
>However in case 2/rule 2 aren't we violating the implicit contract of
>PUT which is that there is no significant transformational process
>involved? RFC 2616 Section 9.6 [2] says
>
> "The PUT method requests that the enclosed entity be stored under
> the supplied Request-URI."
But the XML and GIF representations *are* the same resource; they must
be because they're given the same URI. I don't interpret RFC2616 as
saying anything about no transformation being involved. (For example,
the entity might be stamped with the ID of the user PUTting it; that's
certainly a transformation, though not a particularly complicated
one.)
XML-to-GIF is an extreme example, and I think the identity is more
obvious in less extreme cases. For example,
http://www.novels.com/novel/The_Manticore might identify one
particular novel, and accessing that URL might get you plain ASCII,
HTML, PDF, or Braille; yet it's the same book no matter what
representation it's in.
--amk (www.amk.ca)
Homological algebra beckons -- brain relief in this context!
-- Michael Hudson, 07 Nov 2001, in a discussion of Stackless Python
I'm behind the curve on this discussion and trying to catch up. Sorry if this is an ignorant question. Looking at the WRDL DTD at http://www.prescod.net/rest/wrdl.dtd I see reference to a schema type called "http://www.constantrevolution.com/ns/dtd". What is this? Is this just intended to designate an XML DTD? If so, I'd prefer the RDDL approach -- i.e. use "http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml-dt d". If, on the other hand, this is some schema language I haven't heard of before, where can I find info? Thanks.
Michael Brennan wrote: > >... > > Is this just intended to designate an XML DTD? If so, I'd prefer the RDDL > approach -- i.e. use > "http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml-dt > d". If, on the other hand, this is some schema language I haven't heard of > before, where can I find info? Sure, that would be fine. I just put it in as a placeholder while I considered a better URI. Paul Prescod
I'm still coming up to speed on this discussion, but I thought I'd chime in with a few thoughts. Hopefully, I'm not misreading WRDL (or REST), but if I am, I'm sure someone will correct me. :-) I also posted a fairly long message on the xml-dev list [1]. I didn't want to cross-post, but I'd be happy to hear comments from folks on this list regarding the thoughts I offered. Everyone keeps fixating on the RPC aspects of SOAP. There seems to be this implicit assumption that once you've debunked SOAP-RPC, SOAP has nothing to offer. I disagree, and although I find these discussions about WRDL interesting, I think it still fails to offer the sort of appeal that could win some mindshare from the SOAP/WSDL crowd. The simple XPath reliance is one notable example. Many SOAP toolkits are intentionally quite lean. Many use SAX, or use a pull-based variant of SAX. XPath matching is obviously problematic in such implementations. Another thing to keep in mind is that SOAP Encoding can be useful even if you are not using RPC. SOAP Encoding has an implicit data model that is simple, yet expressive; it can be easily mapped into the native data structures of just about any programming language, and it is easy to serialize as XML. For those who are interested in exchanging *information* between applications and are more interested in the data model than its serialization format, SOAP Encoding can be quite convenient. It makes implementation considerably easier when you want to model the messages with high-level APIs that are a natural fit for the programming language of choice. I don't think this is a bad thing. It's essentially no different from what the RDF crowd is doing. I'm thinking that WRDL needs something like a profile (or something similar) for a certain class of web service that abides by some well defined rules to ease implementations. This could offer similar benefits to the SOAP Envelope and Encoding rules. The profile could be designated by a well-known URI, just like SOAP Encoding. Implementations that are content to deal with just that certain class of web service could easily round-trip between programming language constructs and the XML syntax without having to offer sophisticated schema-driven data-binding. Also, implementations could recognize resource references and, ideally, differentiate between references to shared context vs. resources pertinent to the operation performed or the resource being addressed without having to support arbitrary XPath-based addressing into the message. These are just preliminary thoughts, but I thought I'd toss them out here and see what people think. Don't get me wrong, though. WRDL looks interesting, and I'm won to the notion that WSDL got it all wrong and that the WRDL approach is on the right track. I just think that people are missing the things about SOAP that genuinely appeal to many developers, and I think its worth addressing these things head-on and try to win some mindshare from the web service community. [1] http://lists.xml.org/archives/xml-dev/200202/msg01393.html
Andrew Kuchling wrote: > >... > > But the XML and GIF representations *are* the same resource; they must > be because they're given the same URI. I don't interpret RFC2616 as > saying anything about no transformation being involved. I agree. I would say that it would be good form to say that if you do a PUT to a particular resource with a particular content-type that a GET to that same resource with the same content-type would get back the same thing. But allowing alternate content-type representations is not really considered a transformation. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > But allowing alternate content-type representations is not really > considered a transformation. > Really? Why not? I would think just the opposite - alternate representations are nothing but a transformation of a resource.
not sure how many of you guys were at DevWeek - but somebody who was there has posted a first account summary [1] of exactly what Don said in his key note speech. maybe reading this would avoid misunderstandings? http://www.razorsoft.net/weblog/stories/2002/02/28/thatKeynoteyouKnowT heOne.html thanks --Dilip --- In rest-discuss@y..., Jim Ancona <jim@a...> wrote: > http://zdnet.com.com/2100-1105-845220.html > > ===== > Jim Ancona > jim@a... jancona@x...
rdilipk wrote: > > not sure how many of you guys were at DevWeek - but somebody who was > there has posted a first account summary [1] of exactly what Don said > in his key note speech. maybe reading this would avoid > misunderstandings? Unfortunately this summary hardly touches upon what Don said about HTTP. The zdnet article was actually more technical. Paul Prescod
--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > Unfortunately this summary hardly touches upon what Don said about HTTP. > The zdnet article was actually more technical. > > Paul Prescod then how about this? http://www.sellsbrothers.com/spout/#httpIsDead --Dilip
rdilipk wrote: > > --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > > Unfortunately this summary hardly touches upon what Don said about > HTTP. > > The zdnet article was actually more technical. > > > > Paul Prescod > > then how about this? > http://www.sellsbrothers.com/spout/#httpIsDead That article makes all of the points that we've been making in the rest-discuss list for months (but in excellent detail and with clear presentation). Don Box should have thought these issues through himself before he gave the talk: "The problems raised in the ZDnet article can essentially be summed up thus: clients can't expose endpoints. To me, this doesn't look like a problem with HTTP, it's a problem with the infrastructure. Changing the protocol is certainly not sufficient to fix the infrastructure problems; it's not clear to me that it is even necessary." Paul Prescod
rdilipk wrote: > then how about this? > http://www.sellsbrothers.com/spout/#httpIsDead Let's not mince words: Don views HTTP as "the cockroach of the Internet" --- his own words. Don's perfect world is one where the Internet is a universal bus on which type-specific objects communicate. That's a nice vision, but one that is technically flawed in a very obvious way: all attempts to build such universal buses for type-specific objects or components has failed. Agreement and problems with Don's POV: (1) Asymmetry of HTTP is a problem. No doubt, I am in total agreement. But the problem can be solved in numerous HTTP-friendly ways, many of which have been discussed on this list, more elsewhere. That asymmetry doesn't mean we have to chuck HTTP, though; there's exponential value in putting an HTTP listener everywhere there are resources of interest, exposing those resources through HTTP. Dealing with the firewall is simply a matter of standardizing generic rendezvous intermediaries and how they interact with domain naming. (2) His concern over long-running transactions is a red herring. Think about it this way: existting client-server DB connection protocols support transactions --- even long-running ones --- and transaction management at a semantic level. However, these things are modeled on top of RPCs, which are 1-shot, synchronous, and provide no transactional semantics. HTTP doesn't directly model transactions, but that doesn't mean you can't build transactional systems on top of it. It's simply a matter of modeling your "application" (i.e., resources or domain objects and their interactions) appropriately. (3) He fails to factor out the need for long-running "transactions" and asynchronous messaging. They are related but different. Again, HTTP's fundamentally synchronous nature doesn not prevent asynchronous communications patterns from being used. Paul's HttpEvents spec, Mark Nottingham's WARM / RUP work, and so on are nascent attempts to define how to do asynchronous communications in a manner that fits with the current Web architecture. (4) Fundamentally, Don's got a very deep vested interest in seeing RPC-style SOAP interfaces deployed universally; this interest is rooted in Microsoft's own deeply vested interest in maintaining balkanization of data and systems and integration friction. To the extent that the Web architecture succeeds, it strategically devalues Microsoft. (5) Don and the rest of the SOAP-RPC camp are suffering from yet another iteration of a fundamental failure of software engineering and design. Our industry was sold a bill of goods about "reuse," productivity gains, etc. -wrt- OO 10-15 years ago. In the process of buying into the OO religion, we failed to learn an important lesson: OO rarely works as a large-scale integration methodology. Generic interfaces and generic composition frameworks have always demonstrated better scalability, reusablility, simplicity, economics, etc. than OO. Cases in point: UNIX, Plan 9, the Web, Linda. Until we as an industry learn the lessons these examples pose, we're doomed to fail over and over again, developing technologies that cannot withstand the test of time and ubiquity: ONC and DCE RPC, CORBA, DCOM, etc. jb
Hi, Paul. I see you have a new draft up! Would it be possible to put the date of each draft at the top so that we can tell when you've made changes? The DTD has a bad mixed content model for the documentation element (you need a * at the end). Wouldn't making it ANY be easier? What if I want to use DocBook for my documentation? (This is why I prefer a single annotation element with a content model of ANY--I could then put multiple elements in there with different names or attributes to indicate mediaType or language or anything else I wanted.) The links to the Babelfish example and Python implementation are broken. Regarding the new namespace attribute on representationType elements: My faith in being able to use namespaces to reliably identify a document is very slim. I see them (as Patrick Stickler recently pointed out) as merely punctuation. The mediaType attribute seems much more capable of identifying a representation. What would we use the namespace attribute for? Regarding the new schema elements: Do we really want to embed schemas in WRDL documents? Wouldn't it be more maintainable if we could reference them? Regarding the occurs attribute on reference elements: Should there be a way for the generated proxies to require that a reference appears? I might suggest regular expression-like values "?" for zero or one, "*" for zero or more, and "+" for one or more. The absence of an occurs attribute could imply that only one reference is required (what happens if there's more than one? Does it only match the first?). This makes it possible for proxies to throw exceptions if a required reference is missng. Regarding the key attribute: You don't mention it but I assume that it's implied, does the presence of a key attribute always indicate that multiple references are allowed? Would the occurs attribute then apply to the number of values that can be associated with each key? Regarding the type attribute on reference elements: The description is somewhat vague. If I do a GET on a URI identified by a reference, is it like doing a GET on a resourceType with the same name as the type attribute? What happens when the type is missing? What would the proxy generator generate then? Would it return something generic like a byte stream? Hope this helps, Jason
----- Original Message ----- From: "Jeff Bone" <jbone@...> > > (4) Fundamentally, Don's got a very deep vested interest in seeing RPC-style > SOAP interfaces deployed universally; this interest is rooted in Microsoft's > own deeply vested interest in maintaining balkanization of data and systems > and integration friction. To the extent that the Web architecture succeeds, > it strategically devalues Microsoft. This is a very important point - and you don't have to be a conspiracy freak to see it or believe it.
"S. Mike Dierken" wrote: > This is a very important point - and you don't have to be a conspiracy freak > to see it or believe it. This is hopefully true notwithstanding the fact that the person that originally made the assertion mentioned -- i.e. me -- is probably on some level a certifiable conspiracy freak. ;-) (Long-winded way of saying "thanks Mike!" ;-) jb
However, the interesting thing is that the keynote gave me the distinct impression that Don favored messaging over RPC. He spent quite a bit of time talking about how it wasn't at all clear that "stretching RPC out to internet scale" would work, and how a potentially much better approach would be to shrink messaging down to work "in the small". According to him, the issue there is the programming model, which is what he said he's working on at Microsoft. When I wrote up [1] the various themes that Don touched on, I deliberatedly avoided saying which side of the issues Don came down on, since the writeup would have been waaay longer. My point was that the keynote covered more ground thatn merely "HTTP is dead", and the other themes were also interesting questions in their own right. --Peter [1] http://www.razorsoft.net/weblog > -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Friday, March 01, 2002 1:36 AM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: Don Box predicts death of > HTTP, film at 11 > > ----- Original Message ----- > From: "Jeff Bone" <jbone@...> > > > > > (4) Fundamentally, Don's got a very deep vested interest in seeing > RPC-style > > SOAP interfaces deployed universally; this interest is rooted in > Microsoft's > > own deeply vested interest in maintaining balkanization of data and > systems > > and integration friction. To the extent that the Web architecture > succeeds, > > it strategically devalues Microsoft. > > This is a very important point - and you don't have to be a > conspiracy freak > to see it or believe it.
Jason Diamond wrote: > > Hi, Paul. > > I see you have a new draft up! Would it be possible to put the date of each > draft at the top so that we can tell when you've made changes? Will do. > The DTD has a bad mixed content model for the documentation element (you > need a * at the end). True. > ... Wouldn't making it ANY be easier? What if I want to > use DocBook for my documentation? I think that there has to be standardization. If I write a tool to extract documentation from a WRDL it will only work if I know what the element types are. Therefore I want to strongly encourage people towards one standard (whether it be XHTML or Docbook) and if you really must do your own thing then you can do it in an AppInfo tag. (This is why I prefer a single annotation > element with a content model of ANY--I could then put multiple elements in > there with different names or attributes to indicate mediaType or language > or anything else I wanted.) How do you figure out how to process the elements? From the namespace? I thought you didn't trust that? > The links to the Babelfish example and Python implementation are broken. I'm having trouble uploading through a firewall but I'll fix that when I can. > Regarding the new namespace attribute on representationType elements: My > faith in being able to use namespaces to reliably identify a document is > very slim. I see them (as Patrick Stickler recently pointed out) as merely > punctuation. The mediaType attribute seems much more capable of identifying > a representation. What would we use the namespace attribute for? Because many XML vocabularies will not have media types. I am very sympathetic to Patrick's view but in my own language I'm more concerned about popularity than purity. If the W3C decides that namespaces are The Way to identify document types then I want WRDL to be compatible. If they don't, I'll deprecate it. Plus, there is no good replacement. DOCTYPES only work with DTDs. There is no standardized PI or anything else. > Regarding the new schema elements: Do we really want to embed schemas in > WRDL documents? Wouldn't it be more maintainable if we could reference them? That's why it has an href attribute! > Regarding the occurs attribute on reference elements: Should there be a way > for the generated proxies to require that a reference appears? I might > suggest regular expression-like values "?" for zero or one, "*" for zero or > more, and "+" for one or more. The absence of an occurs attribute could > imply that only one reference is required (what happens if there's more than > one? Does it only match the first?). This makes it possible for proxies to > throw exceptions if a required reference is missng. What about stealing minOccurs and maxOccurs from XML Schema? > Regarding the key attribute: You don't mention it but I assume that it's > implied, does the presence of a key attribute always indicate that multiple > references are allowed? Probably better to still require the minOccurs attribute but... > ... Would the occurs attribute then apply to the number > of values that can be associated with each key? No, I can't follow that logic. I think it should still just count the number of hits to the reference. > Regarding the type attribute on reference elements: The description is > somewhat vague. If I do a GET on a URI identified by a reference, is it like > doing a GET on a resourceType with the same name as the type attribute? Right. > ... What > happens when the type is missing? What would the proxy generator generate > then? Would it return something generic like a byte stream? Yes, the Python implementation (which I thought was on the site) has a GenericResource type. It has no references so it is basically a navigational dead-end. But you can GET and POST and PUT and DELETE it. And yes you can get the byte stream if you ask for it (but that's true even of XML resources). Paul Prescod
Peter Drayton wrote: > > However, the interesting thing is that the keynote gave me the distinct > impression that Don favored messaging over RPC. He spent quite a bit of > time talking about how it wasn't at all clear that "stretching RPC out > to internet scale" would work, and how a potentially much better > approach would be to shrink messaging down to work "in the small". That sounds to me like: "We tried to force one non-Internet model onto the Internet and it didn't work. Now we're about to try to force another non-Internet model onto the Internet. Maybe that will work. Oh, and by the way, that protocol that is the basis for most of the Internet's most sophisticated applications? Let's kill that." > According to him, the issue there is the programming model, which is > what he said he's working on at Microsoft. People have spent the last five years adopting to the Web's programming model, inconvenient as it is. Paul Prescod
Here is a message that describes a reasonable message exchange with first class resources for the business document exchange http://groups.yahoo.com/group/rest-discuss/message/88 ----- Original Message ----- From: "bhaugen32" <bhaugen32@...> To: <rest-discuss@yahoogroups.com> Sent: Tuesday, February 19, 2002 5:13 AM Subject: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language > "S. Mike Dierken" <mdierken@h...> wrote: > > > B. How do you handle order fulfillment? > > It's out of band for our app - we just delivery the docs. If a > business > > document is defined for 'shipping notice' or 'delivery status' or > whatnot, > > we'll deliver those. > > Got any ideas on how you might RESTify this app? > Possibly relevant excerpt from REST Wiki FAQ:
"S. Mike Dierken" <mdierken@h...> wrote: > Here is a message that describes a reasonable message exchange with first > class resources for the business document exchange > > http://groups.yahoo.com/group/rest-discuss/message/88 Thank you, very nice and suggestive. I like it much better than one of the previous proposals that had the order changing its identity with every change of state. If I understand correctly, in your proposal, subsequent conversations about the order would be addressed to sub-resources of the same order. And you laid out the business process as a series of return addresses for subsequent conversational acts. Did the example referenced above depict a "real" business exchange? (I don't mean the contents, just the conversational acts.) Also, I wonder if the idempotency of PUT might be a problem in a slightly more elaborate conversation: for example, if the Acknowledgment of Submission were supposed to be followed by an explicit Acceptance or Rejection, e.g. == Submitting a purchase order == POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1 Ack-To: http://www.smallbiz.com/accounting/po/12345/ack/ Response-To: http://www.smallbiz.com/accounting/po/12345/response/ So there would be a couple of ways to do it. As above, where the response could say "Accept" or "Reject" or maybe "Counter Offer To Come" (we're negotiating, and the deal is still alive). Or you could do: Acceptance-To: http://www.smallbiz.com/accounting/po/12345/accept/ Rejection-To: http://www.smallbiz.com/accounting/po/12345/reject/ In either case, couldn't you have an ambiguous state of the order with more than one PUT, one indicating acceptance, the other rejection? Would a POST to the order (handle this submission as a sub-resource) be more semantically accurate? How would that change the conversation process addresses? Just thinking about it...not sure I am thinking clearly yet. Thanks, Bob Haugen
> ----- Original Message ----- > From: "bhaugen32" <bhaugen32@...> > > > > http://groups.yahoo.com/group/rest-discuss/message/88 > > Did the example referenced above depict a "real" business exchange? > (I don't mean the contents, just the conversational acts.) No - it was not an actual exchange that took place - only a mental experiment. As I learn more about how real businesses exchange real documents (paper, fax, etc.) I will be able to make the sample message exchange more realistic. However, from what I can tell of the real world of (small/medium) business, there is not a lot of consistency between the millions of different businesses. mike
"S. Mike Dierken" wrote: > from what I can tell of the real world of (small/medium) > business, there is not a lot of consistency between the millions of > different businesses. 1. There is more consistency than you may think. There is both commercial law and a body of common practices that differ somewhat by region and industry, but have some common elements everywhere. 2. For electronic commerce, there have been years of work on standardization. I know, standards are so nice because there are so many of them. But all of the initiatives below are related, as a family of standards where each used and built upon the predecessor: * UNIFORM RULES OF CONDUCT FOR INTERCHANGE OF TRADE DATA BY TELETRANSMISSION (UNCID), http://www.unece.org/trade/untdid/texts/d220_d.htm * UN/ECE RECOMMENDATION No.26, THE COMMERCIAL USE OF INTERCHANGE AGREEMENTS FOR ELECTRONIC DATA INTERCHANGE, http://www.unece.org/trade/untdid/texts/d240_d.htm * The Commercial use of Electronic Data Interchange, Section of Business Law American Bar Association, A report and model trading partner agreement, http://www.abanet.org/buslaw/catalog/5070258.html * ISO Open-EDI http://www.jtc1sc32.org/ http://www.rosettanet.org/ http://www.ebxml.org/ http:/www.ebtwg.org/ I'm not suggested you read all of the above. But here is a concrete example-in-progress: http://lists.ebtwg.org/archives/ebtwg-bcp/200202/msg00020.html That example is supposed to be technology-neutral, but there are a lot of P2P EDI assumptions in the group. My purpose for hanging out on this list is to figure out what it would mean to RESTify some of this body of work. Have fun, Bob Haugen
100 Cups 18 Litres Buxton Water Hot Drinks Pack: CONTAINING: Nescafe Tetley Tea Options Hot Chocolate Batchelors Cup a Soups WOULD YOU LIKE TO TRY A BUXTON WATERCOOLER? Our Unique hot & cold beverage solution incorporating Buxton Water & hot beverages - it's much more than just a watercooler!! A fully maintained hot & cold drinks solution for your workplace A full range of beverages including Nescafe & Gold Blend Coffee, Options Hot Chocolate, Tetley Tea and Batchelors Cup a Soups Free, no obligation 7 day trial with water, cups and beverage sample pack Please send me a free trial Please send me more information SPECIAL OFFER PRICES RENTAL ONLY 2.50 PER WEEK & WATER IS ONLY 6.35 per 18.9ltr BOTTLE IF YOU DECIDE TO KEEP THE COOLER YOU WILL RECEIVE A 20 HIGH STREET GIFT VOUCHER OF YOUR CHOICE OR 3 FREE BOTTLES OF BUXTON WATER Water Cups Our compact, stylish watercooler that delivers fresh, chilled Buxton Water It is a well known fact that every day your body needs 1.8 litres of water We provide a customer service programme second to none Free, no obligation 7 day trial with water cups Please send me a free trial Please send me more information FAXBACK ON 0871 8550802 OR CALL 0800 2796969 SIMPLY FILL IN THE FORM BELOW & WE WILL DELIVER TO YOUR DOOR WITHIN 48 HOURS: PLEASE COMPLETE BELOW: Name: Phone: Company: Fax: Title: Postcode: We try to ensure that those people who do not wish to receive emails do not receive them by ensuring our agencies cleanse use the FPS database. If you do not wish to receive emails please return an email with UNSUBSCRIBE in the title and we shall remove your email address from the database.
"S. Mike Dierken" wrote: > > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > > But allowing alternate content-type representations is not really > > considered a transformation. > > > Really? Why not? I would think just the opposite - alternate representations > are nothing but a transformation of a resource. I meant that the PUT is not semantically a transformation. It is a transformation only in the sense that you transform from the representation to the underlying bits that comprise the resource. It isn't semantically an HTML to GIF transformation. It's an HTML to "graphical object" converter, which happens to generate GIF representations if you ask for them. Paul Prescod
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> To: <rest-discuss@yahoogroups.com> Sent: Saturday, March 02, 2002 6:15 AM Subject: [rest-discuss] Re: RESTify a business document exchange app > > Also, I wonder if the idempotency of PUT might be a problem in a > slightly more elaborate conversation: > for example, if the Acknowledgment of Submission were supposed to be > followed by an explicit Acceptance or Rejection, e.g. > > == Submitting a purchase order == > POST http://www.widgets.com/industrial/widgets/purchase-orders/ > HTTP/1.1 > Ack-To: http://www.smallbiz.com/accounting/po/12345/ack/ > Response-To: http://www.smallbiz.com/accounting/po/12345/response/ > > So there would be a couple of ways to do it. As above, where the > response could say "Accept" or "Reject" or maybe "Counter Offer To > Come" (we're negotiating, and the deal is still alive). > > Or you could do: > Acceptance-To: http://www.smallbiz.com/accounting/po/12345/accept/ > Rejection-To: http://www.smallbiz.com/accounting/po/12345/reject/ > > In either case, couldn't you have an ambiguous state of the order > with more than one PUT, one indicating acceptance, the other > rejection? > The two headers 'reply-to' and 'status-to' were meant to separate out advisory messages describing processing of a message from application/semantic response messages. The 'reply-to' is the authoritative status of the 'business response' to the business request. More than one differing values PUT there would be an error (for most business document exchanges, some agreements may allow updates to invoices, etc., but I'm not a business guy so it may be those things are new resources somehow related to the original message). More than one differing value sent to the status would be okay. I wouldn't put application specific concepts in headers - generic asynch messaging and resource manipulation concepts would be okay though. So 'rejection' and 'acceptance' are busines concepts & should stay out of a header name. They should be a value within a message body that is sent as the 'application response'. Knowing where to put the response is a generic concept to request/response message exchanges. In a typical synchronous request/response, you just send it in the response (in http the correlation between req/resp happens because of the single connection, a wicked cool simplification). In a two-phase request response, you put it to the response location - the location being the correlation information - but it is the same concept as synch request/response. In the sample the status is updated with PUT - but if the server wants to keep a history, perhaps it should be POST. But I don't want the clients needing to know what the server intends to do. I'd like to expose the resource as the 'current status' - no assumptions about 'extending' an audit trail - and so I used PUT. If the server chooses to keep history, then I suppose a new resource is needed for the audit trail - which would be a collection of previously PUT entities.
I responded to Paul on xml-dev recently explaining my general dissatisfaction with method-granularity interface specs like WIDL, WSDL, WRDL, etc... Here's my suggestion for a next-gen interface mechanism; http://www.markbaker.ca/2002/03/RestRDF/ MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Paul Prescod" <paul@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> > I meant that the PUT is not semantically a transformation. It is a > transformation only in the sense that you transform from the > representation to the underlying bits that comprise the resource. It > isn't semantically an HTML to GIF transformation. It's an HTML to > "graphical object" converter, which happens to generate GIF > representations if you ask for them. Oh, okay, I see. The 'platonic resource' can't be touched, but you can interact with the shadows on the wall. mike
> From: Mark Baker [mailto:distobj@...] <snip/> > I responded to Paul on xml-dev recently explaining my general > dissatisfaction with method-granularity interface specs like WIDL, > WSDL, WRDL, etc... > > Here's my suggestion for a next-gen interface mechanism; > > http://www.markbaker.ca/2002/03/RestRDF/ This looks good to me. I feel there is a need for higher-level archetypes that can be more easily aligned with the sorts of models business developers use. This looks to me like a promising direction. I'm curious how one would model workflow with something like this. Traditional OO often uses state machines as part of modelling such a solution, whereas (based on comments I've heard here, on the REST wiki, and on xml-dev) REST encourages the use of resources to model steps in a workflow. Presumably, where necessary, one would use transient resources that expire when the workflow is complete, or a step in the workflow that invalidates this resource is taken. Would it make sense to have an archetype in the taxonomy for such resources?
"S. Mike Dierken" <mdierken@h...> wrote: > The two headers 'reply-to' and 'status-to' were meant to separate out > advisory messages describing processing of a message from > application/semantic response messages. The 'reply-to' is the authoritative > status of the 'business response' to the business request. I can go along with that, depending on what you mean by status. The chain of standards I alluded to in a previous message (UNECE-ISO- RosettaNet-ebXML) makes a similar distinction. ebXML calls the business content "Business Documents" and the status messages "Signals". The status signals tend to be simple ACKs but depending on agreement, acceptance could also be a signal. (Simple cases.) In more complex cases, acceptance would be a substantive business document. If I understand your proposal correctly, you would always make acceptance a substantive response, which works fine for me. > Knowing where to put the response is a generic > concept to request/response message exchanges. In a typical synchronous > request/response, you just send it in the response (in http the correlation > between req/resp happens because of the single connection, a wicked cool > simplification). Seems like a good slot for a simple receipt ACK. > In the sample the status is updated with PUT - but if the server wants to > keep a history, perhaps it should be POST. But I don't want the clients > needing to know what the server intends to do. I'd like to expose the > resource as the 'current status' - no assumptions about 'extending' an audit > trail - and so I used PUT. If the server chooses to keep history, then I > suppose a new resource is needed for the audit trail - which would be a > collection of previously PUT entities. The above paragraph seems to imply that you are thinking of something different for status than simple ACKs. Are you thinking of Delivery and Payment as statuses? If so, I got an argument for you... But so far, moving forward. Thanks, Bob Haugen
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > My goal in joining your discussion is to take some of the business > concepts from ebXML and RESTify them. I hope to influence ebXML and > related efforts to move in the REST direction. > > I find it fairly natural to model business objects as suites of Web > resources. (Paul Prescod: refering to one of your recent opponents > on the xml-dev list, I think it is perfectly feasible to model almost > everything in any business application system (ERP, CRM, etc.) in Web > resources.) Any luck with getting someone to do a pure http binding for the Registry and Repository services? They seem to /beg/ for a simple URI and http access mechanism. Maybe we can convince MarkB to do that like he did with some xml-rpc interfaces. I'll go start a page in the Wiki...
> ----- Original Message ----- > From: "bhaugen32" <bhaugen32@...> > > In more complex cases, acceptance would be a substantive business > document. If I understand your proposal correctly, you would always > make acceptance a substantive response, which works fine for me. When there is a substantive business document, I would always want a first-class resource (uri, etc.). There is probably always going to be a business document for full acceptance of a business request - correct me if I'm wrong. The initial submission ack might not have a substantive business document defined. If we POST a biz doc and return an 'Accepted' status to indicate that the document was transferred but not yet processed, I'm not sure about returning a Location header (the http rfc doesn't mention it - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ). The existence of a document might imply business acceptance - which is not correct. If the business process defines acknowledgement or status documents that have 'accepted', 'rejected' and 'undecided' values, then this would be fine I think (retrieving the status document tells you if it was actually approved). If the business document set doesn't define 'undecided' values then the Location header might need to reference a resource that does not yet exist - and when it does exist the values within would specify 'accepted' or 'rejected'. If a Location header isn't returned immediately, there is no defined way to get the status - which is why I added the Reply-To header in the original POST. A later PUT from the server would have the equivalent of a response with a 'created' status and a Location header. In the example I used "200 success" and it probably should be "201 Created" with a Location header, even if the URI was returned as a header in the initial Accepted response.
This is exactly right --- and this is part of what I was talking about a while back -wrt- the addressibility of resources vs. representations. You can't ever address representations directly. At the same time while resources are addressible they still remain abstract in some important sense: sans DAV semantics, even a PUT on the resource has an indirect and semantically vague interaction with the underlying object, semantics subject to interpretation and intermediation by some unspecified and non-addressible layer(s) of software. I waffle between believing this is a hugely powerful and important (if underspecified) concept and thinking it's another HTTP "wart." $0.02, jb Paul Prescod wrote: > "S. Mike Dierken" wrote: > > > > ----- Original Message ----- > > From: "Paul Prescod" <paul@...> > > > But allowing alternate content-type representations is not really > > > considered a transformation. > > > > > Really? Why not? I would think just the opposite - alternate representations > > are nothing but a transformation of a resource. > > I meant that the PUT is not semantically a transformation. It is a > transformation only in the sense that you transform from the > representation to the underlying bits that comprise the resource. It > isn't semantically an HTML to GIF transformation. It's an HTML to > "graphical object" converter, which happens to generate GIF > representations if you ask for them. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> From: Mark Baker [mailto:distobj@...] <snip/> > I responded to Paul on xml-dev recently explaining my general > dissatisfaction with method-granularity interface specs like WIDL, > WSDL, WRDL, etc... > > Here's my suggestion for a next-gen interface mechanism; > > http://www.markbaker.ca/2002/03/RestRDF/ One other thing I should have mentioned in my previous post: I'm a bit fuzzy on what is meant by "identity preserving" container resource. Could someone elaborate, or point me to some discussion that would help me understand what is meant by this? The other resource types in the taxonomy make sense to me, but I am fuzzy on this one.
"S. Mike Dierken" <mdierken@h...> wrote: > Any luck with getting someone to do a pure http binding for the Registry and > Repository services? They seem to /beg/ for a simple URI and http access > mechanism. ebXML is divided into a bunch of work groups. I work with the business process groups, not reg-rep, but know the leaders of that group. I have raised the argument with them, and have received some positive responses. I believe they have decided that all repository elements should have URIs. But I think they still have UDDI and database systems in mind. > Maybe we can convince MarkB to do that like he did with some xml-rpc > interfaces. > > I'll go start a page in the Wiki... If you and MarkB start a discussion in the Wiki, I will try to corral some reg-rep people to engage in discussion. -Bob Haugen
--- "S. Mike Dierken" <mdierken@...> wrote: > If we POST a biz doc and return an 'Accepted' status to indicate that the > document was transferred but not yet processed, > I'm not sure about returning a Location header (the http rfc doesn't mention > it - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ). It seems to imply that the pointer should be in the response entity: "The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled." > The existence of a document might imply business acceptance - which is not > correct. If the business process defines acknowledgement or status documents > that have 'accepted', 'rejected' and 'undecided' values, then this would be > fine I think (retrieving the status document tells you if it was actually > approved). If the business document set doesn't define 'undecided' values > then the Location header might need to reference a resource that does not > yet exist - and when it does exist the values within would specify > 'accepted' or 'rejected'. Wouldn't it be legitimate to return "Created" with a Location header in this case. After all, you did create a resource--the status document you describe above. Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
See my "abstract model for http resource state" [1] for an explanation. It's not intended to be a required class for the base taxonomy; :Resource, :Container, :Replaceable, :Deleteable are the only required ones. But :Annotateable, :Processor, and :IdentityPreservingContainer basically define a sub-taxonomy of Containers. > One other thing I should have mentioned in my previous post: I'm a bit fuzzy > on what is meant by "identity preserving" container resource. Could someone > elaborate, or point me to some discussion that would help me understand what > is meant by this? The other resource types in the taxonomy make sense to me, > but I am fuzzy on this one. [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > Well, you SHOULD be able to, viz a viz the requirement that the > > Content-Location header SHOULD be returned when multiple representations > > exist for the same resource. > > Granted, but they aren't first-class in that they aren't identified by name i.e. > URI. Erm, I'm confused. Because what I said is that representations *are* normally identified by a URI, because that's exactly what Content-Location does. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
--- Mark Baker <distobj@...> wrote: > > > The existence of a document might imply business acceptance - which is > not > > > correct. If the business process defines acknowledgement or status > documents > > > that have 'accepted', 'rejected' and 'undecided' values, then this would > be > > > fine I think (retrieving the status document tells you if it was actually > > > approved). If the business document set doesn't define 'undecided' values > > > then the Location header might need to reference a resource that does not > > > yet exist - and when it does exist the values within would specify > > > 'accepted' or 'rejected'. > > > > Wouldn't it be legitimate to return "Created" with a Location header in > this > > case. After all, you did create a resource--the status document you > describe > > above. > > Except that then you lose the "Accepted" bit, which is really the most > important one. I think I get it now. You're referring to the case where the resource has not yet been created, but the server knows its URI in advance, correct? Using Location with Accept in that case makes sense to me, although in the particular case Mike describes, I can't see why I wouldn't just create an 'undecided' status resource at the time the business document was received. In that case I would return Created (with a Location). Jim ===== Jim Ancona jim@... jancona@... __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
> > Except that then you lose the "Accepted" bit, which is really the most
> > important one.
>
> I think I get it now. You're referring to the case where the resource has not
> yet been created, but the server knows its URI in advance, correct?
Nope.
On a 202 response, it is suggested that the body could contain a URI
that represented the "future response". So you could invoke GET on
it and it would say "not yet", "not yet", "I expect a response soon",
and then finally "the recipient got the message".
I'm suggesting bringing this URI out of the body and putting in the
Location header, and defining that the Location header on a 202
response identifies the "future response".
If anybody here ever used CORBA, there was an orb that supported
a feature called a "future", that was basically a place holder for
a response that you could either use a deferred invocation on (DII),
poll yourself, or do a blocking invocation on. This is basically
the same thing (once you add a router behind the scenes 8-).
> Using
> Location with Accept
s/Accept/Accepted
> in that case makes sense to me, although in the particular
> case Mike describes, I can't see why I wouldn't just create an 'undecided'
> status resource at the time the business document was received. In that case I
> would return Created (with a Location).
Well, as I said before, I think it's more important the "accepted"
nature of the response be reflected in the response status than the
fact that any old resource was created as a side effect. It's more
specific, and quite meaningful to intermediaries.
In a sense, if 202 did return the "future" in the Location header, then
you could consider that there's an inheritance hierarchy here;
200 <-- 201 <-- 202
<-- 203
<-- 204
<-- 205
<-- 206
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote:
> > > Well, you SHOULD be able to, viz a viz the requirement that the
> > > Content-Location header SHOULD be returned when multiple representations
> > > exist for the same resource.
> >
> > Granted, but they aren't first-class in that they aren't identified by name i.e.
> > URI.
>
> Erm, I'm confused. Because what I said is that representations *are*
> normally identified by a URI, because that's exactly what
> Content-Location does.
Sorry, right, misparse. Let me see if I can try this again. Let's say you've got a
resource named
http://foo.com/some/data/producer
This is a processing container resource, let's say. It emits representations as a
result of GET operations, and this rep describes the "current" state of the container
--- which changes rapidly. These representations vary rapidly, so that potentially
each representation emitted in response to a request is in fact different. Those
representations are not individually addressible --- I seriously doubt that many
architects would advocate giving each unique representation its own URI for use in
Content-Location. Content-Location is great for coarse-grained / relatively static
use and where it's appropriate, but it doesn't help out in the general case where a
resource has an arbitrary and time-varying number of representations.
But as I said, this isn't really problematic, except in areas like caching and
archiving. The former is easily dealt with --- resources which emit varying reps
simply manage cache behavior closely or disable it, while in the latter case various
re-write mechanisms (yuck!) generally suffice. (And generally speaking, you don't
want to be archiving all the reps emitted by a highly variant resource anyway.)
jb
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > > Maybe we can convince MarkB to do that like he did with some xml-rpc > > interfaces. > > > > I'll go start a page in the Wiki... > > If you and MarkB start a discussion in the Wiki, I will try to corral > some reg-rep people to engage in discussion. > http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry
"S. Mike Dierken" <mdierken@h...> wrote: > > If you and MarkB start a discussion in the Wiki, I will try to corral > > some reg-rep people to engage in discussion. > > > > http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry I read that. Seems a little tentative. Are you sure you are ready for engagement with people who may be skeptical? I suggest adding some reasons why they would want to do this. Could be brief, as in one-liners with references to other pages that make the argument. Then I can have one page to send them to. Needless to say, I will also reference this group, but it's more difficult to follow than the Wiki.
----- Original Message -----
From: "Mark Baker" <distobj@...>
>
> In a sense, if 202 did return the "future" in the Location header, then
> you could consider that there's an inheritance hierarchy here;
>
> 200 <-- 201 <-- 202
> <-- 203
> <-- 204
> <-- 205
> <-- 206
>
For the RFC challenged:
"OK" <-- "Created" <-- "Accepted"
<-- "Non-authoritative information"
<-- "No content"
<-- "Reset content"
<-- "Partial content"
> Any luck with getting someone to do a pure http binding for the Registry and > Repository services? They seem to /beg/ for a simple URI and http access > mechanism. > > Maybe we can convince MarkB to do that like he did with some xml-rpc > interfaces. I have this thing against registries, unless they're anything more than a list of URI like dmoz.org. The Web is so decentralized, that keeping metadata separate from data is just a maintenance and security nightmare waiting to happen. So I can't really see any value in trying to RESTify ebxml. I also can't see trying to convince a set of companies that plan to make money off a centralized model, that a decentralized model is the best way to go. So I'm not really into evangelizing REST to them either. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > >... > > I also can't see trying to convince a set of companies that plan to make > money off a centralized model, that a decentralized model is the best > way to go. So I'm not really into evangelizing REST to them either. I don't really have the time to become an ebxml reg/rep expert but I do feel that the ebXML world is a natural ally for the REST world because they seem to be document-centric rather than API and software-centric. Paul Prescod
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > > In the sample the status is updated with PUT - but if the server wants to > > keep a history, perhaps it should be POST. But I don't want the clients > > needing to know what the server intends to do. I'd like to expose the > > resource as the 'current status' - no assumptions about 'extending' an audit > > trail - and so I used PUT. If the server chooses to keep history, then I > > suppose a new resource is needed for the audit trail - which would be a > > collection of previously PUT entities. > > The above paragraph seems to imply that you are thinking of something > different for status than simple ACKs. The status messages are just advisory and notify the sender of the biz docs process through the receivers business process. If the receiver's business process spawns multiple biz docs, then the status notifications shouldn't be used - since they are only 'advisory'. The new business docs should be sent to the sender - probably as a POST to the Reply-To location. I'm using POST here to 'extend' the originating document with related material. The Reply-To in the example says '.../ack' so maybe something isn't quite right. > > Are you thinking of Delivery and Payment as statuses? If so, I got > an argument for you... > Um, not sure what a 'status' is - but my notification would be advisory and real biz docs would deserve real URI based exchange.
Mark Baker wrote: > >... > > Well, there's definitely conflicting goals there. It would not have > been hard for them to decentralize without using REST, but they chose > not to. So I think that there's forces at work there. Centralization can improve information longevity. For instance when you try to find a Java or Python library you often get a 404 but with Perl, once they are in CPAN, they are in CPAN and they never go away. Similarly consider the centralization of internet RFCs compared to random web pages on people's sites. The best of all possible worlds is for the centralized service to be a unified mirror of information that is otherwise available in a decentralized manner. Paul Prescod
> > > > http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry > > I read that. Seems a little tentative. Are you sure you are ready > for engagement with people who may be skeptical? I suggest adding > some reasons why they would want to do this. Could be brief, as in > one-liners with references to other pages that make the argument. > Then I can have one page to send them to. Needless to say, I will > also reference this group, but it's more difficult to follow than the > Wiki. No - this isn't ready. It's only a place to start. I wanted to work out the actual REST details before showing it to actual ebXML working group members. Also, there would need to be a focused 'why rest is good' introduction that relates it to ebXML reg/rep. Mike
> The best of all possible worlds is for the centralized service to be a > unified mirror of information that is otherwise available in a > decentralized manner. Agreed. My centralized/decentralized comment related only to the centralization of metadata. i.e. if I was told that http://www.yahoo.com identified Yahoo, but that I had to go to a UDDI registry at IBM to get information about it, I'd be peeved, especially when I can just do GET to get that info. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Paul Prescod <paul@p...> wrote: > Mark Baker wrote: > > > >... > > > > I also can't see trying to convince a set of companies that plan to make > > money off a centralized model, that a decentralized model is the best > > way to go. So I'm not really into evangelizing REST to them either. > > I don't really have the time to become an ebxml reg/rep expert but I do > feel that the ebXML world is a natural ally for the REST world because > they seem to be document-centric rather than API and software- centric. Mark, I don't understand why you are dismissing ebXML either. Especially since I'm here and eager to learn. Yes there are big companies trying to make money off fat central services. But ebXML has a lot of components and many of them are peer-to-peer. And there are also several people including me who are going through the ebXML stage of development in order to come out on the other side with something much simpler. Some of those people went thru the eCo framework before, which was very RESTful, and think ebXML went astray in RegRep. -Bob Haugen
> Mark, I don't understand why you are dismissing ebXML either. It's not an entire dismissal, I'm just not prioritizing it very highly, especially when there's a lot more non-political battles to be fought. > Especially since I'm here and eager to learn. Yes there are big > companies trying to make money off fat central services. But ebXML > has a lot of components and many of them are peer-to-peer. And there > are also several people including me who are going through the ebXML > stage of development in order to come out on the other side with > something much simpler. Some of those people went thru the eCo > framework before, which was very RESTful, and think ebXML went astray > in RegRep. I've heard people say that eCo appears quite RESTful, but I haven't seen that in the look I've had at it. Anyhow, I will of course help anybody who asks to know more, including yourself and any of your peers. I'm just not going to take it upon myself to try and give them religion. Please don't take that as a snubbing; as I said, there's only so many hours in a day. (btw, bhaugen32@... appears to be rejecting emails with "unknown user") MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Dan Connolly and I just had a quick exchange via IRC about how you'd map SQL operations to HTTP methods; http://ilrt.org/discovery/chatlogs/rdfig/2002-03-06.html#T18-09-55 An interesting issue is, what does SQL "update" map to? Some updates seem to clearly be POST (using Dan's example); "update employee set salary = salary * 1.03 where performanceEval>4" but what about this; "set salary = 40000 where level=4" Now, the issue is, I think, if we have a URI representing "all salaries for level 4 employees", then this is a set, i.e. a container. My interpretation of REST suggests that in order to PUT to a container, you have to replace the entire state of the container. So saying "PUT <40000>" to that URI is a mismatch. It should be "PUT <40000, 40000,40000,40000 ...>". This is a real brain teaser. Clearly you can do it all over POST, by just posting the SQL statement (minus the where clause, since that should be in the URI), but would that be considered tunneling? I'm stumped, for now. Anybody else got any ideas? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I've been thinking a lot about names, identifiers, and opacity over the
last couple of months, and wondering why we stringently insist on opaque
identifiers on the Web while, completely counter to this, the trend in
filesystem research has been to *increase* the semantic richness of
names. I've tried to synthesize a cogent treatment of this thought and
investigation; the result of this is a (rather lengthy) write-up I've
made available on the RestWiki. Comments appreciated, this is a first
draft:
http://conveyor.com/RESTwiki/moin.cgi/OpacityReconsidered
jb
Short answer; because you want as much meaning as possible to be explicit, not implicit. Every piece of meaning that is implicit about a URI (if it were not opaque) is information that can not be easily used for automation by a machine. Practically though, as long as there is a fixed amount of non-opaque information that never ever grows, you're ok because understanding it can be hardcoded in. But if you want to add stuff over time, then each time you do all the existing agents out there trying to automate stuff, will need upgrading. Best to keep the URI opaque, and build the meaning up on the Semantic Web. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I don't think that the opacity axiom was ever intended to be at odds with guessability and readability. I've never seen Tim B-L, Fielding, etc. propose that random numbers would be better than human readable strings. As far as Construcability, you say: "A listing of /proc would reveal a set of directories represented processes, each named by the PID of the process they are associated with." That's just the point!!! Given /proc, a computer program should navigate to processes by looking at the *listing* (the entity body) rather than guessing PIDs! That's using "hypertext (links) as the engine of application state". You say: "Reading the n/status file yields the current status of the process, while writing to n/ctl would send a message to the process, etc." On the web, we would use strongly typed hyperlinks so that the name "status" or "mem" would be irrelevant: <status href="status"/> <mem href="mem"/> And here's where the power comes in... <status href="http://www.some.other.site.com/status"/> In a file system you could do that with a symlink. Symlinks (redirects) are a pain to maintain and computational expensive on the Web so it makes more sense to use strongly typed links. Opacity is freedom. Renounce your heresy! "Web archiving is one example where computability of URI is useful and important." Well that's what query parameters are for. There is an exception to URI opacity in the web architecture already. So I'm sorry but I don't see much to reconsider in opacity. URIs should be human readable and guessable. Yes, but that isn't in conflict with the opacity principle. URIs should sometimes be constructable from a base and parameters (though probably not deconstructable). Yes, but that isn't in conflict with the opacity principle. I still think it is a big mistake for *programs* to either deconstruct or guess URIs. Paul Prescod
> I'm curious how one would model workflow with something like this. > Traditional OO often uses state machines as part of modelling such a > solution, whereas (based on comments I've heard here, on the REST wiki, and > on xml-dev) REST encourages the use of resources to model steps in a > workflow. Presumably, where necessary, one would use transient resources > that expire when the workflow is complete, or a step in the workflow that > invalidates this resource is taken. Would it make sense to have an archetype > in the taxonomy for such resources? Excellent question. Yes, I believe so. It would be quite simple too, basically; :Process rdfs:subClassOf :Container I just posted an XML based example of a workflow[1]. It could easily be RDF-ized, and use this class. I'm going over DAML-S[2] right now, checking to see how it might relate to what I've done. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0048.html [2] http://www.daml.org/services/daml-s/2001/10/ MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > Short answer; because you want as much meaning as possible to be > explicit, not implicit. Every piece of meaning that is implicit > about a URI (if it were not opaque) is information that can not be > easily used for automation by a machine. Sorry, that's just not true, though it's a common argument for opacity. As I point out in the write-up,UNIX has a long and profitable history of using synthetic filenames constructed according to particular, explicitly documented conventions to do just that, i.e. automate certain things. Consider construction of names for things in /dev; consider the fact that ps on many modern UNIXes is a shell script that operates by constructing names and accessing files according to a particular set of conventions on /proc. What's more, opacity by itself doesn't guarantee automation any more than non-opacity breaks it. > Practically though, as long as there is a fixed amount of non-opaque > information that never ever grows, you're ok because understanding it > can be hardcoded in. But if you want to add stuff over time, then each > time you do all the existing agents out there trying to automate stuff, > will need upgrading. This isn't true, either --- unless you assume that the grammars and semantics of these names aren't made explicit. The whole process can be fully automated by providing a generative grammar for names and some semantic description for said names. Granted that you want to make everything as explicit as possible. But our focus on using markup to encode all of this stuff is somewhat historical and cultural. Upon further reflection and investigation, it's not at all clear that this is preferable to using generative grammars for construction of names in semantically-rich namespaces. > Best to keep the URI opaque, and build the meaning up on the Semantic > Web. Yes, that's the dogma. But looking at the relative complexity of, say, the implementation of the PS shell script on a UNIX box with /proc and the implementation of something to grok Semantic Web stuff has me wondering. Perhaps giant stringy webs of RDF aren't the easiest, most useful, or best ways to get to some of the same functionality. jb
Jeff Bone wrote: > >... > > Sorry, that's just not true, though it's a common argument for opacity. As > I point out in the write-up,UNIX has a long and profitable history of using > synthetic filenames constructed according to particular, explicitly > documented conventions to do just that, i.e. automate certain things. You also point out in the article that it doesn't always work. I've added a comment to expand on that to the Wiki. > Consider construction of names for things in /dev; consider the fact that > ps on many modern UNIXes is a shell script that operates by constructing > names and accessing files according to a particular set of conventions on > /proc. What's more, opacity by itself doesn't guarantee automation any > more than non-opacity breaks it. A shell script does something like: print /proc/$pid/status A web script (e.g. XSLT) would do something like "print traverse($pid/status)" The difference is that in the former status is a file name. In the latter it is an element type name. When we have an RDF equivalent to shell scripts and xpaths it will be similarly clear using RDF. >... > This isn't true, either --- unless you assume that the grammars and > semantics of these names aren't made explicit. The whole process can be > fully automated by providing a generative grammar for names and some > semantic description for said names. Why invent something extra when markup works?!?! > ... Granted that you want to make > everything as explicit as possible. But our focus on using markup to > encode all of this stuff is somewhat historical and cultural. Upon further > reflection and investigation, it's not at all clear that this is preferable > to using generative grammars for construction of names in semantically-rich > namespaces. Yes it is. The virtue of markup is that it embeds hyperlinks that can go *anywhere on the web*. Hierarchical names are necessarily hosted from the same machine (or at least there must be a redirect on the same machine). That's why the web is different than a file system. (I added this point to the Wiki also) > > Best to keep the URI opaque, and build the meaning up on the Semantic > > Web. > > Yes, that's the dogma. But looking at the relative complexity of, say, the > implementation of the PS shell script on a UNIX box with /proc and the > implementation of something to grok Semantic Web stuff has me wondering. > Perhaps giant stringy webs of RDF aren't the easiest, most useful, or best > ways to get to some of the same functionality. I think you're reverting to something you're comfortable with. If you use XPath or an RDF query language you can get the same benefits without the inflexibility of centralization. Paul Prescod
Let me try another strategy. Let's say you want to move a resource. On Unix, you use a symlink, but you are restricted to file systems that have been mounted. In a standard OS address space you need to account for the indirection in advance and you can only redirect to objects in the same address space. On the Web, you can account for the indirection in advance by indirecting *through markup* and you can redirect to any resource anywhere. You can also account for redirection after the fact using HTTP status codes but this is quite inefficient and will probably break some client software. Paul Prescod
Paul Prescod wrote: > Opacity is freedom. Renounce your heresy! Now see, this is what I'm talking about re: dogma. I seriously doubt you and Mark have bothered to carefully read through that monster before starting in with the indoctrination. Don't bother, I'm indoctrinated, but I'm questioning some of the basic precepts; I'm down with most of this stuff, I just don't buy the fish-on-Friday argument --- and I've documented why! Perhaps you could be bothered to read it first so that I don't have to re-address questions or comments here that are already dealt with in the document? Then we could discuss the specific and useful points rather than simply writing off the whole endeavor as dogmatically inappropriate? ;-) > "Web archiving is one example where computability of URI is useful and > important." Well that's what query parameters are for. There is an > exception to URI opacity in the web architecture already. But this is problematic! I *should* be able to e.g. use my caching proxy to cache /archive/2001/09/11 or whatever! Shoving things into the query string isn't a good answer, each of those objects should be reified as a resource and addressible via URI. THAT's what REST is about, IMO: making everything interesting referenceable. > So I'm sorry but I don't see much to reconsider in opacity. URIs should > be human readable and guessable. Yes, but that isn't in conflict with > the opacity principle. It depends on how stringently you apply it. There's very little guidance. TBL seems to have some informal notions of what makes "good" vs. "bad" URI, but that's far from normative. > URIs should sometimes be constructable from a > base and parameters (though probably not deconstructable). Yes, but that > isn't in conflict with the opacity principle. Again, it depends on how stringently you apply the principle. It's a widely-misunderstood principle, I think, even potentially misunderstood by its author. It's good to have a "principled" design and architecture for the Web, but those principles should be meaningful. In this case, I think the principle was derived in an ad-hoc fashion by some specific failures (i.e., content types from extensions) early on, and is overly general. > I still think it is a big > mistake for *programs* to either deconstruct or guess URIs. Why? If I provided you with (RDF, whatever) that formally defined the structure of names on my site and your code could deduce from that / automatically generate meaningful names, why is this a bad thing? Enough dogma. Check your premises! ;-) Bottom line: the Web insists on opacity --- there are no names, only identifiers. Everywhere else that syntactically similar entities are used, the trend has been to increase rather than decrease the semantic richness of the namespace. Why the discrepancy? Smart people exist in both communities; a reasonable person looks at this discrepancy and attempts to understand what's going on here. jb
Jeff Bone wrote: > > Paul Prescod wrote: > > > Opacity is freedom. Renounce your heresy! > > Now see, this is what I'm talking about re: dogma. I seriously doubt you and > Mark have bothered to carefully read through that monster before starting in > with the indoctrination. I did read it. I've even gone through and added my comments inline. I'm happy to have sacred cow barbeque but I think the web architecture already anticipates all of your concerns. >... > > "Web archiving is one example where computability of URI is useful and > > important." Well that's what query parameters are for. There is an > > exception to URI opacity in the web architecture already. > > But this is problematic! I *should* be able to e.g. use my caching proxy to > cache /archive/2001/09/11 or whatever! Er, who said you can't cache things in query strings? > .. Shoving things into the query string > isn't a good answer, each of those objects should be reified as a resource > and addressible via URI. The query string *generates* a URI. I'm totally not following you. Here's a URI that is both cacheable and addressable using query strings: http://www.google.com/search?hl=en&q=everything+old+is+new+REST >... > It depends on how stringently you apply it. There's very little guidance. > TBL seems to have some informal notions of what makes "good" vs. "bad" URI, > but that's far from normative. Okay, but its a user interface issue, NOT a software architecture issue. I strongly encourage you to write a web page about good URI naming conventions. But I also encourage you to separate it from the heresy about /proc. ;) > > URIs should sometimes be constructable from a > > base and parameters (though probably not deconstructable). Yes, but that > > isn't in conflict with the opacity principle. > > Again, it depends on how stringently you apply the principle. The page where the principle is described also describes its appropriate limits: "Query strings are clearly not opaque to the client. However, they should be opaque to (for example) proxies." >... > Why? If I provided you with (RDF, whatever) that formally defined the > structure of names on my site and your code could deduce from that / > automatically generate meaningful names, why is this a bad thing? #1. Because of the redirection problem. #2. Because now you have two ways to do the same thing: using hyperlinks and using semantic URIs. What benefit does the latter provide? #3. Because now you are restricted in your naming conventions so that it becomes difficult to make names in French and German that are functionally equivalent to the english names. Does Red Flag linux handle the Chinese word for /proc and /proc/pid/status? If so, what happens to your ps script. If not, then you've sacrificed guessability. >... > Bottom line: the Web insists on opacity --- there are no names, only > identifiers. Everywhere else that syntactically similar entities are used, > the trend has been to increase rather than decrease the semantic richness of > the namespace. Why the discrepancy? Smart people exist in both > communities; a reasonable person looks at this discrepancy and attempts to > understand what's going on here. #1. The web people have this problem where the "file system" is global and they want any link to be able to point at any server. #2. The price of double or triple or quadruple dereferencing a file name is cheap compared to the price of parsing markup in a file system. Whereas the price of parsing markup is trivial on the web compared to the price of following one redirect to another redirect to another redirect etc. Better to plan for the need to move things in advance by "indirecting" through markup. #3. The web people just dig markup more. Paul Prescod
Paul Prescod wrote: > >... > > This isn't true, either --- unless you assume that the grammars and > > semantics of these names aren't made explicit. The whole process can be > > fully automated by providing a generative grammar for names and some > > semantic description for said names. > > Why invent something extra when markup works?!?! You're not. You're defining grammatical conventions on already-existing names in the same manner that you specify other sorts of things in markup. It's not an either-or, it's a both-and. There are things that the name-based mechanism allows which can't be done via markup topology... consider a Web crawler that simply wants to crawl across every available page on my site --- *including the one which isn't linked to by any other page.* Name-based conventions *may* allow you to find that object. With markup topology, you'll never find it. Hey, that's a subtle but good point, IMHO. ;-) There's something deep lurking there. > Hierarchical names are necessarily hosted from > the same machine (or at least there must be a redirect on the same > machine). That's why the web is different than a file system. (I added > this point to the Wiki also) This is baloney, too --- but again a commonly offered argument. There's absolutely nothing that says that distributed filesystems cannot be multi-rooted and have global names. Indeed, in a stunning demonstration of the ToII, the SMB / CIFS filesystem's names (UNC names) and URIs look so much alike that *a trivial encoding of UNC names as URI is possible just by replacing '\' with '/'. > I think you're reverting to something you're comfortable with. Possibly. Or perhaps its the lack of familiarity on the part of others of current filesystem research and their relatively greater comfort level with markup technologies that causes them to (a) see nonexistent limitations and problems with semantically-rich naming schemes and (b) seek to compensate for this with markup technologies. Which is it? I don't know, that's what I'm trying to find out. I've floated back and forth between these two communities for a long time, and I prima facie the Opacity Principle seems just as silly to me as the filesystem guys' perpetual insistence on block-level IO and caching. My investigation of these issues is driven by familiarity with the work of Michael McClennen, Stu Sechrest, Hans Reiser, Bal Krishnamurthy, the Plan 9 guys, and others who have at various times in the past decade worked on enriching the semantics of file naming. If you're arguing that the whole endeavor is worthless, you're indirectly arguing with some very smart guys. Indeed, you're telling Rob Pike, Dave Presotta, Ken Trickey, and some other very smart guys that they've wasted most of their careers. If, on the other hand, you criticize the Opacity Principle, you're just telling Tim that he might have overstated a particular point and telling the rest of us to lighten up and think about how we interpret those axioms. Again my question: why the polar opinion about semantics in names? jb
Paul Prescod wrote: > Let me try another strategy. Let's say you want to move a resource. This indicates a limited view of filesystems. In a hypothetical semantic filesystem, the operation is conceptually similar operation to what you do on the Web. With rich names, names are queries. "Moving" a file isn't necessarily a valid concept in current filesystem research; rather, you annotate or fiddle with the properties of a file such that the pathname (query) that is used to access it is different. > On > Unix, you use a symlink, but you are restricted to file systems that > have been mounted. Not necessarily. Various research systems have proposed symbolic links that can be remote and are resolved only at access time. > In a standard OS address space you need to account > for the indirection in advance and you can only redirect to objects in > the same address space. Again, there are distributed filesystems with global, multi-rooted namespaces. > On the Web, you can account for the indirection > in advance by indirecting *through markup* And again, this is preferable... why? As opposed, say, to direct manipulation of properties and metadata? And how, really, is that different, anyway? > and you can redirect to any > resource anywhere. You can also account for redirection after the fact > using HTTP status codes but this is quite inefficient and will probably > break some client software. None of this is novel. jb > > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Paul Prescod wrote: > #1. The web people have this problem where the "file system" is global > and they want any link to be able to point at any server. This is not unique to the Web. > #2. The price of double or triple or quadruple dereferencing a file name > is cheap compared to the price of parsing markup in a file system. > Whereas the price of parsing markup is trivial on the web compared to > the price of following one redirect to another redirect to another > redirect etc. Better to plan for the need to move things in advance by > "indirecting" through markup. This I buy. > #3. The web people just dig markup more. That's not good enough. ;-) jb
Jeff Bone wrote: > >... > > You're not. You're defining grammatical conventions on already-existing names in > the same manner that you specify other sorts of things in markup. It's not an > either-or, it's a both-and. There are things that the name-based mechanism > allows which can't be done via markup topology... consider a Web crawler that > simply wants to crawl across every available page on my site --- *including the > one which isn't linked to by any other page.* Geez, just link it! Use a <link> tag in HTML if you want something simple. > ... Name-based conventions *may* allow > you to find that object. With markup topology, you'll never find it. Setting up the conventions in a machine readable form will be more work than setting up the link. >... > > Hierarchical names are necessarily hosted from > > the same machine (or at least there must be a redirect on the same > > machine). That's why the web is different than a file system. (I added > > this point to the Wiki also) > > This is baloney, too --- but again a commonly offered argument. There's > absolutely nothing that says that distributed filesystems cannot be multi-rooted > and have global names. Indeed, in a stunning demonstration of the ToII, the SMB > / CIFS filesystem's names (UNC names) and URIs look so much alike that *a trivial > encoding of UNC names as URI is possible just by replacing '\' with '/'. You say its baloney but you haven't shown me how I can serve http://www.myprocesses.com/proc/5323/status from http://www.yourprocesses.com. I'd have to set up an HTTP redirect which is expensive both from a maintenance and a performance point of view. It's cheap in a standard file system. >... > Possibly. Or perhaps its the lack of familiarity on the part of others of > current filesystem research and their relatively greater comfort level with > markup technologies that causes them to (a) see nonexistent limitations and > problems with semantically-rich naming schemes and (b) seek to compensate for > this with markup technologies. Which is it? I don't know, that's what I'm > trying to find out. I've floated back and forth between these two communities > for a long time, and I prima facie the Opacity Principle seems just as silly to > me as the filesystem guys' perpetual insistence on block-level IO and caching. Different scale problems have different performance characteristics. If file system guys tell me that block-level IO is required to get the performance they need then I'll believe them until I have reason to believe otherwise. > My investigation of these issues is driven by familiarity with the work of > Michael McClennen, Stu Sechrest, Hans Reiser, Bal Krishnamurthy, the Plan 9 guys, > and others who have at various times in the past decade worked on enriching the > semantics of file naming. If you're arguing that the whole endeavor is > worthless, you're indirectly arguing with some very smart guys. Indeed, you're > telling Rob Pike, Dave Presotta, Ken Trickey, and some other very smart guys that > they've wasted most of their careers. One way of looking at it is that the file system has different requirements, especially when it comes to performance and user interface. Note that the file system names are a primary user interface to information navigation, even on GUI-centric platforms. URIs are at best a secondary or tertiary user interface compared to markup and browser controls. Another way of looking at it is that the semantic web could make a lot of that work obsolete if people started navigating by something other than names. Whoa! Surfing the web in rdfsh or xpathsh...there's an interesting idea. > ... If, on the other hand, you criticize the > Opacity Principle, you're just telling Tim that he might have overstated a > particular point and telling the rest of us to lighten up and think about how we > interpret those axioms. The opacity principle is important precisely because URIs are so human readable and people feel that when they model URIs they are modeling the application. But when they do that they generally aren't taking into account the indirection and discoverability issues. Yes, we could build a parallel system that makes names more discoverable and we could use HTTP redirects for indirection. But *to what end*? I think you'll reduce the human readability of URIs if you start turning them into code objects deconstructed by programs. IMO, the opacity principle works well both in practice and in theory. Paul Prescod
Jeff Bone wrote: > > Paul Prescod wrote: > > > #1. The web people have this problem where the "file system" is global > > and they want any link to be able to point at any server. > > This is not unique to the Web. It isn't unique to the Web but it is the fundamental organizational principle of the Web. File systems tend to think first about local data and then about making remote data look like local data. > > #2. The price of double or triple or quadruple dereferencing a file name > > is cheap compared to the price of parsing markup in a file system. > > Whereas the price of parsing markup is trivial on the web compared to > > the price of following one redirect to another redirect to another > > redirect etc. Better to plan for the need to move things in advance by > > "indirecting" through markup. > > This I buy. Great. Then we agree. ;) > This indicates a limited view of filesystems. In a hypothetical semantic > filesystem, the operation is conceptually similar operation to what you do on > the Web. With rich names, names are queries. "Moving" a file isn't > necessarily a valid concept in current filesystem research; rather, you > annotate or fiddle with the properties of a file such that the pathname > (query) that is used to access it is different. Fiddling the markup is like fiddling the metadata for the file. Given the pseudo-resource http://www.foo.com/processes#xptr(/status/@href) I "move" the pseudo-resource by changing the value of the href attribute. I use the term pseudo-resource, not resource, because the actual resource identified by the link changes when I update the href. Anyhow, at the URI (not markup) level, the web is not a query-centric system it is an address-centric system. We find things first and foremost through a domain name and an associated IP address. A decent distributed file system would rather not expose the machine name or IP address for files. So URIs should be viewed as more like the book-keeping identifier that the file system uses (inode) and less like the file name. Paul Prescod
Mark Baker wrote: > > This is exactly right --- and this is part of what I was talking about a while > > back -wrt- the addressibility of resources vs. representations. You can't ever > > address representations directly. > > Well, you SHOULD be able to, viz a viz the requirement that the > Content-Location header SHOULD be returned when multiple representations > exist for the same resource. Granted, but they aren't first-class in that they aren't identified by name i.e. URI. (Generally speaking this isn't a problem, but it makes certain things more difficult in caching and archiving. Like many things in the Web, it's one of those things with some small disadvantage but from which a lot of benefit comes.) jb
----- Original Message ----- From: "Mark Baker" <distobj@...> > > but what about this; > > "set salary = 40000 where level=4" > > Now, the issue is, I think, if we have a URI representing "all salaries > for level 4 employees", then this is a set, i.e. a container. My > interpretation of REST suggests that in order to PUT to a container, > you have to replace the entire state of the container. So saying > "PUT <40000>" to that URI is a mismatch. It should be "PUT <40000, > 40000,40000,40000 ...>". > I don't see a requirement that the 'new' state of a collection have the same number of application specific records. The collection can be malleable in that it can take a single value and apply it to many managed items - which is exactly what that SQL statement does. It doesn't nuke the records, it updates the values from a single input value. The input value to the SQL statement is not a temp table to be copied - it is a 'representation' not a 'resource'. Of course if PUT requires a 'resource' as input, then you're hosed. If the collection is defined to be a 'view' (as I think DanC said in the IRC log) the reading and writing don't have to be one-to-one. Of course, write-back is a bitch for any one-to-many or many-to-one mapping. (as RoyF will find out at his new day job)
Jeff Bone wrote: > Paul Prescod wrote: > > > #2. The price of double or triple or quadruple dereferencing a file name > > is cheap compared to the price of parsing markup in a file system. > > Whereas the price of parsing markup is trivial on the web compared to > > the price of following one redirect to another redirect to another > > redirect etc. Better to plan for the need to move things in advance by > > "indirecting" through markup. > > This I buy. Actually, on second thought, I don't buy this argument --- at least not as an argument about opacity. Both the Web and certain modern distributed filesystems can handle movement of resources to nonlocal environments through redirection; the 3xx HTTP codes have analogs in SMB, in NFS+autofs environments, and elsewhere. The ability to redirect through markup is unique to the Web, but it is a decidedly *unRESTful* and HTTP-unfriendly concept. Consider: One of the original goals of the Web was to be generally agnostic about the content that it transported. We've moved away from that, and that's perhaps a bad thing. Where the abstractions-of-interest in REST / HTTP are resources and their associated coordination language, the abstractions-of-interest in the Semantic Web are hypertext topologies and metadata. Whereas the REST purist way to handle relocation of resources is (correctly, IMO) through the 3xx codes, a markup-based mechanism requires that any client understand the markup language and redirect conventions. Anyway, this is another red herring --- neither an argument for opacity nor an advantage of the Web over other distributed filesystems. The point of this endeavor isn't to claim that distributed filesystems are in some sense superior to the Web or what have you; it's rather to debug some incorrect assumptions and assertions that are generally made in support of opacity. $0.02, jb
Maybe the easiest way to drill down on this is for my to challenge your assertion that it's a good idea for sites to agree on what /search, /help, and /contact mean. Clearly it would be a good idea for lots of different types of web sites to have a common notion of "search", "help", and "contact". That way, an agent could locate do things like summarize all the contacts for me, and correlate that with their postings to alt.sex. But the issue is, what's the best way to do this? One obvious way, which you seem to suggest, is for everybody to share the same relative name for it. The major problem with this though, is that a software agent wouldn't know whether a web site was following these rules, or if they just happened to have a page named /contact. It is absolutely key that names not be standardized, because it means that there has to be some central authority that ensures that names don't conflict. After 20 years of people doing this, you literally would have to check with somebody to ensure that it's ok for you to publish /foo/bar/baz, lest somebody else has already defined what that means. The opacity-friendly way of doing this would be to assert a relationship between the main site and the URI it uses for the concepts of "contact", "help", and "search". For example, a GET on http://foo.com could return some N3 asserting; @prefix chs: <http://jbone.net/contact-help-search> </admin/help/> a chs:Help . </search/> a chs:Search . </contact-us/> a chs:Contact . Ah yes, the sweet smell of decentralization ... MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker <distobj@a...> wrote: > s/Accept/Accepted Is that a counter-proposal to Mike Dierken's proposal of a Response location where the "Accepted" bits would be part of the response? If so, how would you handle the very common case where there are three possible responses: Accepted, Rejected, or CounterPending. The third meaning that we're still negotiating the deal. (I'm not arguing for or against any proposal here, just trying to understand.) -Bob Haugen
Paul Prescod wrote: > You say its baloney but you haven't shown me how I can serve > http://www.myprocesses.com/proc/5323/status from > http://www.yourprocesses.com. I'd have to set up an HTTP redirect which > is expensive both from a maintenance and a performance point of view. > It's cheap in a standard file system. Sorry, let me clarify. The point isn't that your claimed limitation does not exist --- it does --- but rather that the same problem and essentially the same solution exists on the Web and in several common distributed environments. The claim that the problem (or solution) is unique to the Web is the fallacious part. > > Possibly. Or perhaps its the lack of familiarity on the part of others of > > current filesystem research and their relatively greater comfort level with > > markup technologies that causes them to (a) see nonexistent limitations and > > problems with semantically-rich naming schemes and (b) seek to compensate for > > this with markup technologies. Which is it? I don't know, that's what I'm > > trying to find out. I've floated back and forth between these two communities > > for a long time, and I prima facie the Opacity Principle seems just as silly to > > me as the filesystem guys' perpetual insistence on block-level IO and caching. > > Different scale problems have different performance characteristics. If > file system guys tell me that block-level IO is required to get the > performance they need then I'll believe them until I have reason to > believe otherwise. I've been living in that world for the last year or so, and one of the things that's frustrated me has been this very thing. One of the best-performing filesystems around in the last decade or so was derived from Andy Tannenbaum's Bullet File System --- and it was very RESTlike in some ways. Whole objects were operated on and semantic naming was separated from and dynamically mapped to identifiers for immutable stored objects. Unf., this is "too weird" for most filesystem guys, despite all sorts of compelling, quantitative data to the contrary. > One way of looking at it is that the file system has different > requirements, especially when it comes to performance and user > interface. With respect to the former, a *wide area* filesystem (such as the Web and various others) has different performance characteristics than a local filesystem, a clustered filesystem, etc. If you really think there are significant differences, come up with some of these different requirements and I'll come up with pointers to distributed filesystem research which specifically address them. Otherwise, the "oh, it's just a different problem domain" argument is just FUD. > Note that the file system names are a primary user interface > to information navigation, even on GUI-centric platforms. URIs are at > best a secondary or tertiary user interface compared to markup and > browser controls. I don't buy this one, either. I hear this "GUI" orientation alot, especially from the hypertext enthusiasts. The Web is a hypertext medium, but it shouldn't be a hypertext medium *at the expense of being a universal information space and coordination language.* > Another way of looking at it is that the semantic web could make a lot > of that work obsolete if people started navigating by something other > than names. Whoa! Surfing the web in rdfsh or xpathsh...there's an > interesting idea. I've been hoping for something along those lines for a while. For the life of me, though, I have a hard time finding simple syntaxes for interactive use of Web resources themselves, much less navigating around complex graph topologies. (And yeah, XPath *is* nice. It's necessary, but not sufficient.) > The opacity principle is important precisely because URIs are so human > readable and people feel that when they model URIs they are modeling the > application. Well, I don't think I believe that. Look at all the yucky, unfriendly URI out there. That happens precisely because people *don't* model their URI well enough, and many I've talked to use "opacity" as an excuse. > Yes, we could build a parallel system that makes names more discoverable > and we could use HTTP redirects for indirection. (a) We already use HTTP for redirects, and when we don't we introduce unpleasant dependencies between clients and particular markups. (b) I'm not suggesting a parallel system, any more than WRDL is a parallel system to RDF. Like the latter, what I am suggesting is a specific tool for a specific purpose. > But *to what end*? I > think you'll reduce the human readability of URIs if you start turning > them into code objects deconstructed by programs. I seriously doubt it; probably what would happen would be that a commonality of tools and conventions would appear, which would create more uniformity and better URIs everywhere. jb
Paul Prescod wrote: > Jeff Bone wrote: > > > > Paul Prescod wrote: > > > > > #1. The web people have this problem where the "file system" is global > > > and they want any link to be able to point at any server. > > > > This is not unique to the Web. > > It isn't unique to the Web but it is the fundamental organizational > principle of the Web. File systems tend to think first about local data > and then about making remote data look like local data. This is a generalization about "file systems" that isn't very useful, Paul. Distributed filesystems as well as many local filesytems have as their fundamental organizational principle exactly analogous global namespaces. Failure to recognize this (and don't feel singled out, Roy F. didn't recognize this until I encouraged him to take another look at Plan 9) is one of those areas where Web folks are just underinformed about the goals and current state of the art in filesystems. > Anyhow, at the URI (not markup) level, the web is not a query-centric > system it is an address-centric system. This is another way of restating the premise, which is that URI are opaque, that they are identifiers rather than semantic names. I'm not contesting that this is the dogma, I'm questioning its value as dogma. I've thought a lot about this, and I can't think of any good reasons why this should be so. If you can tell me one, I'll be quite interested. > We find things first and > foremost through a domain name and an associated IP address. A decent > distributed file system would rather not expose the machine name or IP > address for files. That depends on the goals of the distributed filesystem. The two most widely used "distributed" filesystems (SMB / CIFS and NFS+autofs) use an exactly analogous machine + path style of naming. > So URIs should be viewed as more like the > book-keeping identifier that the file system uses (inode) and less like > the file name. Yes, and that's damned unfortunate. It's also a bit of an inconsistency in the goals and requirements for URI --- we need to figure out whether we want URI to be friendly to humans and their software tools or to be convenient for Web plumbing builders. I don't know about you, but I can't remember the last time I interacted with a file via inode number. jb
> Mark Baker <distobj@a...> wrote: > > s/Accept/Accepted > > Is that a counter-proposal to Mike Dierken's proposal of a Response > location where the "Accepted" bits would be part of the response? No no, just that in HTTP, "Accepted" is the 202 response, and "Accept" is the request header used to request content negotiation by media type. > If so, how would you handle the very common case where there are > three possible responses: Accepted, Rejected, or CounterPending. The > third meaning that we're still negotiating the deal. If I've followed the discussion so far, all of those are states of a resource, and so should be carried over 2xx responses. Just as HTTP's methods apply to all resources, so does its response codes - they have to remain generic. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote:
> One obvious way, which you seem to suggest, is for everybody to share
> the same relative name for it. The major problem with this though, is
> that a software agent wouldn't know whether a web site was following
> these rules, or if they just happened to have a page named /contact.
The problem and solution are both the same in the Web case and in the local
operating system file structure case. How, when I run a script on a machine,
can I be sure that /proc is the process psuedofile system and not a directory
that just happened to be named /proc? In the OS case, it's because I can
somehow obtain, hopefully programatically, some assurance that the
environment conforms to some standard --- in this case, I can tell I'm
running on (say) Plan 9 and therefore can expect /proc to be organized in and
behave a certain way, the "standard" defined by Plan 9. In the Web case, one
assumes there would be some resource supported by the site which would
indicate that it conformed to
http://directory.nameschemes.com/SemNameCore/2002
or whatever.
> It is absolutely key that names not be standardized, because it means
> that there has to be some central authority that ensures that names
> don't conflict.
This doesn't make any sense. There's no difference in "standardizing"
certain generative grammars for generating resource names and "standardizing"
certain XML schemas for various purposes. Neither requires a centralized
authority; both merely require that naming schemes and their associated
semantics are themselves distinguishable via URI.
> The opacity-friendly way of doing this would be to assert a relationship
> between the main site and the URI it uses for the concepts of "contact",
> "help", and "search". For example, a GET on http://foo.com could
> return some N3 asserting;
>
> @prefix chs: <http://jbone.net/contact-help-search>
> </admin/help/> a chs:Help .
> </search/> a chs:Search .
> </contact-us/> a chs:Contact .
More or less. I'm not arguing that such information shouldn't be provided;
indeed, I'm piddling around with trying to figure out if RDF or other
XML-based mechanisms can reasonably be used to construct generative grammars
of the type I'm talking about.
jb
Paul Prescod wrote: > Jeff Bone wrote: > > > > consider a Web crawler that > > simply wants to crawl across every available page on my site --- *including the > > one which isn't linked to by any other page.* > > Geez, just link it! Use a <link> tag in HTML if you want something > simple. BTW, I'll point out that this unduly biases the Web towards hypermedia which support such linking, and unduly burdens *all* clients with understanding particular markup languages. It's an example of creeping hypermedia-ness of the Semantic Web that, on some level, is absent from the REST / generic universal information space / HTTP purist's point-of-view. The Web is HTTP, not HTML or XML. jb
Jeff Bone wrote: > >... > > BTW, I'll point out that this unduly biases the Web towards hypermedia which support > such linking, and unduly burdens *all* clients with understanding particular markup > languages. It's an example of creeping hypermedia-ness of the Semantic Web that, on > some level, is absent from the REST / generic universal information space / HTTP > purist's point-of-view. The Web is HTTP, not HTML or XML. "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." * http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Paul Prescod
Jeff Bone wrote: > >... > That depends on the goals of the distributed filesystem. The two most widely used > "distributed" filesystems (SMB / CIFS and NFS+autofs) use an exactly analogous > machine + path style of naming. You are constantly moving the goal posts. You talk about the design decisions in Plan9 or ReiserFS and then when I point out that the Web isn't quite like them you point out that the Web has some features in common with SMB/CIFS. We'll go in circles forever that way. Yes, if you take the union of all features of all file systems and pick and choose then you may get something that looks like the Web. But if you want to claim that the Web should learn from the design decisions made in file systems then you have to choose one or two logically similar file systems and demonstrate that the problem domain is similar. I've not noticed that SMB/CIFS use semantically meaningful names much other than lpt1: so I don't see how they are relevant to your argument. In fact, the Windows operating system encourages application designers to dereference names through the registry and ignore the actual file names. So we dereference through markup. They dereference through a binary database that constantly gets corrupted. Both use opaque identifiers. Paul Prescod
Paul Prescod wrote:
> Er, who said you can't cache things in query strings?
I assume you mean things with query strings. My info is a bit dated, but IIRC
(from proxy work circa '94-'95) it used to be considered bad form for various
reasons for proxy caches to cache "objects" (representations of resources)
identified with URI that had query strings. Maybe this isn't the case anymore;
indeed, if the entire piece is considered as an opaque whole, on further
consideration I'm not sure why this would be problematic. OTOH, its a bit
semantically muddled; does the query string identify the resource or not? I.e.,
do the following refer to the same _resource_ or not?
http://foo.com/some/resource
http://foo.com/some/resource?p1=foo&p2=bar
jb
> The problem and solution are both the same in the Web case and in the local > operating system file structure case. How, when I run a script on a machine, > can I be sure that /proc is the process psuedofile system and not a directory > that just happened to be named /proc? In the OS case, it's because I can > somehow obtain, hopefully programatically, some assurance that the > environment conforms to some standard --- in this case, I can tell I'm > running on (say) Plan 9 and therefore can expect /proc to be organized in and > behave a certain way, the "standard" defined by Plan 9. In the Web case, one > assumes there would be some resource supported by the site which would > indicate that it conformed to > > http://directory.nameschemes.com/SemNameCore/2002 > > or whatever. Ok, so in asserting that, why not reuse that same mechanism to assert what the URIs are? > > The opacity-friendly way of doing this would be to assert a relationship > > between the main site and the URI it uses for the concepts of "contact", > > "help", and "search". For example, a GET on http://foo.com could > > return some N3 asserting; > > > > @prefix chs: <http://jbone.net/contact-help-search> > > </admin/help/> a chs:Help . > > </search/> a chs:Search . > > </contact-us/> a chs:Contact . > > More or less. I'm not arguing that such information shouldn't be provided; > indeed, I'm piddling around with trying to figure out if RDF or other > XML-based mechanisms can reasonably be used to construct generative grammars > of the type I'm talking about. You need to use query parameters. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > > Paul Prescod wrote: > > > Er, who said you can't cache things in query strings? > > I assume you mean things with query strings. My info is a bit dated, but IIRC > (from proxy work circa '94-'95) it used to be considered bad form for various > reasons for proxy caches to cache "objects" (representations of resources) > identified with URI that had query strings. Yes, it was bad form for HTTP 1.0, but not HTTP 1.1: "We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache" > ... Maybe this isn't the case anymore; > indeed, if the entire piece is considered as an opaque whole, on further > consideration I'm not sure why this would be problematic. OTOH, its a bit > semantically muddled; does the query string identify the resource or not? I.e., > do the following refer to the same _resource_ or not? > > http://foo.com/some/resource > http://foo.com/some/resource?p1=foo&p2=bar No. I have seen nothing to indicate that they refer to the same resource. URIs address unique identifiers unless some spec says otherwise. HTTP doesn't say anything that would indicate to me that those are the same resource: * http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 Paul Prescod
Paul Prescod wrote: > "REST is defined by four interface constraints: identification of > resources; manipulation of resources through representations; > self-descriptive messages; and, hypermedia as the engine of application > state." Fine, yes, this is scripture --- but I'm not sure that the latter follows necessarily, i.e., it's possible that this POV may be overemphasized in some cases. If indeed hypermedia were the *sole* engine of application state, we wouldn't need response codes at all --- all responses would be self-descriptive hypermedia. Now you can claim that this is a difference between the pure REST POV and the Web itself, and you're probably right; but my interest in both REST and the Web is in determining what qualities have contributed to the enormous success of the Web. To the extent that REST diverges from the Web in practice, I begin to lose interest. As a counter to this: "When you design a system, or a language, then if the features can be broken into relatively loosely bound groups of relatively closely bound features, then that division is a good thing to be made a part of the design." --- Principle of Modular Design, Principles of Design, TBL [1] It seems clear that embedding the semantics of state transfer in the transferred hypermedia --- as would be true if hypermedia were truly the engine of all application state --- breaks with the Principle of Modular Design. [1] http://www.w3.org/DesignIssues/Principles.html
Mark Baker wrote: > Ok, so in asserting that, why not reuse that same mechanism to assert > what the URIs are? Because (a) it may be interesting and useful to concisely describe how URI for some given scheme can be constructed and, if constructed, what they mean (b) it may *not* be practical or even possible to e.g. exhaustively list all possible opaque URI constructions from a given scheme. > You need to use query parameters. Explain? jb
Paul Prescod wrote: > You are constantly moving the goal posts. You talk about the design > decisions in Plan9 or ReiserFS ReiserFS isn't a distributed filesystem at all. The lessons from ReiserFS involve embedding semantics in names, not issues of distribution. Plan 9 has (some might say is) a distributed "file" system, but it's so idiosyncratic that it's not a good comparison, here. My point in bringing up different filesystems is to help "you" (or the otherwise dogmatically-afflicted ;-) remedy your misunderstanding that the Web is somehow different from all filesystem-oriented efforts. There's not a single high-level architectural characteristic of the Web that isn't present in some other filesystem effort, distributed or local. (There are admittedly none that have *all* those characteristics.) There's *no good reason* to believe that there's any single thing unique about the Web beyond its default and de facto hypermedia interface and the synthesis it achieves of all its features. Given the similarities, IMO it's fair to draw lessons from any / all filesystems which share some characteristic, goal, or what have you with the Web. Categorically stating that lessons learned elsewhere aren't applicable to the Web because it's special (when it isn't) smacks of a kind of technological provincialism that's frustrating. We should be proud of the Web. We shouldn't be too proud of ourselves. ;-) Let me be clear about my claims: after a fair bit of thought, I've concluded that the strictest statements and interpretations of the Opacity Axiom may be a mistake caused by overgeneralization from early historical problems in the Web's development. To the extent that it has nothing to say contrary to my following assertions, then I'm generally fine with it: * URI should be constructable by human or machine * URI should be meaningfully deconstructable by human or machine * URI designers should be encouraged to build meaningful namespaces > Yes, if you take the union of all features of all file systems and pick > and choose then you may get something that looks like the Web. But if > you want to claim that the Web should learn from the design decisions > made in file systems then you have to choose one or two logically > similar file systems and demonstrate that the problem domain is similar. Well, that's rather silly, isn't it? That's like saying "tell me everything you know about numbers. You may only use the number 2." > I've not noticed that SMB/CIFS use semantically meaningful names much > other than lpt1: so I don't see how they are relevant to your argument. If my CIFS home directory contains, say, \\someserver\jbone\mail\archive\FoRK\1999 then that name is indeed semantically meaningful, and its possible that both humans and software might be able to make some deductions about what other names exist in that hierarchy. Particularly if I give them some guidance on the semantics and generative grammar of that naming scheme as it relates to my information organizational structure. > In fact, the Windows operating system encourages application designers > to dereference names through the registry and ignore the actual file > names. Yes, and what a good idea that turned out to be. ;-) Contrast this with systems where installing an entire piece of software is simply a matter of unpacking a tarball in a directory. jb
Jeff Bone wrote: > > Paul Prescod wrote: > > > > http://foo.com/some/resource > > > http://foo.com/some/resource?p1=foo&p2=bar > > > > No. > > Right, that's my recalibrated understanding. But let me point something out: if this > is true, then query parameters are pretty much useless and a kind of syntactic noise. > If the two URI above don't refer to the same resource "paramterized" differently, then > there's no need at all for '?', '&', or a special treatment of '='. The latter URI > could more simply, uniformly be represented as > > http://foo.com/some/resource/p1=foo/p2=bar The query syntax clearly separates the bits that are opaque from the bits that are client-generated. This allows us to discuss the opacity axiom and still have an escape hatch for when it is not appropriate. Your proposed syntax also suggests a hierarchy that isn't there. What would "p1=foo/../p1=bar" mean? Paul Prescod
Paul Prescod wrote:
> > http://foo.com/some/resource
> > http://foo.com/some/resource?p1=foo&p2=bar
>
> No.
Right, that's my recalibrated understanding. But let me point something out: if this
is true, then query parameters are pretty much useless and a kind of syntactic noise.
If the two URI above don't refer to the same resource "paramterized" differently, then
there's no need at all for '?', '&', or a special treatment of '='. The latter URI
could more simply, uniformly be represented as
http://foo.com/some/resource/p1=foo/p2=bar
jb
Jeff Bone wrote: > > Mark Baker wrote: > > > Ok, so in asserting that, why not reuse that same mechanism to assert > > what the URIs are? > > Because (a) it may be interesting and useful to concisely describe how URI for some > given scheme can be constructed and, if constructed, what they mean Interesting, yes. Useful? You'll have to make the case that it is every more useful except for the following: > ... (b) it may > *not* be practical or even possible to e.g. exhaustively list all possible opaque > URI constructions from a given scheme. > > > You need to use query parameters. > > Explain? Query parameters are for when it is not possible to "e.g. exhaustively list all possible opaque URI constructions from a given scheme." Paul Prescod
Jeff Bone wrote: > > ... There's *no good reason* to believe that there's any single thing > unique about the Web beyond its default and de facto hypermedia interface and the > synthesis it achieves of all its features. It isn't an issue of whether there is any single thing. If you want to apply the design criteria of another system then the basic architecture and requirements have to be similar. That's clearly not true of SMB/CIFS so maybe we could stop talking about it. > ... Given the similarities, IMO it's fair to > draw lessons from any / all filesystems which share some characteristic, goal, or what > have you with the Web. Categorically stating that lessons learned elsewhere aren't > applicable to the Web because it's special (when it isn't) smacks of a kind of > technological provincialism that's frustrating. You haven't actually presented any lessons learned. You've said: "smart people made other choices so maybe they were right." And maybe they were wrong. The benefits you've argued for non-opacity are quite small and you're talking about erecting new schema languages, conventions and interface definition systems to support it. >... > Let me be clear about my claims: after a fair bit of thought, I've concluded that the > strictest statements and interpretations of the Opacity Axiom may be a mistake caused by > overgeneralization from early historical problems in the Web's development. And I think you're wrong. At the very least, the opacity axiom frees the application to physically put its resources where-ever it wants without incurring the cost of an HTTP redirect. It also addresses Mark's issue about standardization. > ... To the > extent that it has nothing to say contrary to my following assertions, then I'm > generally fine with it: > > * URI should be constructable by human or machine > * URI should be meaningfully deconstructable by human or machine > * URI designers should be encouraged to build meaningful namespaces I disagree. Wherever possible, machines should be discouraged from either constructing or deconstructing them. Barring a few weird cases (like censorship proxies) they should be "end-to-end" so that only the producing and consuming applications ever deconstruct them and applications that didn't produce them should not try to deconstruct them. > > Yes, if you take the union of all features of all file systems and pick > > and choose then you may get something that looks like the Web. But if > > you want to claim that the Web should learn from the design decisions > > made in file systems then you have to choose one or two logically > > similar file systems and demonstrate that the problem domain is similar. > > Well, that's rather silly, isn't it? That's like saying "tell me everything you know > about numbers. You may only use the number 2." No, it's saying lets restrict our conversation to systems that are relevant. > > I've not noticed that SMB/CIFS use semantically meaningful names much > > other than lpt1: so I don't see how they are relevant to your argument. > > If my CIFS home directory contains, say, \\someserver\jbone\mail\archive\FoRK\1999 then > that name is indeed semantically meaningful, and its possible that both humans and > software might be able to make some deductions about what other names exist in that > hierarchy. Nobody could prevent you from writing software that does that but it would be poor software design. Of course using human meaningful names is great. But writing software that presumes, for example, that the mailing archive is going to be broken down by years and that the years will reside on the same disk would be poor software design. I already have this problem when I want to move my massive trash folder to a different disk than the other mail messages. > ... Particularly if I give them some guidance on the semantics and generative > grammar of that naming scheme as it relates to my information organizational structure. And how will I get around the fact that my 1999 and 2000 folders just won't fit on the same disk and the \\someserver\ operating system doesn't have a concept of symlinks? > > In fact, the Windows operating system encourages application designers > > to dereference names through the registry and ignore the actual file > > names. > > Yes, and what a good idea that turned out to be. ;-) It's an excellent idea. Thanks to it, I can take my home directory from machine to machine with all of the magical windows setting in it. On one machine its e:\data\profile on another its c:\profile and in theory I could even have one machine get its profile information over the net. Guess what: Unix does the same thing. It is typical to dereference your home directory through one of ~, $HOME or /etc/passwd. Hypertext is the engine of application state. Unix just isn't consistent about it because nobody ever formulated it as an axiom. And because Unix is not consistent about it, you get software that presumes that a particular file is going to be in a particular place. There is no global root way to ask where the file should be so you just have to "know". The reason it can't be an axiom on Unix (or even Windows) is because indirection is annoying and people hate indirection in user interfaces. The file system is a really important user interface in every operating system so people get annoyed if they can only navigate it through indirection. I don't dispute that the opacity principle has a price in simplicity and to a certain extent usability. It compensates in *flexibility*. > ... Contrast this with systems where > installing an entire piece of software is simply a matter of unpacking a tarball in a > directory. You're talking about something totally different. Paul Prescod
> Mark Baker wrote: > > > Ok, so in asserting that, why not reuse that same mechanism to assert > > what the URIs are? > > Because (a) it may be interesting and useful to concisely describe how URI for some > given scheme can be constructed and, if constructed, what they mean (b) it may > *not* be practical or even possible to e.g. exhaustively list all possible opaque > URI constructions from a given scheme. > > > You need to use query parameters. > > Explain? A URI is an odd creature with opaque, semi-opaque, and non-opaque parts. The authority/port part is non-opaque, the path part is opaque, and query parameters are semi-opaque. That is, they are opaque to intermediaries, but are not opaque to clients because they are a way for the publisher to say "put what you want here, I can take it". That's where somebody other than the publisher gets to do guessing. For example, from your Wiki page, you have; http://foo.com/~joeuser/archive/www.att.com/1999/04/19 This would best be; http://foo.com/~joeuser/archive?host="www.att.com"&date="1999/04/19" etc.. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> This is exactly right --- and this is part of what I was talking about a while > back -wrt- the addressibility of resources vs. representations. You can't ever > address representations directly. Well, you SHOULD be able to, viz a viz the requirement that the Content-Location header SHOULD be returned when multiple representations exist for the same resource. I really love that header, as it reifies a Composite pattern that's really necessary if "everything on the Web has a URI". That's why I gave it special attention in RestRDF. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > The existence of a document might imply business acceptance - which is not > > correct. If the business process defines acknowledgement or status documents > > that have 'accepted', 'rejected' and 'undecided' values, then this would be > > fine I think (retrieving the status document tells you if it was actually > > approved). If the business document set doesn't define 'undecided' values > > then the Location header might need to reference a resource that does not > > yet exist - and when it does exist the values within would specify > > 'accepted' or 'rejected'. > > Wouldn't it be legitimate to return "Created" with a Location header in this > case. After all, you did create a resource--the status document you describe > above. Except that then you lose the "Accepted" bit, which is really the most important one. I noticed that 201 didn't include the Location header some time ago, but forgot to bring it up. I think it would be a great idea to include it, as it would permit simpler automation of asynchronous processing with HTTP. Anybody want to raise this with on the HTTP WG mailing list? It might be added to the errata - I consider it an oversight, and I doubt there's any deployment issue with doing it. Another option would be the use the DAV "multistatus" feature where a response includes a XML body that includes multiple response codes. This way it could return both 201 and 202. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Paul Prescod wrote: > It isn't an issue of whether there is any single thing. If you want to > apply the design criteria of another system then the basic architecture > and requirements have to be similar. That's clearly not true of SMB/CIFS > so maybe we could stop talking about it. The amazing thing about SMB/CIFS vis-a-vis the Web isn't that its "basic architecture" (whatever that means, we're talking about names, here) is similar, and I have no visibility to its requirements a priori. The amazing thing about SMB/CIFS is the *almost identical to HTTP URI* naming scheme it employs. It doesn't take much head-scratching to realize that the same problems yield the same solutions, and indeed, the similarity of the two is a rather striking example of the ToII. > You haven't actually presented any lessons learned. Then you haven't read what I've written. ;-) But if you'd prefer to hear it them from other potentially more authoritative sources, go spend a fraction of the amount of time prowling the references I've posted that you (and I, and all of us on this list) have spent studying The Official Cannon. :-) > The benefits you've argued for non-opacity are quite small and > you're talking about erecting new schema languages, conventions and > interface definition systems to support it. Well, there's no reason to believe that the benefits or small, large, or otherwise in the absence of a more detailed investigation of relaxing the opacity axiom. But without such an investigation --- substituting dogma for research --- one can't really speak authoritatively about such things. It seems to me that the Opacity Axiom is overstated and overapplied, and I've documented some few of the many reasons why embedding information in names is in fact useful, not anathema as the dogma states. As for the horrors of new schema languages, conventions, and interface definition systems... WRDL? I rest my case. If you're going to argue, you should at least try not to argue with yourself. ;-) (Sometimes, that's hard --- trust me, I know. ;-) > And I think you're wrong. At the very least, the opacity axiom frees the > application to physically put its resources where-ever it wants without > incurring the cost of an HTTP redirect. It also addresses Mark's issue > about standardization. (a) The redirect issue is a complete red herring, as I've already illustrated. Name opacity has *nothing at all* to do with redirection and relocation. (b) The "standardization" issue is also a red herring, as I've already illustrated. It hardly matters whether what's being "standardized" (let's be more clear, specified by any and all who want to specify such things, independent of any central authority) is N3 notation for ontologies of resources or some other mechanism for specifying generative grammars for names and information organizational conventions. > > * URI should be constructable by human or machine > > * URI should be meaningfully deconstructable by human or machine > > * URI designers should be encouraged to build meaningful namespaces > > I disagree. Wherever possible, machines should be discouraged from > either constructing or deconstructing them. Why? I've heard all the reasons you and others have brought up. They aren't compelling. There are clear existance proofs of the power and utility of semantically meaningful names. The counter-arguments are mostly apocryphal horror stories of certain bad choices made early in the Web's lifecycle. > Barring a few weird cases > (like censorship proxies) they should be "end-to-end" so that only the > producing and consuming applications ever deconstruct them I agree. Proper operation of intermediaries requires that it be possible to treat URI opaquely. This doesn't mean that URI need be absolutely opaque, and says nothing about the producers, consumers, etc. > No, it's saying lets restrict our conversation to systems that are > relevant. I'm not going to argue with you about how to argue, Paul. If you're offended by the plethora of potential learning opportunities I'm providing you, I'm truly sorry. > Nobody could prevent you from writing software that does that but it > would be poor software design. Well, you are in essence asserting that all attempts to embed semantics and use meaningful names to structure systems of resources --- including such incredibly powerful and yet incredibly misunderstood efforts like Plan 9 --- is poor software design. You make this assertion with very little backup, and contrary to the prevailing opinion of some of the world's most influential computer scientists. > Of course using human meaningful names is > great. But writing software that presumes, for example, that the mailing > archive is going to be broken down by years and that the years will > reside on the same disk would be poor software design. It does nothing of the sort. It poses an abstract organization of resources in a quasi-hierarchical namespace. It doesn't at all necessarily assume that the breakdown by years is the only possible naming structure (others might simultaneously exist) or that the objects are going to "reside on the same disk." (Check out NTDFS, AT&T 3DFS, Sun's Translucent File System, the FiST stackable filesystem toolkit, and other filesystems to see why you're wrong in your presumption.) It might be a bad software design if those presumptions were true, but the fact that you make those presumptions simply illustrates a lack of understanding of the flexibility and utility of the filesystem namespace in many modern filesystems. > I already have > this problem when I want to move my massive trash folder to a different > disk than the other mail messages. Yes, no doubt, this is a huge problem. Most workday local filesystems couple the namespace to the underlying storage space in unpleasantly tight ways. This is one of the problems we're addressing at Deepfile. > And how will I get around the fact that my 1999 and 2000 folders just > won't fit on the same disk and the \\someserver\ operating system > doesn't have a concept of symlinks? Simple --- you layer on a stackable filesystem. You then mount up the 1999 filesystem from one place and the 2000 folder from another place into a single virtual parent directory. Voila! It looks like they're in the same place, but they aren't. > > Yes, and what a good idea that turned out to be. ;-) > > It's an excellent idea. Now I know you're broken. ;-) The Windows registry is the worst idea ever, hands down, end of story. It's such a bad idea that getting away from the registry and from "DLL Hell" --- i.e., enabling plug-and-go installation of software just by writing directories and files --- was supposedly one of the original motivations of the research effort that became .NET. > I don't dispute that the opacity principle has a price in > simplicity and to a certain extent usability. Now we're getting somewhere. > It compensates in > *flexibility*. Yes, by *losing* it. > > ... Contrast this with systems where > > installing an entire piece of software is simply a matter of unpacking a tarball in a > > directory. > > You're talking about something totally different. It's part-and-parcel of the same thing. Squint, you can see it. jb
Paul Prescod wrote: > Interesting, yes. Useful? You'll have to make the case that it is every > more useful except for the following: I don't actually have to make the case --- one of the wonderful things about the Web is that, as always, I'm free to ignore whatever parts of the dogma you can't make sense of for me. ;-) Look, I bought the REST ticket, saw the show, got the T-shirt, drank the Kool-Aid, got a bit part in the production, and have even helped sell more tickets to my friends and family. I only have one itty-bitty small problem with the whole thing: after a lot of consideration and a lot of comparitive analysis with other systems that exhibit similar properties in similar contexts, I've concluded the opacity axiom is largely based on unsubstantiated paranoia that stems from overgeneralization from early problems with the (then lack of) Web architecture, and is in general taken far too seriously and literally by many people. That's my opinion, open to change, compelling counterarguments welcome. Even Mark's own "opacity" investigation [1] makes my point for me. We start with the presumption that URI are opaque and "semantics free" in all contexts then proceed to describe how in fact they have parts that have hierarchical and other relationships with each other! The URI spec itself itself, in all its contortions to specify how HTTP-scheme relative URI are to be handled, proves my point! They aren't semantics-free and they aren't opaque, they describe a hierarchical information space supplemented with properties and a flat parameter space. This is a kind of *semantics.* It desribes an *ontology*, albeit rather vaguely. Paul, you aren't going to sway my considered opinion simply by reciting the dogma to me, and none of the arguments you've posed are unfamiliar. Indeed, most of them are dealt with in the writeup. If you want to convince me that URI *are* and *should be* opaque, you need to illustrate that this is true and that dangers abound when you treat them otherwise. For every "dangerous" example you give, I'll be happy to offer a positive, beneficial scenario for using semantically-meaningful names. We'll see who runs out of scenarios first. jb [1] http://www.markbaker.ca/2002/01/UriOpacityInvestigation/ [2] http://www.ietf.org/rfc/rfc2396.txt
Mark Baker wrote: > A URI is an odd creature with opaque, semi-opaque, and non-opaque parts. > The authority/port part is non-opaque, the path part is opaque, and > query parameters are semi-opaque. Another way to put this is that URI are prima facie not opaque entities --- otherwise what is all that grammar doing in RFC2396? They have parts and those parts have syntax, and those parts also have semantic relationships with each other. However, due perhaps to some early failures in putting *inappropriate* information into URI, we've apparently decided as a Web community to chuck the endeavor entirely. And some (at least) among us have done this in relative ignorance of current research regarding semantic naming in other more-or-less analogous contexts. > http://foo.com/~joeuser/archive/www.att.com/1999/04/19 > > This would best be; > > http://foo.com/~joeuser/archive?host="www.att.com"&date="1999/04/19" > etc.. I fail entirely to see why this is objectively preferable to the former. It's got more syntax, that's for sure. ;-) OTOH, a "smart" namespace manager might provide all of the following as potential well-formed synonyms for the object of interest: http://foo.com/~joeuser/archive/www.att.com/1999/04/19 http://foo.com/~joeuser/www.att.com/archive/1999/04/19 http://foo.com/~joeuser/1999/04/19/archive/www.att.com http://foo.com/~joeuser/1999/04/19/www.att.com/archive The Principle of Explicit Transparency ---------------------------------------------- Mark, in your opacity investigation you state that you believe the Opacity Axiom to be fundamental because it forces "publishers to be explicit about the relationships between their resources through any mechanism that allows them to state those relationships." I totally buy that this is desirable... however that doesn't mean that URI cannot be *other* than opaque. How about this for a relaxed statement: "URI are required (modulo existing exceptions to this rule in RFC2396) to be treated by all parties other than publishers as if they were opaque, except when the publisher is explicit about the relationships between those resources and the names they may have through any mechanism that allows them to state those relationships and rules for forming names. In all cases, URI are required to be treated as opaque by any party to an interaction other than the ultimate endpoints involved." I.e., publishers could easily provide to others generative grammars or other mechanisms that would allow them to construct well-formed and meaningful references without a-priori requiring a link to some root in the site's namespace. Indeed, relaxing opacity would allow for easier introduction and proliferation of naming schemes which deviate from the traditional hierarchical containers-and-objects metaphor. The explicit information about the organization of the (name)space could be used to describe the specific relationships of the various syntactic parts, just like RFC2396 does but in a machine-processible fashion. The kinds of problems you were discussing earlier re: mapping to the relational model might be more easily addressed by allowing applications to define what the relationship between parts separated by '/' is intended to be. A particular application might treat these parts as order-independent sets and '/' as set-theoretic intersection, and explicit information about this would allow applications to construct their own "queries" against this namespace. That's my story for tonite, I'm sticking to it. ;-) jb
Paul Prescod wrote: > Your proposed syntax also suggests a hierarchy that isn't there. What > would "p1=foo/../p1=bar" mean? Assuming something like McClennen-Sechrest, I would assume that this means the object p1=bar if it exists in the same directory as the object p1=foo. (Remember, we've already decided that each possible permutation in fact identifies a different resource, so the idea that specific values for parameters identify different resources shouldn't trouble you too much.) I'm really kicking the dog, here, but here you go proving to me again that URI aren't actually opaque *even now.* If you truly believed that URI were opaque --- or that the path parts were opaque --- then why would you assume that my URI suggests hierarchy? If URI were actually opaque, I would entirely be free to interpret any syntactically well-formed URI in whichever way I like. Perhaps '/' means set intersection in my ontology, '..' is meaningless, and order of parts is irrelevant. URI aren't opaque, they have specific syntax and associated semantics *even today.* One way to look at what I'm proposing is this: find ways to free the semantics of URI from the implied semantics of RFC2396 and make them explicit and usable by humans and software. jb PS - Getting the semantics of .. right is troublesome in any context. Cf. Rob Pike (one of the inventors of the idea of .., IIRC) musings on the topic in the context of Plan 9 development in his paper "Lexical File Names in Plan 9 or Getting Dot-Dot Right." [1] [1] http://www.cs.bell-labs.com/sys/doc/lexnames.pdf
> > I also can't see trying to convince a set of companies that plan to make > > money off a centralized model, that a decentralized model is the best > > way to go. So I'm not really into evangelizing REST to them either. > > I don't really have the time to become an ebxml reg/rep expert but I do > feel that the ebXML world is a natural ally for the REST world because > they seem to be document-centric rather than API and software-centric. Well, there's definitely conflicting goals there. It would not have been hard for them to decentralize without using REST, but they chose not to. So I think that there's forces at work there. And I'm not saying there's no value to evangelizing it to them. It's just that there's only so many hours in a day. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
bhaugen32 wrote: > >... > > Mark, I don't understand why you are dismissing ebXML either. I think he was just saying that trying to get the regrep people (not ebXML in general) to move to a decentralized model would take more effort than he is willing to undertake. Paul Prescod
Paul Prescod: > Bob Haugen: > > > >... > > > > Mark, I don't understand why you are dismissing ebXML either. > > I think he was just saying that trying to get the regrep people (not > ebXML in general) to move to a decentralized model would take more > effort than he is willing to undertake. I'm not personally interested in regrep, as I said, I think they went the wrong way. There are lots of groups within ebXML. I come from the Business Process group. You're looking into DAML-S business process models. I think in some ways we are a generation ahead. We do technology- neutral models, but are developing an RDF representation. DAML-S is ahead of us on RDF, we're ahead in resource modeling and use of resource state for pre and post condition expressions. I think in the near future we will try to get together with them (the models are similar enough to converge), but it's another case of too few hours in a day. [...] Paul Prescod: >> I don't really have the time to become an ebxml reg/rep expert but I do >> feel that the ebXML world is a natural ally for the REST world because >> they seem to be document-centric rather than API and software- centric. Mark Baker: >Well, there's definitely conflicting goals there. >It would not have been hard for them to decentralize >without using REST, but they chose not to. >So I think that there's forces at work there. There are definitely forces at work in the regrep group, and they come from your previous employer. Much of ebXML is P2P. The business process stuff is all P2P at this point. I think they would be open to REST. Or at least I am, and so are some others in my gang. > And I'm not saying there's no value to evangelizing > it to them. It's just that there's only so many hours > in a day. I'm not sure why you keep repeating this to me. I'm not regrep. You don't need to evangelize me, I came to you. All I want is to find somebody to discuss this stuff with me respectfully. In particular, answer questions. Or actually I don't even need that, I can go back to lurking, and I'll get it just fine. One problem I am having now is that there are at least five different approaches for how to do the resource modeling on the table: mine (not a proposal yet), Paul Prescod's, Mike Dierken's, Jeff Bone's and Mark Baker's. And there are some terminology issues confusing them. One terminology issue is "accept": the standard business protocol for contracts (orders are a kind of contract) is offer-acceptance. Accepted is also used as an HTTP response. But the semantics of the two uses are very different. -Bob Haugen
> There are lots of groups within ebXML. I come from the Business
> Process group. You're looking into DAML-S business process models. I
> think in some ways we are a generation ahead. We do technology-
> neutral models, but are developing an RDF representation. DAML-S is
> ahead of us on RDF, we're ahead in resource modeling and use of
> resource state for pre and post condition expressions. I think in
> the near future we will try to get together with them (the models are
> similar enough to converge), but it's another case of too few hours
> in a day.
That sounds cool. But I still haven't made my mind up about DAML-S
yet. I think I've read their docs 3 times by now, and it's still not
sinking in for me. Not sure why.
>
> [...]
>
> Paul Prescod:
> >> I don't really have the time to become an ebxml reg/rep expert but
> I do
> >> feel that the ebXML world is a natural ally for the REST world
> because
> >> they seem to be document-centric rather than API and software-
> centric.
>
> Mark Baker:
> >Well, there's definitely conflicting goals there.
> >It would not have been hard for them to decentralize
> >without using REST, but they chose not to.
> >So I think that there's forces at work there.
>
> There are definitely forces at work in the regrep group, and they
> come from your previous employer.
I can neither confirm nor deny that. 8-)
> Much of ebXML is P2P. The
> business process stuff is all P2P at this point. I think they would
> be open to REST. Or at least I am, and so are some others in my gang.
Good. Invite them over!
> > And I'm not saying there's no value to evangelizing
> > it to them. It's just that there's only so many hours
> > in a day.
>
> I'm not sure why you keep repeating this to me. I'm not regrep. You
> don't need to evangelize me, I came to you. All I want is to find
> somebody to discuss this stuff with me respectfully. In particular,
> answer questions.
I'm obviously here for that reason. Sorry Bob, I got the impression
from the previous discussion that I was being asked to run out and
evangelize REST on the ebXML mailing lists.
> Or actually I don't even need that, I can go back to lurking, and
> I'll get it just fine.
>
> One problem I am having now is that there are at least five different
> approaches for how to do the resource modeling on the table: mine
> (not a proposal yet), Paul Prescod's, Mike Dierken's, Jeff Bone's and
> Mark Baker's. And there are some terminology issues confusing them.
>
> One terminology issue is "accept": the standard business protocol
> for contracts (orders are a kind of contract) is offer-acceptance.
> Accepted is also used as an HTTP response. But the semantics of the
> two uses are very different.
I don't think this is an issue at all. "Accept" is for content
negotiation, not for any kind of offer/acceptance mechanism. You use
it to say "give me HTML", or "give me JPEG". I don't see them as
related at all.
Neither do I see the Accepted (202) response code being related to
offer/acceptance. It's a data transfer feature ("response will not be
returned on this connection"), not anything that has any "business
level" semantics.
I think if you asked Paul/Mike/Jeff/myself to model offer/acceptance,
that we would pretty much build the same model.
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote:
> I still haven't made my mind up about DAML-S
> yet. I think I've read their docs 3 times by now, and it's still
not
> sinking in for me. Not sure why.
I haven't made my mind up either. When I said "technology neutral
design", I meant as an ideal. The technology-neutral refrain in
ebXML comes from UN/CEFACT, the United Nations trade facilitation
committee. The UN/CEFACT business process people do not think XML is
the end of the road. Some prefer RDF. They are also mandated to use
UML, which embeds some other technology assumptions, although I think
they may go more deeply into RDF in the near future.
DAML-S appears to assume procedure-step style workflow engines.
RosettaNet crashed and burned trying to use those in B2B ecommerce
before giving up and going to a state-alignment conversational model.
Etc.
> > Much of ebXML is P2P. The
> > business process stuff is all P2P at this point. I think they
would
> > be open to REST. Or at least I am, and so are some others in my
gang.
>
> Good. Invite them over!
I will, as soon as I have figured out enough to make a good "sales
pitch".
> Sorry Bob, I got the impression
> from the previous discussion that I was being asked to run out and
> evangelize REST on the ebXML mailing lists.
Not by me. I agree it would be a total waste of time and just annoy
the inhabitants. I intend to bring people from my gang in ebXML over
to here and the REST wiki, when I think I can make a good case (or
somebody else has made a good case first, which would be even better
from my point of view).
> I don't think ["accept"] is an issue at all. "Accept" is for
content
> negotiation, not for any kind of offer/acceptance mechanism. You
use
> it to say "give me HTML", or "give me JPEG". I don't see them as
> related at all.
>
> Neither do I see the Accepted (202) response code being related to
> offer/acceptance. It's a data transfer feature ("response will not
be
> returned on this connection"), not anything that has any "business
> level" semantics.
I agree, but I think the overloaded word confused some of the
discussions.
> I think if you asked Paul/Mike/Jeff/myself to model
offer/acceptance,
> that we would pretty much build the same model.
Let's do it! It is one of the key business-level protocols. My
conclusion from previous discussions would be two HTTP exchanges:
1. offer-ack
2. businessResponse-ack
where businessResponse could be "accept", "reject" or some variation
on "let's negotiate, I will make a counter-offer next".
A good RESTful offer-acceptance model would be the start of a
compelling argument to the ebXML business process gang.
-Bob Haugen
> > I think if you asked Paul/Mike/Jeff/myself to model
> offer/acceptance,
> > that we would pretty much build the same model.
>
> Let's do it! It is one of the key business-level protocols. My
> conclusion from previous discussions would be two HTTP exchanges:
> 1. offer-ack
> 2. businessResponse-ack
> where businessResponse could be "accept", "reject" or some variation
> on "let's negotiate, I will make a counter-offer next".
Just to clarify, is "ack" a business level ack ("got your offer,
I'll check it out and get back to you"), or a transfer level ack
("received your message")?
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > > Paul Prescod wrote: > > > It isn't an issue of whether there is any single thing. If you want to > > apply the design criteria of another system then the basic architecture > > and requirements have to be similar. That's clearly not true of SMB/CIFS > > so maybe we could stop talking about it. > > The amazing thing about SMB/CIFS vis-a-vis the Web isn't that its "basic architecture" > (whatever that means, we're talking about names, here) is similar, and I have no visibility to > its requirements a priori. The amazing thing about SMB/CIFS is the *almost identical to HTTP > URI* naming scheme it employs. It doesn't take much head-scratching to realize that the same > problems yield the same solutions, and indeed, the similarity of the two is a rather striking > example of the ToII. I keep telling you that the inventors of SMB/CIFS are as dogmatic about the opacity principle as we are, and they back it up with licensing programs and stickers. > > > Yes, and what a good idea that turned out to be. ;-) > > > > It's an excellent idea. > > Now I know you're broken. ;-) The Windows registry is the worst idea ever, hands down, end > of story. It's such a bad idea that getting away from the registry and from "DLL Hell" --- > i.e., enabling plug-and-go installation of software just by writing directories and files --- > was supposedly one of the original motivations of the research effort that became .NET. You're not listening and you edited out the part of the message that points out that UNIX is the same in this regard as Windows. Yes the registry is a bad idea. Microsoft happens to indirect through the registry. The indirection is a good idea. That's why Unix does it too, through "~", "TEMPDIR", "HOME" and /etc/passwd. Because Unix now has an efficient concept of symlinks, it could probably get away with having a root directory called /plan9/homdirs which organized everything in the plan9 style and another root directory called /linux/homedirs which organized everything in the Linux style. But the Web *does not have* an efficient concept of symlinks. Instead it has hyperlinks. > > > ... Contrast this with systems where > > > installing an entire piece of software is simply a matter of unpacking a tarball in a > > > directory. > > > > You're talking about something totally different. > > It's part-and-parcel of the same thing. Squint, you can see it. No, it isn't part and parcel of the same thing. Indirecting well-known paths through something like an environment variable or registry setting or hypertext document has *nothing to do* with whether installation goes into a single directory. You're just trying to tar the idea through proximity to bad ideas. > (a) The redirect issue is a complete red herring, as I've already illustrated. Name opacity > has *nothing at all* to do with redirection and relocation. Let's put it this way. Opaque names and non-opaque names can both be redirected and relocated equally easily. *BUT* if the authoritative, official way to navigate from one name to another is through name similarlity relationships rather than through hypertext relationships then it becomes impossible for two related names to be directly served off of unrelated servers in a domain-name based system. Therefore you need the hypertext to be authoritative in which case the names are effectively opaque again because you are no longer relying on their similarity. Paul Prescod
I haven't read the book myself yet, but ordered it just based on
this anecdote:
"In The Periodic Table, Primo Levi tells a story that happened
when he was working in a varnish factory. He was a chemist, and
he was fascinated by the fact that the varnish recipe included a
raw onion. What could it be for? No one knew; it was just part of
the recipe. So he investigated, and eventually discovered that
they had started throwing the onion in years ago to test the
temperature of the varnish: if it was hot enough, the onion would
fry."
-- Paul Graham [1]
The Axiom of Opacity is just such an onion in the varnish of REST
/ the Web. It's prima facie false; it should at best be called
The Conceit of Opacity and at worst The Delusion of Opacity.
Consider the following contradiction, brought to you courtesy Tim
Berners-Lee:
"When you are not dereferencing you should not look at the
contents of the URI string to gain other information." (Opacity
Axiom) [2]
"Looking at this
[http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm], the
"pubs/1998" header [sic, he's referring to hierarchical parts of
a URI -jb] is going to give any future archive service a good
clue that the old 1998 document classification scheme is in
progress." [3]
So we're not supposed to look at the contents of a URI string.
But here we are looking at the contents of a URI string.
Hmmm... where there's a contradiction, there's probably
confusion, and confusion about and selective application of an
axiom makes one question the validity of the axiom.
$0.02,
jb
[1] http://www.paulgraham.com/arcll1.html
[2] http://www.w3.org/DesignIssues/Axioms
[3] http://www.w3.org/Provider/Style/URI.html
Paul Prescod wrote: > I keep telling you that the inventors of SMB/CIFS are as dogmatic about > the opacity principle as we are, And you conclude this because...? > Indirecting well-known > paths through something like an environment variable or registry setting > or hypertext document has *nothing to do* with whether installation goes > into a single directory. You're just trying to tar the idea through > proximity to bad ideas. Sigh. Paul, you're getting the independent threads of this conversation tangled --- not suprising, given your Webby proclivities. ;-) The point I was making re: the registry is that some installation mechanisms dispense with this indirection entirely, creating self-contained installations / configurations rather than interacting with settings in the registry / environment / what-have-you. This isn't a bad idea, it's a good idea --- and it's one of the motivating ideas behind .NET, behind the ROX desktop, behind some aspects of how NeXT / OS X package software, etc. > Let's put it this way. Opaque names and non-opaque names can both be > redirected and relocated equally easily. *BUT* if the authoritative, > official way to navigate from one name to another is through name > similarlity relationships rather than through hypertext relationships > then it becomes impossible for two related names to be directly served > off of unrelated servers in a domain-name based system. Not at all --- this appears to be an overgeneralization. In order for this to make sense, you need to describe specifically what the relationship between the two names is and why this relationship prevents being served from unrelated servers. jb
Jeff Bone wrote: > > Paul Prescod wrote: > > > I keep telling you that the inventors of SMB/CIFS are as dogmatic about > > the opacity principle as we are, > > And you conclude this because...? Because on Windows you cannot get Microsoft's little stamps of approval on your product if you refer directly to "/Program Files" or "/Documents and Settings". You MUST look up the real names of these things. You MUST NOT presume that the file system namespace is consistent. > > Indirecting well-known > > paths through something like an environment variable or registry setting > > or hypertext document has *nothing to do* with whether installation goes > > into a single directory. You're just trying to tar the idea through > > proximity to bad ideas. > > Sigh. Paul, you're getting the independent threads of this conversation tangled --- not suprising, > given your Webby proclivities. ;-) The point I was making re: the registry is that some > installation mechanisms dispense with this indirection entirely, creating self-contained > installations / configurations rather than interacting with settings in the registry / environment / > what-have-you. This isn't a bad idea, it's a good idea --- and it's one of the motivating ideas > behind .NET, behind the ROX desktop, behind some aspects of how NeXT / OS X package software, etc. You're going to have to provide some evidence for that statement. For instance how does .NET in any way remove a level of indirection from the filesystem? > > Let's put it this way. Opaque names and non-opaque names can both be > > redirected and relocated equally easily. *BUT* if the authoritative, > > official way to navigate from one name to another is through name > > similarlity relationships rather than through hypertext relationships > > then it becomes impossible for two related names to be directly served > > off of unrelated servers in a domain-name based system. > > Not at all --- this appears to be an overgeneralization. In order for this to make sense, you need > to describe specifically what the relationship between the two names is and why this relationship > prevents being served from unrelated servers. I have a resource that represents a user and one that represents a user's bio. I could use the namespace: /users/paul/bio or I could use hypertext /users/paul#xptr(document(@bio)). In the latter case, the thing referenced by @bio can live anywhere on the Web, even at a gnutella:// URI. In the former case I need to set up a redirect from /users/paul/bio to the real location. Paul Prescod
Jeff Bone wrote: > >... > > The Axiom of Opacity is just such an onion in the varnish of REST > / the Web. It's prima facie false; it should at best be called > The Conceit of Opacity and at worst The Delusion of Opacity. > Consider the following contradiction, brought to you courtesy Tim > Berners-Lee: > > "When you are not dereferencing you should not look at the > contents of the URI string to gain other information." (Opacity > Axiom) [2] > > "Looking at this > [http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm], the > "pubs/1998" header [sic, he's referring to hierarchical parts of > a URI -jb] is going to give any future archive service a good > clue that the old 1998 document classification scheme is in > progress." [3] > > So we're not supposed to look at the contents of a URI string. > But here we are looking at the contents of a URI string. > Hmmm... where there's a contradiction, there's probably > confusion, and confusion about and selective application of an > axiom makes one question the validity of the axiom. You're right there is confusion. But it is in your mind, not Tim's. The opacity axiom applies to *software*. One should not write software that breaks when the form of an HTTP URI changes. It's like not writing a function that breaks when its first argument is a variable named "foo" instead of one named "bar". You don't own the caller's namespace and should make no assumptions about it. Similarly client and intermediary software does not own the server's namespace and should make no assumptions about it. Tim was talking about a *human* reading the URI. That's why he said that it is a "clue". He's talking about the Web equivalent to variable naming conventions. As in, you SHOULD use m_ as a member prefix because this will make reading your code simpler. But I would kill you if you sent me a piece of software that depended upon member variables starting with m_. So variable names are opaque, except when they aren't, in exactly the same way. Paul Prescod
Paul Prescod wrote: > You're right there is confusion. But it is in your mind, not Tim's. The > opacity axiom applies to *software*. Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's head, but it's certainly in yours. ;-) Here's why: Every single browser and probably almost every other sort of Web client on the planet breaks the opacity axiom each and every day. URI are not opaque; they have semantics. Without those semantics, relative URI would be impossible. To say that URI are opaque indicates both sloppiness of language and terminological (or other worse) confusion. To assert that it is incorrect to extract any information from URI, to do anything other than dereference one --- is contradictory to a very common use of URI which is spelled out in great detail in RFC2396 -wrt- relative URI. So once we've dispelled the delusion that URI are *in fact* and by intent / design opaque, we can get on with our lives and begin to ask what the structure and semantics of URI names are and how we can enrich those semantics formally, explicitly, usefully. > Tim was talking about a *human* reading the URI. That's why he said that > it is a "clue". He's talking about the Web equivalent to variable naming > conventions. As in, you SHOULD use m_ as a member prefix because this > will make reading your code simpler. But I would kill you if you sent me > a piece of software that depended upon member variables starting with > m_. So variable names are opaque, except when they aren't, in exactly > the same way. Invalid analogy. URI aren't variable names in a flat namespace, they are semi-hierarchical names in a structured namespace. Consider: every piece of *Web server software* on the planet builds log files. These log files are often named and managed in a hierarchical log space, with log file names constructed generatively according to some rules or grammar. jb
Paul Prescod wrote: > I have a resource that represents a user and one that represents a > user's bio. I could use the namespace: /users/paul/bio or I could use > hypertext /users/paul#xptr(document(@bio)). In the latter case, the > thing referenced by @bio can live anywhere on the Web, even at a > gnutella:// URI. In the former case I need to set up a redirect from > /users/paul/bio to the real location. Just to be entirely clear: You've just pointed out that, in fact, URI can have *more* rather than less semantics than the traditional / naive understanding of filesystem pathnames. (Assuming embedding XPointer/XLink/XPath and related kinds of things into URI.) jb
Mark Baker wrote: > Paul and I are arguing that, without authoritative information to the > contrary, one should not make assumptions about somebody else's > namespace. We're in agreement on that. The disagreement potentially comes in terms of what that authoritative information needs to be, how it may be used, and whether it can be used generatively to construct URI. > Moreover, we argue that in addition to this, even when > this authoritative information is available, it should not map to > a specific relative URI structure, but instead each resource should > be classified as the expected type independant of its name, and > as part of the same aforementioned authoritative information. > > Jeff appears to agree with the first part, per his response to me > about signifying the "implementation" of a relative URI structure > by exposing that as a "feature" URI. But he disagrees with the > second part. > > Is that a fair characterization? More or less. I'm not suggesting that the abstract "type" of a resource be solely identified by its URI; I am however suggesting that abstract "type" information may be profitably embedded in URI, and that (with appropriate rules and information for doing so, provided presumably by the owner of the URI) that "type" and other useful information may be inferred from nothing more than URI. Note I'm specifically not talking about content type --- that would be a very bad idea --- but a somewhat fuzzier notion of ontological "type," i.e. how that resources stands in relation to other resources in the same information subspace and what other resources might be there. jb
Jeff Bone wrote: > >... > > Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's > head, but it's certainly in yours. ;-) Why don't we quit this line of discussion. It's unnecessarily inflammatory to presume that because someone disagrees with you they must not have thought through the issues. In fact I had all of the same questions when I first heard that URIs are opaque. Luckily, there is a document that discusses opacity, query parameters, relative URIs and so forth. It was written in 1996, perhaps years after Tim Berners-Lee went down the same mental paths you are. I went through them around six months ago. I haven't done a comparison to various file systems but I have thought through what opacity means in this context and when it applies and doesn't. That's why I've been telling people, for example, to use query parameters when opacity is not appropriate and slashes when it is. > ... Here's why: > > Every single browser and probably almost every other sort of Web client on > the planet breaks the opacity axiom each and every day. URI are not opaque; > they have semantics. Without those semantics, relative URI would be > impossible. As long as you restrict yourself to the semantics described in the URI specifications, I have no argument. Those are shared agreements that software reliably implements. When you start inventing naming conventions you are going beyond that and starting to embed *application semantics* in URIs. Software that depends upon this will be fragile in the face of changes in URIs. Insofar as URIs are tied to servers, they will be fragile in the face of resource moves to other servers. This can only be mitigated through expensive redirects. > To say that URI are opaque indicates both sloppiness of language and > terminological (or other worse) confusion. To assert that it is incorrect to > extract any information from URI, to do anything other than dereference one > --- is contradictory to a very common use of URI which is spelled out in > great detail in RFC2396 -wrt- relative URI. URIs are opaque at the application level. Client software should not inspect URIs to try and figure out the structure of a server's data model. Relative URIs are a syntactic shortcut like a macro. Like a macro, they are provided by the person who created the data. If the *client* started inventing relative URIs, by adding ".."s etc., it would be a violation of application-level URI opacity. > So once we've dispelled the delusion that URI are *in fact* and by intent / > design opaque, we can get on with our lives and begin to ask what the > structure and semantics of URI names are and how we can enrich those > semantics formally, explicitly, usefully. You have to make a case that there is value in enriching those semantics. So far all I've seen is: "this thing that can be done with hypertext. We could also do it in a different way with namespaces." The confusion caused by relative URIs demonstrates that the current level of "rewriting semantics" already causes a problem. It was confusing for me at first also. I presumed that HTTP's notion of containment and URI's notion of containment were related. They are not. HTTP's is a *public* containment that client and server should share. URIs is a *private* containment that is owned by the server and used by the client only under strict server control...in other words with "..". > > Tim was talking about a *human* reading the URI. That's why he said that > > it is a "clue". He's talking about the Web equivalent to variable naming > > conventions. As in, you SHOULD use m_ as a member prefix because this > > will make reading your code simpler. But I would kill you if you sent me > > a piece of software that depended upon member variables starting with > > m_. So variable names are opaque, except when they aren't, in exactly > > the same way. > > Invalid analogy. URI aren't variable names in a flat namespace, they are > semi-hierarchical names in a structured namespace. From the client's point of view it *is* a flat namespace. That's just the point. URIs have hierarchical parts *only* to allow relative URIs: RFC 2396: > It is not necessary for all URI within a given scheme to be > restricted to the <hier_part> syntax, since the hierarchical > properties of that syntax are only necessary when relative URI are > used within a particular document. And relative URIs *only* exist as a shortcut syntax for the maintenance of human-authored documents: > Relative addressing of URI allows document trees to be partially > independent of their location and access scheme. For instance, it is > possible for a single set of hypertext documents to be simultaneously > accessible and traversable via each of the "file", "http", and "ftp" > schemes if the documents refer to each other using relative URI. In other words' it is a hack to get around the fact that rewriting URIs is a pain and not even feasible with primitive software like FTP servers. > ... Consider: every piece of > *Web server software* on the planet builds log files. These log files are > often named and managed in a hierarchical log space, with log file names > constructed generatively according to some rules or grammar. So software ignores web architecture. What a surprise! This could easily be handled with either hypertext links or query parameters. Paul Prescod
Detailed but concise responses to many incorrect or invalid assertions. Paul Prescod wrote: > Jeff Bone wrote: > > > > Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's > > head, but it's certainly in yours. ;-) > > Why don't we quit this line of discussion. It's unnecessarily > inflammatory to presume that because someone disagrees with you they > must not have thought through the issues. You opened that line of argument. I just tossed it back with a winky. ;-) I would prefer not to engage that way, but you did (and continue to, below) presume the very thing you're encouraging me not to presume about you. > In fact I had all of the same > questions when I first heard that URIs are opaque. It's incorrect (and, as you've asserted above, unnecessarily inflammatory) to assume that this is a first reaction to URI opacity on my part. On the contrary, as I've mentioned in private correspondance to you previously, my starting point circa my REST gestalt mid last year was to accept all of it --- including URI opacity --- on faith. My current POV is the result of a critical examination of that acceptance of the whole rather than specific parts. My current conclusions are not the result of a process of initial non-acceptance. > Luckily, there is a > document that discusses opacity, query parameters, relative URIs and so > forth. It was written in 1996, perhaps years after Tim Berners-Lee went > down the same mental paths you are. I'd be very surprised if, either in the course of the discussion here or in the pages I've been working on in the Wiki, I haven't cited the document you mention. I would be even more surprised if I haven't already read that document and, indeed, based part of my current thinking on it. > I haven't done a comparison to various file systems Then you are insufficiently prepared. > As long as you restrict yourself to the semantics described in the URI > specifications, I have no argument. Those are shared agreements that > software reliably implements. When you start inventing naming > conventions you are going beyond that and starting to embed *application > semantics* in URIs. No, you are embedding information modeling semantics in URI. HTTP is the application. And this should be no more or less acceptable than using, say, arbitrary XML Schemata or RDF. Again, if it's not clear, I'm *not* suggesting that URI be given "naked semantics." I am suggesting that explicit and possibly extensible semantics can be given by specific namespace owners to specific sets of URI w/o the Web coming to an end. > Software that depends upon this will be fragile in > the face of changes in URIs. This is a myth, cf. the Wiki. Short version: this is no more a problem than is schema evolution, etc. in RDF ontologies. To the extent that software might be fragile in the face of good, disciplined use of structured naming, that's IMO poor software design causing the fragility. > Insofar as URIs are tied to servers, they > will be fragile in the face of resource moves to other servers. This can > only be mitigated through expensive redirects. This is a red herring. URIs are already tied to servers. Recognizing and exploiting the semantics of the path component of a URI doesn't make the URI any more or less susceptible to this problem. > URIs are opaque at the application level. Client software should not > inspect URIs to try and figure out the structure of a server's data > model. This is trivially incorrect. Relative URI are an example of how client software can and does inspect URI to determine certain things about the structure of a server's data model. > Relative URIs are a syntactic shortcut like a macro. Like a macro, they > are provided by the person who created the data. If the *client* started > inventing relative URIs, by adding ".."s etc., it would be a violation > of application-level URI opacity. Big deal. If the server (or some other agency) provides explicit information about the structure of its names and their associated semantics then there's no downside. > You have to make a case that there is value in enriching those > semantics. No, you have to make the case that there isn't. Extraordinary claims require extraordinary proof. TBL's assertion of the axiom is the extraordinary claim, counter to the majority of all namespace and filesystem research out there today. > So far all I've seen is: "this thing that can be done with > hypertext. We could also do it in a different way with namespaces." That's not true, I have already given you a very particular example of how generative names can be used that is impossible to accomplish with hypertext. With generative names, it might be possible to crawl a site to "find the page that isn't linked to by any other page." Using strictly the hypergraph topology, this is impossible. This is a trivial but I think evocative example. > > Invalid analogy. URI aren't variable names in a flat namespace, they are > > semi-hierarchical names in a structured namespace. > > >From the client's point of view it *is* a flat namespace. That's just > the point. Only by virtue of the Axiom of Opacity. You can't use the Axiom of Opacity to prove the validity of the Axiom of Opacity. Next thing you know you'll be telling me that everything in the Bible is true because it's God's Word, and we know that because the Bible tells us so. > > ... Consider: every piece of > > *Web server software* on the planet builds log files. These log files are > > often named and managed in a hierarchical log space, with log file names > > constructed generatively according to some rules or grammar. > > So software ignores web architecture. What a surprise! This could easily > be handled with either hypertext links or query parameters. My point is to illustrate that useful and simple examples of generative naming abound throughout all types of software. Why do you think Web server implementations use such a non-Webby concept as structured naming to manage logfiles, rather than using some other hypermedia concept or what have you? Could it be because there are benefits to doing so? jb
Mark Baker wrote:
> > 1. offer-ack
> > 2. businessResponse-ack
> > where businessResponse could be "accept", "reject" or some
variation
> > on "let's negotiate, I will make a counter-offer next".
>
> Just to clarify, is "ack" a business level ack ("got your offer,
> I'll check it out and get back to you"), or a transfer level ack
> ("received your message")?
In RosettaNet and ebXML it's called "receipt acknowledgment" which
means "message received" and "schema validated". It is business-level
but should be done quickly and automatically and the contents can be
stereotyped. It may require non-repudiation of receipt (e.g. digital
signature). The contents would be archived in a transaction log,
which I think should be part of the resource model.
There could be other complications, too, but I'll spare you for now.
I tried to reply to this earlier, but it apparently went off into
space. I got the message earlier that there was something amiss with
my Yahoo groups profile, and tried to fix it, and the next reply was
published quickly. Don't know what happened to the last one. If
this one disappears, I'll try deleting and re-adding my membership
with a new user id. The problems started to appear after the recent
Yahoo groups outage, although that may have been coincidental.
Mark Baker asked [about offer-ack]:
> Just to clarify, is "ack" a business level ack ("got your offer,
> I'll check it out and get back to you"), or a transfer level ack
> ("received your message")?
The acks are business-level, but simple. In RosettaNet and ebXML,
it's called a "receipt acknowledgment" and means "received"
and "schema validated". Non-repudiation of receipt may be required.
The receipts would go into a transaction log, which I think should be
part of the resource model.
There could be other status messages and complications depending on
the business process model, but those will do for starters and
everything else would be a variation.
-Bob Haugen
Paul Prescod wrote: > You're going to have to provide some evidence for that statement. For > instance how does .NET in any way remove a level of indirection from the > filesystem? It doesn't remove a level of indirection from the filesystem, it uses filesystem-based objects (assemblies) to store all necessary metadata in a self-contained fashion. Cf. "Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework" [1] > I have a resource that represents a user and one that represents a > user's bio. I could use the namespace: /users/paul/bio or I could use > hypertext /users/paul#xptr(document(@bio)). So, just to point something out: you've introduced semantics into that name. The point is that whatever interprets these names --- whether human or Web server or servlet or enhanced shell (as with ksh98) or kernel namespace manager (as with Plan 9, Linux, etc.) --- can be made to understand the latter. Indeed the kind of thing you're doing with that name is precisely the kind of thing e.g. Reiser would like to accomodate for "file" name resolution in the operating system: "semantic naming." Furthermore, there's absolutely no reason why I can't (using some sophisticated file namespace mechanism such as custom extensions to 3DFS) provide a mapping from /users/paul/bio to resolve to /users/paul#xptr(document(@bio)). Indeed, in the long run I truly believe that the boundaries between the Web and filesystems must dissolve and the location dependencies of *both* mechanisms must go away. But that's a later argument; let's stick with debunking the Delusion of Opacity and eliminating the dangers of tossing out structured semantic naming without good justification. A namespace is a namespace. It's all about how you manipulate them and how you interact with them. I'm specifically *not* stating that traditional UNIX-like pathnames have the power and flexibility and so forth of URI, nor am I advocating any move away from URI. What I am pointing out is that the same level of name resolution and indirection from symbolic names to lower-level objects (representations, local device:inode pairs, etc.) happens both in the Web and in filesystems, and that filesystems have obtained positive benefit by not being delusional about name opacity. jb [1] http://msdn.microsoft.com/msdnmag/issues/1000/metadata/metadata.asp
Jeff Bone wrote: > >... > > Well, there's no reason to believe that the benefits or small, large, or otherwise in the > absence of a more detailed investigation of relaxing the opacity axiom. But without such an > investigation --- substituting dogma for research --- one can't really speak authoritatively > about such things. Well, go do the research! I have not run into any problems that name transparency would help me to solve. The examples you've presented have been trivially solvable with hypertext, using existing techniques. You admit that making name-based navigation work as well as hypertext navigation would require a bunch of new standards, so I think you need to demonstrate that there is some payoff for that effort. Here are the advantages I've heard you cite: 1. Guessability for humans -- nobody disputes the value of this. But the authoritative way to navigate for humans must be hypertext. i.e. I'll kick your ass if you build a site with a /search but no search button. On the other hand, having a search button that goes to www.google.com rather than /search seems acceptable to me. So you may create URIs that are readable but you should ACT as if they are opaque. 2. Guessability for computers -- the only way you could make things guessable for computers is to invent this "generative grammar" thing. First, we already have most of that in HTML forms and XForms. Second, guessability is never as good as certainty and certainty can be provided more easily through hypertext. You say: "A program armed with a grammar for constructing resource names from hierarchical components and a further declarative description of the semantics of each part --- potentially in RDF --- could similarly 'discover' information in a sort of gestalt rather than deductive fashion." You do not demonstrate why this is better. By the way, note that in Unix it is common to "discover" new files by going to a directory and getting a listing. Getting a listing in HTTP is doing a GET and parsing the XML. Unix programs do not discover the list of new processes by poking at /proc/random_number. Rather they do an LS and *parse the result* (semantically...of course this is not precisely what happens in C programs). 3. As a resource modeling tool -- if you treat this as similar to 1., I have no problem with it. Make meaningful names for communication among humans and then write software that treats the names as meaningless. > ... It seems to me that the Opacity Axiom is overstated and overapplied, and > I've documented some few of the many reasons why embedding information in names is in fact > useful, not anathema as the dogma states. Nobody, anywhere, would say that it is bad to embed information names. The problem is making names the canonical source for information. > As for the horrors of new schema languages, conventions, and interface definition systems... > WRDL? I rest my case. If you're going to argue, you should at least try not to argue with > yourself. ;-) (Sometimes, that's hard --- trust me, I know. ;-) WRDL is based on the notion that the hypertext is the definitive means for navigating between components. If we made names the definitive means then your new language would probably be a appropriate. But as I understand it, what you are arguing is that we should have both. Names should be the definitive in some circumstances and hypertext in others. That means we need both WRDL (or something like it) and a generative grammar language. We need both WRDL's notion of a resource type and your notion of a URI interface type. Until I hear some compelling advantages for having two different, parallel authoritative navigation mechanisms, I'd rather apply Occam's razor. >... > (b) The "standardization" issue is also a red herring, as I've already illustrated. It > hardly matters whether what's being "standardized" (let's be more clear, specified by any and > all who want to specify such things, independent of any central authority) is N3 notation for > ontologies of resources or some other mechanism for specifying generative grammars for names > and information organizational conventions. Let's be 100% clear about how we each see things working. My model: Somebody gives me a URI, like "www.foobar.com/blahservice.xml". I expect my software to be able to look at that XML document and see if it is in a vocabulary it knows (probably through an XML namespace or doctype). If it is, I expect it to be able to follow all links and access the complete service through hyperlinks. It may have a WRDL that describes the service or it may just run with no validation. If it isn't a vocabulary I've ever heard of then in theory I may one day be able to use RDF to figure out the semantics of the service (okay, I doubt it, but the semantic web people seem to believe it so I'll mention it). Now what do YOU propose? I look at the URI document and then I take its name and tack on a /jeffsnamingconventions or a /paulsnamingconventions or a /mikesnamingconventions, etc., etc. until I get a "hit"? When I find a hit I know what generative grammar it is using and I construct other names based on the base name? >... > Well, you are in essence asserting that all attempts to embed semantics and use meaningful > names to structure systems of resources --- including such incredibly powerful and yet > incredibly misunderstood efforts like Plan 9 --- is poor software design. The value of namespaces as organizational tools depends heavily on the a) flexibility of the namespaces, b) the ease or difficulty of constructing new namespaces, c) the introspection tools availble for navigating namespaces, d) the ease of having adjacent names stand for things on physically distant devices e) the extent to which the user will use namespaces as a navigation mechanism f) the extent to which it is important to decentralize namespace standardization etc. Plan 9: a) It has *per process* namespaces, so you can't get much more flexible then that. b) Obviously constructing namespaces in Plan 9 is very cheap since it can be done in user space c) plan 9, like every operating system, has an "ls" command. It returns a document with name-value pairs where the values can be pointers elsewhere. The web has GET. It returns hypertext which typically embeds name-value pairs where the values can be pointers elsewhere d) plan 9 namespaces are "client-side" (i.e. in the process) so two seemingly adjacent things can be arbitrarily far apart in physical space with no runtime expense e) In unix-like systems, namespace navigation is a primary tool for navigating information. Hyperlinks are not a first-class concept. f) in plan 9, "Although there is no global name space, for a process to function sensibly the local name spaces must adhere to global conventions" This is okay when you are designing an operating system, because you already expect people to "port" their software to your OS. I don't want to "port" applications from one web site to another. In plan 9, "the command cat /proc/*/status is a crude form of the ps command; the actual ps merely reformats the data so obtained." Note that the cat command does not use some form of generative grammar. Rather the command line processor parses the logical output of an "ls" on /proc and then works with those files. The command is almost legal XPath syntax although the semantically equivalent XPath would look more like: http://www.machine.com/processes#xprt(document(//proc/status)) (if we presume that status's live in a separate document rather than the same one) > ... You make this > assertion with very little backup, and contrary to the prevailing opinion of some of the > world's most influential computer scientists. Once again you're shifting around. I'm talking about good application design in a system with the constaints of the Web or (to some extent) CIFS/SMB. Plan 9 is a totally different world because Plan 9 is an *operating system* not just a file system and it manages many things in the kernel that we cannot do on the Web. Yes, if we could push namespace merging onto the client side on the Web then of course that would be a very powerful tool. In fact, hypertext is all we can transmit to the client side so in essence we do namespace merging using hypertext. >... > It does nothing of the sort. It poses an abstract organization of resources in a > quasi-hierarchical namespace. It doesn't at all necessarily assume that the breakdown by > years is the only possible naming structure (others might simultaneously exist) or that the > objects are going to "reside on the same disk." (Check out NTDFS, AT&T 3DFS, Sun's > Translucent File System, the FiST stackable filesystem toolkit, and other filesystems to see > why you're wrong in your presumption.) It might be a bad software design if those > presumptions were true, but the fact that you make those presumptions simply illustrates a > lack of understanding of the flexibility and utility of the filesystem namespace in many > modern filesystems. That only works because you have *kernel support* for making namespaces look very different than physical layout. The web *has no such thing*. I can't have a file "appear to be" on one machine for one user and on another machine for another user without considerable runtime expense and complexity. > > I already have > > this problem when I want to move my massive trash folder to a different > > disk than the other mail messages. > > Yes, no doubt, this is a huge problem. Most workday local filesystems couple the namespace to > the underlying storage space in unpleasantly tight ways. This is one of the problems we're > addressing at Deepfile. Once you address it on the Web we'll be able to use namespaces as an organizational tool on the Web. Paul Prescod
I'm not sure there's as much disagreement as we might think. Paul and I are arguing that, without authoritative information to the contrary, one should not make assumptions about somebody else's namespace. Moreover, we argue that in addition to this, even when this authoritative information is available, it should not map to a specific relative URI structure, but instead each resource should be classified as the expected type independant of its name, and as part of the same aforementioned authoritative information. Jeff appears to agree with the first part, per his response to me about signifying the "implementation" of a relative URI structure by exposing that as a "feature" URI. But he disagrees with the second part. Is that a fair characterization? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I've started a page on the Wiki [1] which attempts to capture and debunk some of the "myths" about name opacity that we've discussed here and that commonly occur elsewhere. I'm interested in collecting more myths to add to this page, so let me have 'em if you've got 'em. :-) I've also got the rough outline of a page [2] on the different kinds and qualities of names. It's barely an outline at this point; what I'd like to do with it is ultimately construct a taxonomy of different kinds of names and a table of the operations and characteristics each supports. In my own investigation of opacity I've concluded that the refusal to recognize the differences between names and addresses by e.g. TBL is probably more of a historical / cultural response to the contentiousness of discussing various ideas about naming and identity in the early Web than it is a well-formed technical viewpoint. I'd like to clear out the fog of confusion a bit and give us a vocabulary to use in discussing names and their applications. $0.02, and feedback welcome,* jb [1] http://conveyor.com/RESTwiki/moin.cgi/OpacityMythsDebunked [2] http://conveyor.com/RESTwiki/moin.cgi/KindsOfNames * always welcome, though dogma discouraged. ;-)
One of the recurring themes in this discussion has been Paul's questioning of why we need naming when
navigating hypertext might suffice. The answer is that, if both mechanisms were equally expressive, we
wouldn't need both. But the fact is that navigation and naming aren't equally expressive in all
situations or for all purposes. There are things you can do --- particularly in dense,
highly-structured information spaces --- which are not possible via traversal of graph structures from
opaque entry points.
Imagine if, whenever I wanted to run "ls" for the first time in a shell process, I had to "crawl" the
directory structure from the root in order to locate the executable. This would be awful, wouldn't it?
I've provided many examples of how generative naming can be and is used in various contexts to
accomplish things that aren't or are not easily accomplished via navigation from some well-known
starting point. To recap some of these examples:
* discovery of "unlinked" but named objects in a namespace
* creation, maintenance, and access of dense, regular namespaces
* logging
* archiving
* collections of non-hypermedia
* avoiding user interface navigation
* programatic use of regular namespaces
* log managers
* debuggers -w- /proc
* system management tools
* location of executables, libraries, etc. by other programs
Etc. etc. etc. All of these things benefit from having a priori understanding (via filesystem
organization "standards," conventions, grammars or rules for generating names, etc.) of namespace
organization and rules for generating names of interest. All of them operate by de novo synthesis of
semantically-meaningful names in structured namespaces. None of these operate solely by traversal of
graph structures, even trivial graph structures such as single-rooted filesystem DAGs --- and many (such
as the debugger example) *require* structured name generation.
The value of generative naming and structured namespaces simply can't be questioned, given the ubiquity
of the technique in everything we do with software. It's preference to navigation *for certain
purposes* should be clear. Insistence otherwise is, really, pretty silly.
jb
Jeff Bone wrote: > >... > > Not true. For the *fourth* time (counting the Wiki) here's a trivial example that debunks this > myth, a problem which generative names solve which cannot be solved via hypertext. You are a Web > crawler. Your job is to find all the public objects on a Web server, *including the one or ones > that are not linked to by other objects.* This is ridiculous. Part of your problem statement is to disallow me from using one of the two tools under discussion. "How would you solve this problem in Java without using Java." Paul Prescod
Geez, Paul, you're going for an alltime record in how many times one can be demonstrably wrong in a single e-mail. Please take the time to read this if we're going to keep this up, as we're now hitting a point where I'm demonstrating the incorrectness of certain of your assertions *repeatedly* and yet you keep insisting on them. I have no problem with *either* being wrong or telling somebody they are wrong --- mistakes made once are good, but the same mistakes made multiple times are stupid and annoying. I'm sorry if that's inflammatory, but if you can't learn, don't argue. Paul Prescod wrote: > Well, go do the research! I have not run into any problems that name > transparency would help me to solve. The examples you've presented have > been trivially solvable with hypertext, using existing techniques. Not true. For the *fourth* time (counting the Wiki) here's a trivial example that debunks this myth, a problem which generative names solve which cannot be solved via hypertext. You are a Web crawler. Your job is to find all the public objects on a Web server, *including the one or ones that are not linked to by other objects.* Generative, structured names can solve this problem. Hypermedia cannot, as by definition these objects are not part of the hypergraph. Paul, you can go on asserting till the cows come home that I haven't give you such an example, but the problem appears to be that you haven't read it, undertood it, and acknowledged it. > You > admit that making name-based navigation work as well as hypertext > navigation would require a bunch of new standards, so I think you need > to demonstrate that there is some payoff for that effort. No more, say, than you need to demonstrate the advantages of e.g. WRDL. > Here are the > advantages I've heard you cite: > > 1. Guessability for humans -- nobody disputes the value of this. But > the authoritative way to navigate for humans must be hypertext. i.e. > I'll kick your ass if you build a site with a /search but no search > button. On the other hand, having a search button that goes to > www.google.com rather than /search seems acceptable to me. So you may > create URIs that are readable but you should ACT as if they are opaque. The last statement is non-sequiter from your example. But let's be clear: there is a *difference* between navigation and directly naming an object. Both are useful in different contexts. In general, however, navigation is more expensive than just simply "going" to the resource in question. If in order to get to your search page I must first pull up your front page and click a link, this is less useful than being able to type in .../search and get to the same place. > 2. Guessability for computers -- the only way you could make things > guessable for computers is to invent this "generative grammar" thing. It's not an invention, we've been using generative grammars for ages. The question is how and whether to apply this kind of thing to the Web in order to (a) solve problems hypermedia cannot solve, such as dealing with objects that do not reside in hypermedia and / or link inconcistencies, or (b) solve problems that hypermedia can solve but for which name-based solutions are easier, more useful, or more efficient. > First, we already have most of that in HTML forms and XForms. Second, > guessability is never as good as certainty and certainty can be provided > more easily through hypertext. I'm not arguing purely for guessability. Consider: if I am on a UNIX box, I don't have to "guess" whether /etc, /dev, etc. will be there --- they will. I know this because I know the organizational structure that the OS conforms to and presents through the filesystem. > You do not demonstrate why > this is better. The above example (which you're blissfully refusing to grok ;-) demonstrates one way in which this is "better" i.e. useful for tasks hypermedia isn't useful for. > By the way, note that in Unix it is common to "discover" > new files by going to a directory and getting a listing. Getting a > listing in HTTP is doing a GET and parsing the XML. Unix programs do not > discover the list of new processes by poking at /proc/random_number. > Rather they do an LS and *parse the result* (semantically...of course > this is not precisely what happens in C programs). That's true, and this is a good point. However, programs on various UNIXen *do* indeed "construct" synthetic filenames synthetically based on conventions, rules, etc. Debuggers contruct filenames to reference the /proc/n/mem psuedofile representing the memory of PID n that they are debugging. Logging systems manipulate filenames of e.g. the form /var/logs/<software>/<year>/<month>/<day> and so on. Archives of various things synthesize filenames much like the following to organize the information they manage. These things don't "discover" anything by traversing the filesystem from some well-known entry point; they have a priori information about how the namespace is organized, and they use this constructively to manage the information space. There's several additional examples of the use of structured names that are not and cannot be accomodated in hypermedia or other navigational metaphors. In all cases, names are computed rather than navigated to. > 3. As a resource modeling tool -- if you treat this as similar to 1., I > have no problem with it. Make meaningful names for communication among > humans and then write software that treats the names as meaningless. That's how this started, in a sense, but the more I thought about it the more I discovered that structured and semantically-meaningful names were as or even more useful to softare. > Nobody, anywhere, would say that it is bad to embed information names. TBL would, and does in his explanation / justification / rationalization of the Opacity Axiom and elsewhere. > The problem is making names the canonical source for information. Did you think I suggested this? If so, you're wrong. > > As for the horrors of new schema languages, conventions, and interface definition systems... > > WRDL? I rest my case. If you're going to argue, you should at least try not to argue with > > yourself. ;-) (Sometimes, that's hard --- trust me, I know. ;-) > > WRDL is based on the notion that the hypertext is the definitive means > for navigating between components. So what you're telling me is that invention of new "schema languages, conventions, and interface definition systems" is a futile activity, to be discouraged and avoided... unless you're dogma compliant? GMAB. I'm not casting aspersions on your effort at all. Rather, I believe that such effort is valid regardless of whether it conforms to doctrine or not, particularly if deviating from doctrine produces something useful that does not devalue other doctrinologically-appropriate tools. > If we made names the definitive means > then your new language would probably be a appropriate. But as I > understand it, what you are arguing is that we should have both. What I am arguing is that we *do* have both (relative URI) and that TBL's own Design Principle of Tolerance as well as the general attention to extensibility and openness in other areas of Web design argues --- contrary to the axiom --- for opening up the semantics of URI for other purposes, in effect *truly* allowing namespace owners to use their namespaces as they see fit. (They already do the latter; I'm simply advocating a mechanism to encourage more discipline and consistency.) > Names > should be the definitive in some circumstances and hypertext in others. > That means we need both WRDL (or something like it) and a generative > grammar language. We need both WRDL's notion of a resource type and your > notion of a URI interface type. Until I hear some compelling advantages > for having two different, parallel authoritative navigation mechanisms, > I'd rather apply Occam's razor. Occam's razor only applies if the mechanisms (navigation and name generation) are expressively equivalent. They aren't, as I've demonstrated repeatedly with my crawler example. Both models need to exist. (Actually, while it's provably true that generative names can do things hypergraph traversal cannot, the converse has yet to be proven in this discussion. But I'm generously willing to grant that it's probably the case that both mechanisms are necessary.) > My model: Somebody gives me a URI, like > "www.foobar.com/blahservice.xml". I completely understand your model. I took the time to do so. I rather like it. > Now what do YOU propose? I look at the URI document and then I take its > name and tack on a /jeffsnamingconventions or a /paulsnamingconventions > or a /mikesnamingconventions, etc., etc. until I get a "hit"? When I > find a hit I know what generative grammar it is using and I construct > other names based on the base name? This is a bit of a bad example; generative names are bad for generating names in sparse namespaces. They're good, for example, for calculating the name of a particular archival object given the name of an earlier one + a syntax for representing time in the name + an understanding of the "period" of the archive. > The value of namespaces as organizational tools depends heavily on the Thanks for the lesson, Paul, I'm quite familiar with Plan 9. ;-) > > ... You make this > > assertion with very little backup, and contrary to the prevailing opinion of some of the > > world's most influential computer scientists. > > Once again you're shifting around. There's a lot of ground to cover in debunking the myth of opacity. > I'm talking about good application > design in a system with the constaints of the Web or (to some extent) > CIFS/SMB. Plan 9 is a totally different world because Plan 9 is an > *operating system* not just a file system and it manages many things in > the kernel that we cannot do on the Web. This argument isn't compelling. We're talking about the use of namespaces and naming. There are similarities. There are differences. As long as we don't ignore these, it's possible to use lessons learned in one in the other context. > Yes, if we could push namespace > merging onto the client side on the Web then of course that would be a > very powerful tool. Do you think I'm suggesting that? I'm not. > In fact, hypertext is all we can transmit to the > client side so in essence we do namespace merging using hypertext. The latter assertion is false. A large majority by volume of the traffic on the Web is not hypertext but rather opaque media objects. > That only works because you have *kernel support* for making namespaces > look very different than physical layout. This is false. The very thing I was referring you to which you *clearly* haven't bothered to investigate --- AT&T's 3DFS --- is a userspace per-process virtual filesystem implementation that runs on many different platforms with no kernel support at all. > The web *has no such thing*. I > can't have a file "appear to be" on one machine for one user and on > another machine for another user without considerable runtime expense > and complexity. This is also trivially false, as demonstrated by (for instance) mirroring, etc. > Once you address it on the Web we'll be able to use namespaces as an > organizational tool on the Web. But I'm not going to be allowed to address it if everybody wants to continue being delusional about URI opacity. ;-) jb
The name/location/identifier thing, for whatever reason, was the first thing I understood about the Web really well. This was back in 94/95, before I got the Web. My view of it, which I got before reading very much of Tim's stuff, was that you have strings that are used in different contexts for different purposes. To a higher layer, an identifier looks like a location. To a lower layer, it looks like a name. That is, depending upon how you look at it, an identifier is both a name and a locator. http://www.markbaker.ca/2001/03/James/ is a string that identifies my son (who turned 1 today!). I use it as a name when I ask a cache if it has a valid representation for me. I use it as a locator when my HTTP client stack follows the rules in RFC 2396 to turn it into something that opens a socket to port 80 on 207.236.3.141. Rohit had a great presentation at TWIST '99[1], and a spinoff article[2] in his IEEE column about this. [1] http://www.isr.uci.edu/events/twist/twist99/presentations/khare/ [2] http://www.isr.uci.edu/~rohit/IEEE-L7-namespaces.html MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Paul Prescod wrote: > This is ridiculous. Part of your problem statement is to disallow me > from using one of the two tools under discussion. "How would you solve > this problem in Java without using Java." The above Java example *is* ridiculous --- it's a problem that would never occur in real life. The example I've offered is something that might easily occur --- consider densely packed regularly named namespaces full of opaque media objects without links between them. I'm denying you your tool because, in some cases, your tool doesn't work, or because it's more work to make your tool work than to make other tools work. Hammer, nails, etc. jb
Paul Prescod wrote: > This is ridiculous. Part of your problem statement is to disallow me > from using one of the two tools under discussion. "How would you solve > this problem in Java without using Java." Actually, on more reflection, your pushback is incredibly ridiculous. You're saying "I have a phillips head screwdriver. I can drive any screw with this. Prove me wrong by showing me something I can't screw in with this." I'm saying "fine, here's a regular screw. Screw it in with your phillips head screwdriver. You can't." And you're getting petulant and complaining that I'm invalidating your assertion by giving you something other than a phillips head screw. jb
Jeff Bone wrote: > > Paul Prescod wrote: > > > This is ridiculous. Part of your problem statement is to disallow me > > from using one of the two tools under discussion. "How would you solve > > this problem in Java without using Java." > > The above Java example *is* ridiculous --- it's a problem that would never occur in real life. The > example I've offered is something that might easily occur --- consider densely packed regularly named > namespaces full of opaque media objects without links between them. Now you've given me a problem statement: "How would you handle densely packed regularly named namespaces full of opaqaue media objects without links between them." Fine. By saying "between them" you've opened the door for me to add hypertext that links the documents externally. In other words I'm now allowed to use the tool I'm supposed to compare. I'm presuming I have control over the server because otherwise I can't solve this using either a regular naming convention or a hypertext solution. If the graphics use random names and are not linked somehow then the robot is screwed either way. So given that I control the server, I can simply write a CGI that generates an index document that creates links to the opaque objects a la images.google.com. If there is a reason to want to get indexes just of subsets of them then my CGI would do that too (c.f. images.google.com). If the files are reliably named then this CGI should take about an hour to write. As the service provider I can trivially include images in the set that are not physically stored on the server because the URIs can point anywhere on the Web. Now if I am JUST the spider writer and I have no opportunity to co-ordinate with the service creator then I may be reduced to hacking. I'm trying to get information out that the service provider did not give me explicit access to. Guessing predictable filenames might be an okay hacking technique in some circumstances. Poking around for a hypertext index might be another good technique in some circumstances. I could also try to see if there was an FTP interface or perhaps a known security hole I could exploit. ;) > I'm denying you your tool because, in some cases, your tool doesn't work, or because it's more work to > make your tool work than to make other tools work. Hammer, nails, etc. Now that you've stated the problem as a problem, I've applied my hammer and as far as I can see it works fine. Paul Prescod
Paul Prescod wrote: > Now you've given me a problem statement: "How would you handle densely > packed regularly named namespaces full of opaqaue media objects without > links between them." Fine. By saying "between them" you've opened the > door for me to add hypertext that links the documents externally. In > other words I'm now allowed to use the tool I'm supposed to compare. Sorry, "without links to them." Bottom line, Paul --- although everything on the Web *can* be linked to, not everything is. Yet everything that is nameable by a URI --- regardless of whether it has inbound or outbound links in some hyperstructure --- is still part of "the Web." The Web enables hypertext. It is not defined by it, nor is it intended to be constrained by it. The statement "hypermedia is the engine of application state" is another onion in the varnish, a hypermedia enthusiast's statement of opinion about the Web rather than a true principle of its design, IMO. It seems to me that, by itself, HTTP is the application, not XML or HTML. It seems to me, after months of consideration, that the problem with Roy's formulation of REST is not that it is too constraining but rather that it is *not constraining enough* --- it fails to separate the concerns of generic resource modeling and representational state transfer from the concerns of a particular kind of state that might be transferred, i.e. hypermedia. But that's a later argument. I'm working on a set of examples for the Wiki beyond the one I've repeatedly offered which illustrate how dispensing with the pretext of opacity enables some things that are not possible simply through graph traversal from an opaquely-named entry point and how it simplifies and makes many other things more efficient. I'll post here when that is ready for perusal. > Now if I am JUST the spider writer and I have no opportunity to > co-ordinate with the service creator then I may be reduced to hacking. Yes, you are reduced to "hacking" in this case --- *because* of opacity. (The limitation to being the spider writer should've been clear in the original problem statement.) Dispensing with opacity and introducing explicit information about organizational schemes and the specific semantics of structured names elevates that activity to something more disciplined. > Now that you've stated the problem as a problem, I've applied my hammer > and as far as I can see it works fine. No, you seized on a misstatement of mine (I incorrectly said "between" when "to" was the more limiting statement I was going for, and indeed used in earlier formulations) and ran with it. Further, you ignored one basic premise that was clear, namely that your task was constrained by virtue of not being in local control of the resources in question. jb > > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
I'm not proposing --- despite examples yesterday which might imply
something to the contrary --- both that URI be considered transparent
*and* that the semantics of e.g. '/', ';', and '?' subject to
redefinition by any namespace owner. I might've confused the discussion
when I talked about the possibility of using '/' to mean set
intersection; that's sort of an extreme example, not something you're
really want to do. Informally, '/' should only be used to indicate
traversal of "links" in a graph-structured namespace. That is, given a
partial path
a/b/
then the following should hold
a/b/.. == a/
I'm not at all trying to redefine the semantics associated with existing
URI syntax, just trying to point out that those semantics do indeed
exist and can be usefully exploited. As Mark indicates in notes on his
own opacity investigation, the existing URIspace has several
well-defined dimensions or degrees of freedom. '//' selects between
roots in a (flat or hierarchical, depending on whether hostnames are
opaque) namespace; '/' traverses named links in a single-rooted
graph-structured namespace rooted in the authority, yielding a
two-dimensional object, a directed graph. The addition of properties
via ';' introduces a third dimension to the namespace. The query string
'?' turns each "point" in an arbitrary number of so-far three
dimensional spaces into its own namespace of arbitrary dimensionality or
degree.
There are some conclusions that can be drawn from this. '/' should
*only* be used to represent graph-oriented (commonly incorrectly called
"hierarchical") relationships. Conversely, *all* such relationships
*should* be represented by use of '/'. This is my beef with shoving
stuff into query parameters out of some poorly-conceived concern for
opacity; when you push information into the query string, you lose the
information about the graph-oriented relationships between the parts.
This is a bad thing; we've got a syntax for representing that
information in URI, but concern for "opacity" means that generally
speaking we often can't use it, with the result being less meaningful
names.
jb
> > URIs are opaque at the application level. Client software should not > inspect URIs to try and figure out the structure of a server's data > model. Is it okay for a client to be /told/ what the structure of a server's data model (with respect to URIs) is? and then do URI munging?
----- Original Message -----
From: "Jeff Bone" <jbone@...>
> [...] Informally, '/' should only be used to indicate
> traversal of "links" in a graph-structured namespace. That is, given a
> partial path
>
> a/b/
>
> then the following should hold
>
> a/b/.. == a/
>
This is harder than it looks, if 'b' has more than one incoming pointer
('parent').
Doing lexical operations (fiddling with just the text) will work. Actually
doing the traversals might not work if the traversal algorithm doesn't
remember its sequence of traversed nodes - which implies that ".." will work
only in the context of the full request/transaction/session/whatever. Doing
something like this probably would fail:
get("a").get("b").get("..")
since get("b") rips the state of the resource out of its context.
Jeff Bone wrote: > > Paul Prescod wrote: > > > Now you've given me a problem statement: "How would you handle densely > > packed regularly named namespaces full of opaqaue media objects without > > links between them." Fine. By saying "between them" you've opened the > > door for me to add hypertext that links the documents externally. In > > other words I'm now allowed to use the tool I'm supposed to compare. > > Sorry, "without links to them." Oh, I see. We're back to "Java can't implement this solution unless you use Java." > ... Bottom line, Paul --- although everything on the Web *can* be linked to, > not everything is. Yet everything that is nameable by a URI --- regardless of whether it has inbound or > outbound links in some hyperstructure --- is still part of "the Web." How do we find things that are part of the Web but not hyperlinked? You say by working with names. But that only works a tiny, tiny, tiny fraction of the time. Most of the time you can't find things by guessing at their names. That only works when you have an agreement with the website author. Why wouldn't they express that agreement through hypertext (which is already deployed) rather than a generative grammar language (which isn't)? I'm still waiting for a use case. If you invent a generative grammar language for the Web, I will write a CGI program that allows generative grammars to generate hypertext documents so that the Web subsumes that functionality *through hypertext*. > ... It seems > to me that, by itself, HTTP is the application, not XML or HTML. It seems to me, after months of > consideration, that the problem with Roy's formulation of REST is not that it is too constraining but rather > that it is *not constraining enough* --- it fails to separate the concerns of generic resource modeling and > representational state transfer from the concerns of a particular kind of state that might be transferred, > i.e. hypermedia. But that's a later argument. If we define hypertext as "text with links" then it becomes clear that anything you can represent with plan 9 namespaces I can represent with text with links. The only question is whether the system is closed over hypertext or closed over namespaces or neither. If we obey the opacity principle then it will become closed over hypertext because things without links to them would by definition not be on the Web. But thanks to query parameters and URIs the set of things with links to them is infinite. >... > Yes, you are reduced to "hacking" in this case --- *because* of opacity. No, I'm reduced to hacking because I'm trying to get access to information (the listing of files) that was not provided to me. If it is provided to me as hypertext or a generative grammar I am equally able to get access to it. > ... (The limitation to being the > spider writer should've been clear in the original problem statement.) Dispensing with opacity and > introducing explicit information about organizational schemes and the specific semantics of structured names > elevates that activity to something more disciplined. Okay you're the spider writer. I've just put ten .gif files on my website. Really. To help you along I put your first name in their file names. Go find them. (Please don't brute force my service provider.) If you show me how to solve the problem with namespaces I'll show you how to do it with hypertext. Either the webiste owner is working with you or not. If they are not working with you then there is no reason to believe the names will be consistent because *they own the server side namespace and can name the graphics whatever they want*. That isn't unique to the Web. Every operating system I've ever used allows you to name things more or less whatever you want. Every programming language I've ever used allows you to name things more or less whatever you want. Are you saying the Web should enforce predictable names? If they are working with you then the tried and true and 100% effective way for them to do so is to provide hypertext (either static or dynamic) that provides access to the documents. Paul Prescod
> > Just to clarify, is "ack" a business level ack ("got your offer,
> > I'll check it out and get back to you"), or a transfer level ack
> > ("received your message")?
>
> In RosettaNet and ebXML it's called "receipt acknowledgment" which
> means "message received" and "schema validated". It is business-level
> but should be done quickly and automatically and the contents can be
> stereotyped. It may require non-repudiation of receipt (e.g. digital
> signature). The contents would be archived in a transaction log,
> which I think should be part of the resource model.
>
> There could be other complications, too, but I'll spare you for now.
Ok, so let's say we have this resource which is the thing that is
being negotiated for;
http://company1.com/thing
So company2 becomes aware of this thing, and wants to make an offer for
it. So it does a GET on that URI and retrieves some RDF asserting that
it is of type http://stds.org/product. company2 knows this means that
it can submit an offer document to that URI, so it puts one together and
POSTs it there. company1's software receives the offer, and can do
one of two things;
- respond with an "Acceptance" document immediately
- respond with an "Ack" document, which includes a URI that refers
to the Acceptance or Rejection document in the future.
How's that?
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
"S. Mike Dierken" wrote: > This is harder than it looks, No doubt --- it's taken 30 years for *any* UNIX or derivative to get this right. Cf. "Lexical File Names in Plan 9, or, Getting Dot-Dot Right" by Rob Pike. [1] Interestingly, (a) the algorithm for dealing with dot-dot in Plan 9 is very similar to the way it is handled with relative URI, and (b) in fact they acknowledge this and cite Roy Fielding's earlier work on dealing with this problem. jb [1] http://www.cs.bell-labs.com/sys/doc/lexnames.pdf
I've been working on a Wiki page to describe Generative Naming [1] in more detail, along with some examples of how it might be used to solve problems that hyperstructures cannot or cannot efficiently solve. It's not done, but it's a good and useful start. Check it out if you'd like, feedback appreciated. jb [1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming
See the Wiki: [1] Paul Prescod wrote: > > Sorry, "without links to them." > > Oh, I see. We're back to "Java can't implement this solution unless you > use Java." No. The above is an artificially bogus problem statement, I wouldn't do that to you. The problem I have offered is a much more realistic problem statement grounded in the *fact* that, while there are addressible objects on the Web, not all of them are necessarily part of any hypertext structure. > How do we find things that are part of the Web but not hyperlinked? You get URLs to them in e-mail, or on napkins, or whatever. You ever noticed that field in your browser that you can type things into, or do you always get to every piece of content you access by following links from your home page? ;-) > You > say by working with names. But that only works a tiny, tiny, tiny > fraction of the time. No, it's guaranteed to work *all* the time. Hyperlinks depend on names. Names do not depend on hyperlinks. How you acquire those names is a different matter, but TBL etc. have made it very explicit that the URI space is intentionally constructed to not depend on any given mechanism of name acquisition. > If you invent a generative grammar language for the Web, I will write a > CGI program that allows generative grammars to generate hypertext > documents so that the Web subsumes that functionality *through > hypertext*. Ok. ;-) But first, just to warm up, maybe you should start as follows: write a program that lists all the natural numbers. Report back. ;-) (The fact that you can write a grammar for something doesn't imply that you can practically generate the possibly infinite set of things that the grammar *can* generate.) > If we define hypertext as "text with links" then it becomes clear that > anything you can represent with plan 9 namespaces I can represent with > text with links. It's not a question of representation, it's a question of whether generative, dynamic representations are equivalent to static, declarative representations for all purposes. They aren't. Cf. the Wiki for more detailes, but the following should suggest the problem: while I may be able to write a grammar that generates all possible strings that the grammar can generate, that set may be infinite and might not be enumerable. > The only question is whether the system is closed over > hypertext or closed over namespaces or neither. If we obey the opacity > principle then it will become closed over hypertext because things > without links to them would by definition not be on the Web. This is exactly correct! And the conclusion I've drawn is that (a) the original intent of at least the URI and HTTP architectural components of the Web was that the Web was a superset of the hypertext structure, and (b) the deviation away from those precepts is a cultural artifact of the increasing focus and interest on the part of a few people (TBL) on markup-based KR. But it's not at all clear that markup-based KR can or can best capture all the kinds of information that inhabits a universal information space. > But thanks > to query parameters and URIs the set of things with links to them is > infinite. Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses* information. This is badness. See the Wiki. > > > Yes, you are reduced to "hacking" in this case --- *because* of opacity. > > No, I'm reduced to hacking because I'm trying to get access to > information (the listing of files) that was not provided to me. This is incorrect. I am trying to find objects in a space that is not and perhaps cannot be (or cannot efficiently be) enumerated. And I'm not "hacking," I'm using information about the organization of that space that was explicitly provided to me by the owner of that space to do so. > Okay you're the spider writer. I've just put ten .gif files on my > website. Really. To help you along I put your first name in their file > names. Go find them. (Please don't brute force my service provider.) If > you show me how to solve the problem with namespaces I'll show you how > to do it with hypertext. This wouldn't be an appropriate problem for generative names, it would be like the problem I gave you earlier of enumerating an infinite set. Generative names aren't appropriate for this --- but neither is hypertext, if the set is truly infinite or even very large. I'm not suggesting that generative naming can or should tackle this kind of problem. I am, however, suggesting that there are information spaces which are well-organized, dense, and regular for which this is an efficient and useful technique. Infospaces organized along time and space are good examples. See the Wiki. > Either the webiste owner is working with you or not. If they are not > working with you then there is no reason to believe the names will be > consistent because *they own the server side namespace and can name the > graphics whatever they want*. That isn't unique to the Web. Every > operating system I've ever used allows you to name things more or less > whatever you want. Every programming language I've ever used allows you > to name things more or less whatever you want. Are you saying the Web > should enforce predictable names? Not at all. > If they are working with you then the tried and true and 100% effective > way for them to do so is to provide hypertext (either static or dynamic) > that provides access to the documents. I'm not suggesting that hypertext isn't a good thing, and indeed the right tool in many, many cases. I am suggesting that it is not the right tool for every job, and in many cases where it's not the right tool generative names in structured namespaces are. We have both a hammer (hypertext) and a saw (the URI namespace). We shouldn't use the hammer to try to cut boards. jb [1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming
Mark Baker wrote: > Ok, so let's say we have this resource which is the thing that is > being negotiated for; > > http://company1.com/thing > > So company2 becomes aware of this thing, and wants to make an offer for > it. So it does a GET on that URI and retrieves some RDF asserting that > it is of type http://stds.org/product. company2 knows this means that > it can submit an offer document to that URI, so it puts one together and > POSTs it there. company1's software receives the offer, and can do > one of two things; > > - respond with an "Acceptance" document immediately Easy. > - respond with an "Ack" document, which includes a URI that refers > to the Acceptance or Rejection document in the future. The more interesting case... > How's that? Very simple. Want to keep going? I'm interested to find out if this simple plan will run into trouble in the next user stories. If so, may I change the names from Company1 and Company2 to Seller and Buyer? (Did I assign them correctly? I'll get confused otherwise.) Ok, so we got: http://seller.com/thing -To which URI the Buyer POSTs an offer to buy (i.e. Purchase Order). And I'll focus on the case where the Seller responds to the Buyer with an "Ack" document including a URI referring to an Acceptance or Rejection document in the future. Which the Buyer will check in the future. All the documents except the "Ack" are in the control of the Seller. Sorry if this is tedious, but if I rephrase, it may tell you if I understand or not. Did I? Ok, then, next complication: the offer to buy should not be good forever, it should have a time constraint. At the appointed time, the Buyer could check the URI for the Acceptance or Rejection document and if it's not there, the deal is off. How would you handle that? We want it to be clear to both parties that the deal is off, so they don't end up in court because the Seller tried to keep going. -Bob Haugen
I've read your Wiki and all I can find that makes sense to me is:
"No, Really, WTF Is It Good For?"
Jeff Bone wrote:
>
>...
>
> No. The above is an artificially bogus problem statement, I wouldn't do that to you. The problem I have offered
> is a much more realistic problem statement grounded in the *fact* that, while there are addressible objects on the
> Web, not all of them are necessarily part of any hypertext structure.
And, in general, they are only reachable if somebody wants you to reach
them. The "web way" for them to express that is to give you either a
hard-coded address or a hypertext document. Inventing a new way for
describing sets of documents buys no new power, only complexity.
> > How do we find things that are part of the Web but not hyperlinked?
>
> You get URLs to them in e-mail, or on napkins, or whatever. You ever noticed that field in your browser that you
> can type things into, or do you always get to every piece of content you access by following links from your home
> page? ;-)
Once I type them in I defacto have a hyperlink.
>...
> > If you invent a generative grammar language for the Web, I will write a
> > CGI program that allows generative grammars to generate hypertext
> > documents so that the Web subsumes that functionality *through
> > hypertext*.
>
> Ok. ;-) But first, just to warm up, maybe you should start as follows: write a program that lists all the
> natural numbers. Report back. ;-) (The fact that you can write a grammar for something doesn't imply that you
> can practically generate the possibly infinite set of things that the grammar *can* generate.)
def natural_numbers(startpos, endpos):
for i in xrange(startpos, endpos):
print "<num>%d</num>" % i
Now you can "address" all of the natural numbers through this function.
> > If we define hypertext as "text with links" then it becomes clear that
> > anything you can represent with plan 9 namespaces I can represent with
> > text with links.
>
> It's not a question of representation, it's a question of whether generative, dynamic representations are
> equivalent to static, declarative representations for all purposes. They aren't. Cf. the Wiki for more detailes,
> but the following should suggest the problem: while I may be able to write a grammar that generates all possible
> strings that the grammar can generate, that set may be infinite and might not be enumerable.
You don't have to enumerate them because you are only ever interested in
a subset.
> > The only question is whether the system is closed over
> > hypertext or closed over namespaces or neither. If we obey the opacity
> > principle then it will become closed over hypertext because things
> > without links to them would by definition not be on the Web.
>
> This is exactly correct! And the conclusion I've drawn is that (a) the original intent of at least the URI and
> HTTP architectural components of the Web was that the Web was a superset of the hypertext structure, and (b) the
> deviation away from those precepts is a cultural artifact of the increasing focus and interest on the part of a
> few people (TBL) on markup-based KR. But it's not at all clear that markup-based KR can or can best capture all
> the kinds of information that inhabits a universal information space.
I feel like I'm arguing with you about libertarianism. You aren't trying
to solve a real problem that you've experienced in practice, just trying
to achieve a sort of hypertext-less purity. Well I'm trying to achieve a
hypertext-centric purity. Having the Web be closed over hypertext makes
it a much simpler information space. As you say, generative grammars
don't handle anything either. Next we'll be shipping Javascript
documents with the only goal of generating hyperlinks on the client
side. That's powerful enough that we could do away with hyperlinks and
generative grammars altogether.
> > But thanks
> > to query parameters and URIs the set of things with links to them is
> > infinite.
>
> Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses*
> information. This is badness. See the Wiki.
No, it doesn't lose information. Queries generate *indexes* over
hierarchical information space. The existence of the Google index does
not destroy the hierarchy of MSDN, one of the things it may index.
> >
> > > Yes, you are reduced to "hacking" in this case --- *because* of opacity.
> >
> > No, I'm reduced to hacking because I'm trying to get access to
> > information (the listing of files) that was not provided to me.
>
> This is incorrect. I am trying to find objects in a space that is not and perhaps cannot be (or cannot
> efficiently be) enumerated.
The relevant subsets of the information can be enumerated. The idea "ls
/1999/*/02" you can be expressed as a query with the appropriate
wildcard. The indexed documents may have whatever URI hierarchy you
want, and separately may have whatever HTTP hierarchy you want.
> ... And I'm not "hacking," I'm using information about the organization of that space
> that was explicitly provided to me by the owner of that space to do so.
The Web has a way for them to provide that information to you. It is a
hypertext index. Go to images.google.com. The Web way deals with both
highly structured AND highly unstructured namespaces.
>...
> This wouldn't be an appropriate problem for generative names, it would be like the problem I gave you earlier of
> enumerating an infinite set. Generative names aren't appropriate for this --- but neither is hypertext, if the
> set is truly infinite or even very large. I'm not suggesting that generative naming can or should tackle this
> kind of problem. I am, however, suggesting that there are information spaces which are well-organized, dense, and
> regular for which this is an efficient and useful technique. Infospaces organized along time and space are good
> examples. See the Wiki.
You're an infospace designer. You have two options, one is to provide
access to the infospace through indexes and hypertext. The other is to
provide it through a generative grammer. In the former, all computation
can be done entirely on the server side, requires no more a priori
agreement beyond that necessary to use today's web and allows all
standard web tools to work with the index. The latter requires a new
language: "generative grammars for the web". It requires an agreement to
use this new namespace schema language. It requires new client side
code. The logical index generated on the client side with this
generative technique is not "on the web" (has no URI) and cannot be used
as an input to web processes.
Generating the index on the server reifies it with a URI and generally
builds on existing web infrastructure better.
http://www.somefiles.com/images?subset=/1999/*/02
Paul Prescod
> I've read your Wiki and all I can find that makes sense to me is: > > "No, Really, WTF Is It Good For?" Ditto. There are a lot of people learning REST via the Wiki. We should take care to tag those more, <ahem/>, "controversial" pages as "Not generally accepted as RESTful". But back to Jeff's ideas. Ignoring the so-called dogma for the moment, here's a couple of very practical concerns. First, internationalization. If we agree that /help means "help", shouldn't we also permit /aide to mean the same? And if we do that, do we require bots to understand all languages, and that no new languages be defined? If not, how do you deploy new languages? You need a layer of indirection here, something to assert "this URI is of this type". Second, if my namespace already includes a "/help" - perhaps I use it as the name for my "happy elves love partying" resource - does that mean that I can't use the help/contact/search system? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > How do we find things that are part of the Web but not hyperlinked? You > say by working with names. But that only works a tiny, tiny, tiny > fraction of the time. Most of the time you can't find things by guessing > at their names. That only works when you have an agreement with the > website author. Why wouldn't they express that agreement through > hypertext (which is already deployed) rather than a generative grammar > language (which isn't)? I'm still waiting for a use case. Aren't HTML FORM elements a set of inputs to some agreed-upon-instructions for generating URIs?
> > If you invent a generative grammar language for the Web, I will write a > CGI program that allows generative grammars to generate hypertext > documents so that the Web subsumes that functionality *through > hypertext*. > I have a flat list of 100K users. Each are URI addressable. This is goodness. I have a username from another source (an email address for example). I know they are (or might be) somewhere in that list... how do I get the URI for it? Sure.... I could do a query... but that would need a URI & I'd have to.. generate one. Sure... I could GET the index (100K times the size of a record in markup...) then search locally. But I (a lazy programmer) don't want to. I can't go upstream to the original source & tell it to give me identifiers used by a different system. What now? (if this is a different problem, feel free to correct me...) Mike
> > Sorry, "without links to them." Bottom line, Paul --- although everything on the Web *can* be linked to, > not everything is. Yet everything that is nameable by a URI --- regardless of whether it has inbound or > outbound links in some hyperstructure --- is still part of "the Web." This is an important point. When at a company that shall remain nameless, I boiled down information systems into several aspects - not all being provided or efficient, but you could talk about the system in those terms: - read/write - address/reference - discovery - query - transform (above that there is security, events and transactions, but they are in a different category). Not all system have a way to do all these seven things - some are easy to read and hard to write back to. Some have no discovery - or at least no standard interoperable discovery mechanism. For example, in SQL you can reference a table, but I don't know of a (standard) way to list them. Anyway.. I think Jeff has a good point that sometimes you don't have a good way to discover instances of the remote server's public identifiers for information, but you do have a good way to create those identifiers via patterns of some kind. The view that everything can and should be discoverable through receiving the value from the server might be an analogous argument to the 'every operation can be get/put/post/delete combined with many objects',. but this time I'm not on the same side. Examples help. How do I take an email address and get a users profile from a URI addressable directory service?
> > And I'll focus on the case where the Seller responds to the Buyer > with an "Ack" document including a URI referring to an Acceptance or > Rejection document in the future. Which the Buyer will check in the > future. All the documents except the "Ack" are in the control of the > Seller. [...] > > Ok, then, next complication: the offer to buy should not be good > forever, it should have a time constraint. At the appointed time, > the Buyer could check the URI for the Acceptance or Rejection > document and if it's not there, the deal is off. How would you > handle that? I think that this probably is an application level concept, so should go in the response body - some xml format. I don't know if web resource have a concept of lifetime. There is an 'Expires' header - but this is meant for caching. "The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. " http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21 I'd still consider using it though...
----- Original Message ----- From: "Jeff Bone" <jbone@...> > Check it out if you'd like, feedback appreciated. > > [1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming > --- "Myth #6: Link Topologies Can Do Everything Structured Names Can Consider the following task. I am a Web crawler, and I want to find every publically available object that is served up by a Web server. This Web server contains and makes available one or more objects that are not linked to by any other object. If the server provides information which I can use to dynamically understand and generate structured names in its namespace, I may be able to find those objects. If names are opaque and I am restricted to traversing the hypergraph topology, finding the objects that are not linked to is impossible. See GenerativeNaming for more examples of how constructable semantic names can sometimes be more expressive or efficient or enable things that can't be done with graph traversal. " --- I'd like to examine this part "This Web server contains and makes available one or more objects that are not linked to by any other object." In the scenerios I can think about (a large database of one table), the objects /are/ linked by another object - the db table - but that other one isn't 'public'. I would re-phrase this (to describe my scenario) to "This Web server contains and makes available one or more resources that are not linked to by any other publicly available resource." What I'm getting at is that the linking is there, but it is not made visible publicly. Sometimes it's not visible due to lazy programmers like me, but many times it isn't feasible to just list all known resources (transfer the state of the index of the table). Making the private resource into a public resource would help. You could define 'views' over this resource and list all those - which brings you back to hyperlinking - but you'd need to know the name of the view. Which is still an issue, but not one that requires generating a structured name. This would bring some scenarios into the hypermedia fold (the HyperFold(tm)) - but that isn't practical for everything. For example a DB resource could have a representation like: <table> <allVCRs>/data/query?dev=vcr</allVCRs> <allUsers>/data/users/list</allUsers> </table> You still need to know names (e.g. 'allUsers') but you don't have to construct them. I do think generative naming is very useful but I'm thinking of the case where you have to translate addresses. Two disparate systems have 'local' names for something and don't know about each other. You receive a name from serviceA and need to do something via serviceB. Defining a pattern based mapping is handy. I don't know how to do it otherwise. Anyone? Anyone?
Paul Prescod wrote:
> I've read your Wiki and all I can find that makes sense to me is:
>
> "No, Really, WTF Is It Good For?"
I know. Try harder. (Do you have any *substantive* criticism, or are we reduced to taking pot shots? ;-)
> And, in general, they are only reachable if somebody wants you to reach
> them.
But linking to them via hypertext is *explicitly* not the only means of making them available and communicating that
availability. Napkins, billboards, voice convo, e-mail, etc.
> The "web way" for them to express that is to give you either a
> hard-coded address or a hypertext document. Inventing a new way for
> describing sets of documents buys no new power, only complexity.
I've already given you many specific examples and general explanations.
> Once I type them in I defacto have a hyperlink.
No, you de facto have a URI. A URI is not a hyperlink --- a URI embedded in hypertext is a hyperlink. Whether you have
a hyperlink or not depends on whether it occurs in a recognizable hypertext.
> def natural_numbers(startpos, endpos):
> for i in xrange(startpos, endpos):
> print "<num>%d</num>" % i
>
> Now you can "address" all of the natural numbers through this function.
No, I didn't say in some range, I said *all of them.* (Hint: it was a joke, Paul. The point should be clear: you
can't list an infinite set.)
> You don't have to enumerate them because you are only ever interested in
> a subset.
But the server cannot a priori know what subset I'm interested in. Therein lies the problem. Consider a resource
representing the digits of pi. I'd like to be able to address specifically the digits of pi. The ordinal position of a
digit of pi bears a subordinate, hierarchical relationship to the sequence of digits that make up pi. I'd like to be
able to say
http://www.constants.com/pi/2036
rather than
http://www.constants.com/pi?digit=2036
Why? Because the meaning of the first is clearer by virtue of the use of the hierarchical path syntax, while the
meaning of the second is not as clear. This is a bit of a weak example, because the first is not a *lot* clearer than
the second, but you get my drift. At least, in the first example, the index *is* the namespace rather than being an
adjunct to it. Pi and pi's 2036th digit are both equally first-class entities, though the latter is "subordinate" to
the former.
> I feel like I'm arguing with you about libertarianism.
This is a scientific and engineering discussion, not a political discussion. At least it should be --- that's what I'm
trying to keep it at.
> You aren't trying
> to solve a real problem that you've experienced in practice, just trying
> to achieve a sort of hypertext-less purity.
No, I'm trying to avoid cutting boards with hammers. We have *two* powerful abstractions with the Web: the URI
namespace and hypertext. We should use them both.
> Well I'm trying to achieve a
> hypertext-centric purity.
So here we have it --- you're the one with the political agenda, here. The Web is undergoing a revisionist movement
called "The Semantic Web." People have problems grokking namespaces, while everybody understands (some) graph theory.
Let's get rid of the troublesome namespaces! Problem is, there are things namespaces are good for that graphs are not.
> Having the Web be closed over hypertext makes
> it a much simpler information space. As you say, generative grammars
> don't handle anything either. Next we'll be shipping Javascript
> documents with the only goal of generating hyperlinks on the client
> side. That's powerful enough that we could do away with hyperlinks and
> generative grammars altogether.
Javascript documents that generate hyperlinks would be a form of generative "grammar" or an equivalent generative
system.
>
> > Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses*
> > information. This is badness. See the Wiki.
>
> No, it doesn't lose information. Queries generate *indexes* over
> hierarchical information space. The existence of the Google index does
> not destroy the hierarchy of MSDN, one of the things it may index.
It loses information *in the URI.* This is clear. Think about it.
> The relevant subsets of the information can be enumerated.
Again the problem is that the server cannot know a priori which subset is interesting, so it cannot be enumerated in
hypertext, only indirectly represented via a partial name. This name *can* be represented as a query string, at the
expense of losing information about the relationships between the query parameters and between those parameters and the
overall information space being modeled.
> The Web has a way for them to provide that information to you. It is a
> hypertext index. Go to images.google.com. The Web way deals with both
> highly structured AND highly unstructured namespaces.
It also has a mechanism called "URI" that can be used to represent highly organized information spaces directly.
> You're an infospace designer. You have two options,
Not an either-or choice, but one to be informed by the problem you're modeling.
> Generating the index on the server reifies it with a URI and generally
> builds on existing web infrastructure better.
> http://www.somefiles.com/images?subset=/1999/*/02
This is a good and noble goal, and should be pursued wherever possible. Sometimes, though, these indices cannot be
reified; rather, the relevant information must be computed. Generative naming works in this case; hypertext per se
does not. In the case of generative naming, the namespace *is* the index.
jb
Mark Baker wrote:
> Ditto. There are a lot of people learning REST via the Wiki. We should
> take care to tag those more, <ahem/>, "controversial" pages as "Not
> generally accepted as RESTful".
This is a reasonable request. I have now marked the documents in question in
the following manner, at the top of the page:
Note: THIS DOCUMENT CONTAINS REST HERESY.
> But back to Jeff's ideas. Ignoring the so-called dogma for the moment,
> here's a couple of very practical concerns.
>
> First, internationalization.
It's no more or less a problem here than it is in agreeing on XML tag name
choices in "standardized" schemas, etc., and then dealing with
transformations between language representations of tag name choices.
> You need a layer
> of indirection here, something to assert "this URI is of this type".
As mentioned, the semantic information about what particular name elements
needs to be represented elsewhere. I'll go further: not only do complete
URI need to be typed, but their parts need to be typed.
> Second, if my namespace already includes a "/help" - perhaps I use it
> as the name for my "happy elves love partying" resource - does that mean
> that I can't use the help/contact/search system?
Good question. The answer at first seems to be yes, and this seems to be a
weakness. The mechanism for avoiding this problem is the same as it is in
XML: introduce namespaces inside URI components to avoid collision. But we
don't even have to do anything to introduce those; the ';' property space
does our job for us. Instead of namestd:help you have help;namestd or what
have you.
jb
"S. Mike Dierken" wrote: > I would re-phrase this (to describe my scenario) to "This Web server > contains and makes available one or more resources that are not linked to by > any other publicly available resource." This is a good point, thanks! A further point is that the scenario only makes sense for sets of objects for which some predictable naming scheme conceptually exists. (Thanks also to Paul for his rather ridiculous but pertinent example about sparse, irregular spaces in some earlier message; I never imagined using names for those, but it's good to be clear.) I have changed to wording to: "This Web server contains and makes available one or more resources that are not linked to by any other publicly available resource, but for which one or more predictable naming schemes conceptually exists." > I do think generative naming is very useful but I'm thinking of the case > where you have to translate addresses. Two disparate systems have 'local' > names for something and don't know about each other. You receive a name from > serviceA and need to do something via serviceB. Defining a pattern based > mapping is handy. I don't know how to do it otherwise. Anyone? Anyone? Hmmm... this is an interesting point. Want to elaborate? jb
It's seeming to me like generative naming vs. hypermedia discussion all boils down to algorithms and data structures. An XML document is a data structure; the hyperstructure of the Web is a data structure. Some data structures can encode algorithms --- for example, an XSLT transform is an XML data structure that is also a Turing-complete algorithmic language. The hyperstructure of the Web is not an algorithmic language. It is well-known that algorithms can represent things that cannot be explicitly represented without computation. If URIspace is intended to contain all possible information --- and I assume that it is --- then non-generative naming and hypermedia are not sufficient by themselves to refer to all the things URIspace is intended to contain. Generative names are not Turing-complete algorithmic languages either, of course, but they do provide a mechanism by which references to objects may be computed. Without generative names, the Web can contain things that cannot be referred to without a priori knowledge of the thing. Give a person a fish, and you've fed him dinner. Teach a person to fish, and you've fed them for life. Give a person a URI, and you've given him a reference to a resource. Teach a person to make URIs to your resources, and you've given him references to all of them. Just a thought before bed. jb
One point. Paul actually brings up an interesting possibility re: my motivation in pressing the issue of URI opacity: > You aren't trying to solve a real problem that you've experienced in practice, > just trying to achieve a sort of hypertext-less purity. In fact this isn't at all the case. Most of the thorniest technical problems I've dealt with in my entire career have all touched on the stuff we're talking about: from mapping and transforming between arbitrary data models at Evolutionary Technologies* a over a decade ago to exposing an information model for presence in URIspace at Activerse to exposing a rich and flexible ontological model for online news in HTTPspace at Clickfeed to filesystem namespace wrangling and breaking the barriers between filesystem and Web at Deepfile. In particular, opaque URIs make my job harder at Deepfile in ways that I can't really discuss in detail until we open the kimono on what we're doing. Throughout all of these, it's become clear that namespaces --- abstract machines which resolve semantically-meaningful names into things --- are incredibly powerful tools for solving a variety of problems. We've got one of those tools in URIs, I just hate to see us lose the use of it for obscure, political / cultural, or mistaken reasons. The fact that I'm invoking some theoretical arguments to support what I'm asserting doesn't mean that the point is academic; it means that the theoretical arguments demonstrate (or at least should be evocative of familiar) definitive generalizations. I've admittedly not done as good a job as I would like with those arguments, but the points we're dicussing touch some very fundamental and philosophical parts of computer science such as computability, identity, representability, information theory, and so on. I've tried to supplement these with some toy but concrete examples that illustrate the points I'm making. I'm happy to add more (and more detailed) examples, if that's useful, and if anyone else can think of any good examples (or counterexamples) I'm happy to add them. I'd like to communicate the problem well enough for people to understand --- but this may indeed be as subtle and thorny a topic to the RESTful as REST itself is to the RPC enthusiast or Web layman. Cheers, jb
> > > > I do think generative naming is very useful but I'm thinking of the case > > where you have to translate addresses. Two disparate systems have 'local' > > names for something and don't know about each other. You receive a name from > > serviceA and need to do something via serviceB. Defining a pattern based > > mapping is handy. I don't know how to do it otherwise. Anyone? Anyone? > > Hmmm... this is an interesting point. Want to elaborate? > At the risk of my train of thought being derailed... A lot of information systems have 'fragments' that can be passed to other systems to control other information. These are like partial hyperlinks - they aren't ready to be used without adjusting for the target information system. In a RDB the values in one table don't say much about whether you can use them against another table, or in another database or a the file system, etc. The 'base' part of database means its all been normalized. You need a third thing to link the two systems together - thats what the set of queries are after all (sure sure foreign key constraints, blah blah blah...). These 'fragments' of an address are just relative locations. If I wanted to take data that contained 'hidden' or 'truncated' hyperlinks and make visible the links lurking within, the values need to 'bubble up' through name translation. From the value in a table, to the name of the table, to the name of the database to the name of the db server, etc. Expressing this name translation symbolically is what most web software (the procedural code aspects) does today. This is probably just a convoluted description of 'link re-writing'. Doing this 'link re-writing' assumes you know what is being referenced by the link - and that's where the problem comes in. You can generate many different views, but someone will always want something different. They will know about a third information system that uses the same value as a lookup name, but you don't know anything about it and so cannot generate the link to it. You have to provide a 'relative name' and let the client/intermediary do the rest. I see the power of information in the 'joins' between data systems. Taking values from one place (email addresses from an ldap server) and generating references into another (home folders on disk, searches on google, entries at hotornot, inboxes at hotmail, etc.) is easy and leads to cool systems like the web itself. Doing this by keeping an explicit instance-based mapping is tedious and unnecessary. Generating the links via symbolic descriptions of the naming transform sounds looks better to me. mike 'sleepyhead' d
"S. Mike Dierken" wrote: > >... > > I have a flat list of 100K users. Each are URI addressable. This is > goodness. Great. > I have a username from another source (an email address for example). I feel a query coming on.... > I know they are (or might be) somewhere in that list... how do I get the URI > for it? You can't. Either the information owner has given you a way to map from email addresses to URIs or they haven't. Jeff's way to do the mapping is to have the information owner specify (how?) that email addresses may be plugged in to URIs. The Web way is for the informatoin owner to create a query that maps from email addresses to URIs. The Web way allows 50K of the users to live at one domain and 40K at another and 10K at another. > Sure.... I could do a query... but that would need a URI & I'd have to.. > generate one. Don't follow this point. You need *something*. The information owner has to provide a mapping somehow. Either it is a query URI or it is a "generative grammar" URI or it is a prose email from the information owner. Paul Prescod
> This is a reasonable request. I have now marked the documents in question in > the following manner, at the top of the page: > > Note: THIS DOCUMENT CONTAINS REST HERESY. Thanks. 8-) > > But back to Jeff's ideas. Ignoring the so-called dogma for the moment, > > here's a couple of very practical concerns. > > > > First, internationalization. > > It's no more or less a problem here than it is in agreeing on XML tag name > choices in "standardized" schemas, etc., and then dealing with > transformations between language representations of tag name choices. I think it is substantially different. Representations can be transformed willy nilly with no implication, but names cannot. > > You need a layer > > of indirection here, something to assert "this URI is of this type". > > As mentioned, the semantic information about what particular name elements > needs to be represented elsewhere. I'll go further: not only do complete > URI need to be typed, but their parts need to be typed. "need" as in "must"? If so, you're placing quite a burden on namespace owners. I should be able to create http://foo.org/a/b/c/d/e/f/g without any worry that people will assume certain things about that means, which may place additional obligations on me as webmaster. > > Second, if my namespace already includes a "/help" - perhaps I use it > > as the name for my "happy elves love partying" resource - does that mean > > that I can't use the help/contact/search system? > > Good question. The answer at first seems to be yes, and this seems to be a > weakness. The mechanism for avoiding this problem is the same as it is in > XML: introduce namespaces inside URI components to avoid collision. But we > don't even have to do anything to introduce those; the ';' property space > does our job for us. Instead of namestd:help you have help;namestd or what > have you. URI parameters have no global meaning, if that's what you're suggesting. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Mike Dierken" wrote: > > > > > URIs are opaque at the application level. Client software should not > > inspect URIs to try and figure out the structure of a server's data > > model. > > Is it okay for a client to be /told/ what the structure of a server's data > model (with respect to URIs) is? and then do URI munging? First, let's acknowledge that "URI munging" is sometimes necessary. That's why the Web infrastructure has explicit support for it, as you say: > Aren't HTML FORM elements a set of inputs to some agreed-upon-instructions > for generating URIs? So the opacity principle has always been: opacity by default and transparency when you need it. WRDL even deepens the support for URI generation through strong typing etc. And this interoperates with the hierarchical parts of the URI because the query typically generates an index OVER the hierarchical namespace. It's like a Unix "find" command. The find command itself is non-hierarchical but the results it returns are in a hierarchical space. So now that we've agreed that URI munging is necessary (as Tim Berners-Lee did in his 1996 document on URI opacity), Jeff's instinct is to open the floodgates and allow arbitrary manipulations of URIs. In theory, this is probably okay as long as it is under complete server control (as HTML forms and query parameters are). But what would it take to make it really work reliably on the Web? Jeff suggests that we need a set of generative grammar schema languages that can be shared between client and server. And we need a form of "namespaces" for URIs. And we need strong typing for components of namespaces. And...etc. etc. Can you see that he is going to end up reinventing everything that has been done in the markup world? And he won't make a single "opaque data object" addressable that would otherwise be non-addressable because it will take *effort* on the part of the information owner to generate these generative grammars and they could just as easily implement an index using queries today. So we'll put in a bunch of effort inventing a bunch of new technologies that buy no new power. Really, the question boils down to whether the mapping from primitive values (e.g. dates) to addressable objects (e.g. dated webcam snapshots) happens on the client or the server. And we all know about the effort it takes to deploy new technologies on the client (browsed many XML/XSLT pages lately?) versus the server. So the whole project is doomed from the start because it doesn't buy anything and it has tremendous costs. Paul Prescod
> I have a flat list of 100K users. Each are URI addressable. This is > goodness. > I have a username from another source (an email address for example). > I know they are (or might be) somewhere in that list... how do I get the URI > for it? > Sure.... I could do a query... but that would need a URI & I'd have to.. > generate one. > Sure... I could GET the index (100K times the size of a record in markup...) > then search locally. But I (a lazy programmer) don't want to. > I can't go upstream to the original source & tell it to give me identifiers > used by a different system. > What now? If "I" here is just you, the resource publisher, then you do whatever the heck you want with it because you know what the namespace semantics are. The issue is, can somebody else infer that because they see; http://www.dierken.com/email/foo@... that there exists a URI http://www.dierken.com/email/asdfasdf@... I say no, unless somehow dierken.com asserts that /email is a container of arbitrary email addresses. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"S. Mike Dierken" wrote: > >... > > Examples help. How do I take an email address and get a users profile from a > URI addressable directory service? People do this stuff on the Web every day: http://www2.1800ussearch.com/search/teaser.cgi?searchLName=Prescod&searchMName=&searchCity=&searchState=&searchApproxAge=&searchFName=Paul&resultID=115672819--9649017-0&adID=1007001 Paul Prescod
Mark Baker wrote: > >... > > If "I" here is just you, the resource publisher, then you do whatever > the heck you want with it because you know what the namespace semantics > are. > > The issue is, can somebody else infer that because they see; > > http://www.dierken.com/email/foo@... > > that there exists a URI > > http://www.dierken.com/email/asdfasdf@... > > I say no, unless somehow dierken.com asserts that /email is a container > of arbitrary email addresses. I agree 100%. And if they want to make this assertion on *today's web* they use a servlet with query parameters. Of course for now the assertion probably has both prose and declarative components. The prose part is: "you can plug in an email address from X". The declarative part is that the syntax of the parameter must be an email address. As the semantic web progresses we'll hopefully move more of the semantics into the declarative bit... Paul Prescod
Jeff Bone wrote: > > It's seeming to me like generative naming vs. hypermedia discussion all boils > down to algorithms and data structures. An XML document is a data structure; > the hyperstructure of the Web is a data structure. Some data structures can > encode algorithms --- for example, an XSLT transform is an XML data structure > that is also a Turing-complete algorithmic language. The hyperstructure of the > Web is not an algorithmic language. Sounds like hand waving to me. As you admit below, Turing-completeness is irrelevant because neither model is Turing-complete. > It is well-known that algorithms can represent things that cannot be explicitly > represented without computation. If URIspace is intended to contain all possible > information --- and I assume that it is --- then non-generative naming and > hypermedia are not sufficient by themselves to refer to all the things URIspace > is intended to contain. Generative names are not Turing-complete algorithmic > languages either, of course, but they do provide a mechanism by which references > to objects may be computed. As do query parameters. > .... Without generative names, the Web can contain things > that cannot be referred to without a priori knowledge of the thing. If someone tells you that his website is organized as /foo/$year/$month/$index then you HAVE a priori knowledge of all of the things so addressed. It's just a very compact syntax for that knowledge. Using a query you can reference the *same thing*, through one level of indirection. document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href)) The only question is whether the $-variable to URI mappings happens on the client or the server. The set of addressable objects is exactly the same. Paul Prescod
> > So now that we've agreed that URI munging is necessary (as Tim > Berners-Lee did in his 1996 document on URI opacity), Jeff's instinct is > to open the floodgates and allow arbitrary manipulations of URIs. I think this is incorrect. Defining a subset of all possible URI manipulation along with rules doesn't sound like 'floodgates'. Clarifying existing practice and extending that to other declarative forms sounds like it will strengthen the Web, not weaken it. JeffB consistently says that it is only one of many tools and can/should be used only in certain classes of problems, and he says that otherwise a pure hyperlink approach is better. http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming "It's not good for characterizing sparse or irregular information spaces. And generally, they are no substitute for hypertext unless the abstraction being represented just cannot be efficiently represented in hypertext" "The bottom line is that names and graphs are different tools that are *both* fundamental components of the Web architecture, and you should use the right tool for the job" Take the example of 100K user profiles, indexed by email address. JeffB & PaulP - show me each of your approaches. More than one example is fine, since that helps explain things to me.
Jeff Bone wrote: > > Mark Baker wrote: > > > Ditto. There are a lot of people learning REST via the Wiki. We should > > take care to tag those more, <ahem/>, "controversial" pages as "Not > > generally accepted as RESTful". > > This is a reasonable request. I have now marked the documents in question in > the following manner, at the top of the page: > > Note: THIS DOCUMENT CONTAINS REST HERESY. While we're making editorial changes, its a weak rhetorical trick to equate the opacity axiom to the onion analogy. The onion was a bit of superstitious nonsense with no chemical backing whatsoever. The fact that we've been arguing about this for several days indicates that we have a legitimate technical disagreement like the difference between the Java and C# floating point models. > ... I'd like to communicate the problem well > enough for people to understand --- but this may indeed be as > subtle and thorny a topic to the RESTful as REST itself is to the > RPC enthusiast or Web layman. Actually, we've had pretty good success explaining the benefits of REST to the RPC crowd. There are things you can do with hypertext and addressing that are painful to the extent of being impossible to do without them. RPC people who are willing to think about it long enough to argue about it tend to come around. I don't see it in this case. Every time you present a use-case that doesn't explicitly deny me the right to use hypertext, I can present a hypertext solution to the problem. In fact, I can mechanically translate your generative grammars definitions into hypertext solutions. It's just a matter of moving the string replacement from the client to the server and adding a level of indirection. Paul Prescod
> > And, in general, they are only reachable if somebody wants you to reach > > them. > > But linking to them via hypertext is *explicitly* not the only means of making them available and communicating that > availability. Napkins, billboards, voice convo, e-mail, etc. That's the same thing. There is no "linking to them" separate from simply "writing down their URI". > > Once I type them in I defacto have a hyperlink. > > No, you de facto have a URI. A URI is not a hyperlink --- a URI embedded in hypertext is a hyperlink. Whether you have > a hyperlink or not depends on whether it occurs in a recognizable hypertext. Well, "hypertext" is just text with URIs. Nothing says the text has to give URIs special status. For example, email clients are doing the right thing when they make URIs clickable that are embedded in a plain text email. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > >... > > > def natural_numbers(startpos, endpos): > > for i in xrange(startpos, endpos): > > print "<num>%d</num>" % i > > > > Now you can "address" all of the natural numbers through this function. > > No, I didn't say in some range, I said *all of them.* (Hint: it was a joke, Paul. The point should be clear: you > can't list an infinite set.) No, you can't list them. You can *represent them*. On the web we do that with query-generated indexes. You want to do it with client-side generative grammars. I'm waiting for a *concrete* benefit. > > You don't have to enumerate them because you are only ever interested in > > a subset. > > But the server cannot a priori know what subset I'm interested in. That's why you supply *query parameters*. > ... Therein lies the problem. Consider a resource > representing the digits of pi. I'd like to be able to address > specifically the digits of pi. The ordinal position of a > digit of pi bears a subordinate, hierarchical relationship to > the sequence of digits that make up pi. I'd like to be > able to say > > http://www.constants.com/pi/2036 > > rather than > > http://www.constants.com/pi?digit=2036 That's absolutely fine. The latter can be either a redirect to the former or an index page that returns a link to the former or both. > Why? Because the meaning of the first is clearer by virtue of the use of the hierarchical path syntax, while the > meaning of the second is not as clear. This is a bit of a weak example, because the first is not a *lot* clearer than > the second, but you get my drift. Do you have any examples that are not a bit weak??? > ... At least, in the first example, the index *is* the namespace rather than being an > adjunct to it. Pi and pi's 2036th digit are both equally first-class entities, though the latter is "subordinate" to > the former. That's fine. Use the query as an index over or redirect to the hierarchical version. Anyhow, you're begging the question. You start with the premise that it is important to represent hierarchies in the URI. Actually, this is just a convenience that makes mapping between file systems and URIs easier. It is not core to the web architecture at all. > > I feel like I'm arguing with you about libertarianism. > > This is a scientific and engineering discussion, not a political discussion. At least it should be --- that's what I'm > trying to keep it at. My point is that your arguments in each situation are not problem-driven, they are theory-driven. If you had approached this whole situation like: "I was working on this problem and I found it very hard to solve with existing techniques." I can solve your problem of finding graphics that have no links on the Web using CGI. Yes, it requires coordination with the server creator. BUT SO DOES YOUR SOLUTION. >... > > No, it doesn't lose information. Queries generate *indexes* over > > hierarchical information space. The existence of the Google index does > > not destroy the hierarchy of MSDN, one of the things it may index. > > It loses information *in the URI.* This is clear. Think about it. Google loses information in MSDN's URIs? That's ridiculous! The object's canonical URI does not change because someone, somewhere has indexed it. > > The relevant subsets of the information can be enumerated. > > Again the problem is that the server cannot know a priori which subset is interesting, so it cannot be enumerated in > hypertext, only indirectly represented via a partial name. This name *can* be represented as a query string, at the > expense of losing information about the relationships between the query parameters and between those parameters and the > overall information space being modeled. The query-based URI does not necessarily reference the resource. It can be the canonical name for the object, or an alternate name for the resource, or a redirect to the resource or provide a reference to the resource. >... > > builds on existing web infrastructure better. > > http://www.somefiles.com/images?subset=/1999/*/02 > > This is a good and noble goal, and should be pursued wherever possible. Sometimes, though, these indices cannot be > reified; rather, the relevant information must be computed. What do you think images.cgi does? It's a computation! Paul Prescod
"S. Mike Dierken" wrote: > > JeffB consistently says that it is only one of many tools and can/should be > used only in certain classes of problems, and he says that otherwise a pure > hyperlink approach is better. > ... That sounds very reasonable. But the hyperlink model is complete, in the same way that GET/PUT/POST/DELETE is complete. In the same way that lambda calculus primitives are complete. So Jeff needs to show that his way is simpler. Rather, he's shown how he can recreate all of the complexity of markup (namespaces, interfaces, generative schemas) in namespaces. So we double the complexity without increasing the descriptive power at all. >... > > Take the example of 100K user profiles, indexed by email address. JeffB & > PaulP - show me each of your approaches. More than one example is fine, > since that helps explain things to me. I thought I did this already. There are 100K user profiles. There are 100K email addresses somewhere else. Somehow we have to communicate from the client to the server that there is a mapping from email addresses to URIs. I can only roughly guess at Jeff's approach (he hasn't elaborated it except in bits and pieces) but it seems like it would involve sending something like this from server to client: <uri_remapping> <variable name="userid" type="EmailAddress"> <remapping href="http://www.userprofiles.com/profiles/$userid"> </uri_remapping> The client needs to know how to interpret this as an assertion that email addresses can be plugged in to get back URIs. Whereas, I would send something like: <form method="GET" target="http://www.profiles.com/profile_for_id"> <input name="userid" type="email_address"/> </form> A three-line servlet returns a redirect to http://www.userprofiles.com/profiles/$userid My solution is equally powerful, uses only currently-deployed technologies and lets the server name things however it wants. Paul Prescod
On Sat, Mar 09, 2002 at 11:41:27AM -0800, Paul Prescod wrote: > While we're making editorial changes, its a weak rhetorical trick to > equate the opacity axiom to the onion analogy. The onion was a bit of > superstitious nonsense with no chemical backing whatsoever. The fact No, not superstition. It was a kludge that was later taken to have been a design decision. Though that may not make the argument any stronger. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Paul Prescod wrote: > > I have a username from another source (an email address for example). > > I feel a query coming on.... Semantic names are queries. > > I know they are (or might be) somewhere in that list... how do I get the URI > > for it? > > You can't. Only because of the delusion of opacity! You can't use the axiom of opacity to argue for the axiom of opacity, Paul! In fact you *can* get that URI if you know how to build it. > The Web way is for the informatoin owner to create a > query that maps from email addresses to URIs. The In other namespace-oriented applications, the namespace can *encode* that query in a useful, meaningful way. > Web way allows 50K of > the users to live at one domain and 40K at another and 10K at another. This ability is not unique to the "Web way" of having part of that information in an opaque string and part in a transparent string. jb
Paul Prescod wrote:
> Can you see that he is going to end up reinventing everything that has
> been done in the markup world? And he won't make a single "opaque data
> object" addressable that would otherwise be non-addressable because it
> will take *effort* on the part of the information owner to generate
> these generative grammars and they could just as easily implement an
> index using queries today. So we'll put in a bunch of effort inventing a
> bunch of new technologies that buy no new power.
Aha! Here's another one that's easy to knock down. It's often a *lot* easier
to write down a scheme for naming in a useful manner than it is to provide
either a query capability *beyond* namespace organization *or* an explicit which
can be used to find things. If namespace owners can describe the structures of
their information spaces as easily as something like
http://smartspace.com/<user>/<building>/<room>/<device>
then more structure will be imposed, resulting in better organized and more
useful information on the Web. To the extent that "new technology" needs to be
invented in order to use semantic naming, the power it "buys" is expressivity.
And that *is* important and useful.
> And we all know about the effort it
> takes to deploy new technologies on the client (browsed many XML/XSLT
> pages lately?) versus the server. So the whole project is doomed from
> the start because it doesn't buy anything and it has tremendous costs.
This is an absolutely ridiculous non-sequiter conclusion, you know? I'm not
quite sure what all this scary "new technology" you think is necessary actually
is. At a minimum, all a server would need to do to use structured names is
write the rules down in English on a Webpage for how to construct URI to their
resources of interest. Humans *and* developers could then use those rules as
they saw fit, or not.
jb
Mark Baker wrote: > > It's no more or less a problem here than it is in agreeing on XML tag name > > choices in "standardized" schemas, etc., and then dealing with > > transformations between language representations of tag name choices. > > I think it is substantially different. Representations can be > transformed willy nilly with no implication, but names cannot. Hmmm.... is that true? Think about it. > > Good question. The answer at first seems to be yes, and this seems to be a > > weakness. The mechanism for avoiding this problem is the same as it is in > > XML: introduce namespaces inside URI components to avoid collision. But we > > don't even have to do anything to introduce those; the ';' property space > > does our job for us. Instead of namestd:help you have help;namestd or what > > have you. > > URI parameters have no global meaning, if that's what you're suggesting. That's not what I'm suggesting --- the mechanism I'm talking about is a way to distinguish otherwise identical parts at some position in the path, i.e. /help;mine from /help;std etc. jb
Paul Prescod wrote: > If someone tells you that his website is organized as > /foo/$year/$month/$index then you HAVE a priori knowledge of all of the > things so addressed. It's just a very compact syntax for that knowledge. Yes!! YES!!! This is EXACTLY what I'm talking about!!! > Using a query you can reference the *same thing*, through one level of > indirection. > > document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href)) No. It's not the same. The case above is both more complex syntactically and *less* meaningful. By pushing things into the query string, you've lost the knowledge that $month bears a subordinate relationship to $year. jb
Paul Prescod wrote: > While we're making editorial changes, its a weak rhetorical trick to > equate the opacity axiom to the onion analogy. The onion was a bit of > superstitious nonsense So is the opacity axiom. jb
Paul Prescod wrote: > The only question is whether the $-variable to URI mappings happens on > the client or the server. The set of addressable objects is exactly the > same. BTW, of *course* the set of addressible objects is going to be the same as long as opacity is allowed to be violated somewhere in the name. My contention is simply that --- contrary to popular mistaken belief --- the world isn't going to come to an end if we start allowing all the various pieces of the URI syntax to be usefully exploited. jb
Paul Prescod wrote: > That sounds very reasonable. But the hyperlink model is complete, in the > same way that GET/PUT/POST/DELETE is complete. In the same way that > lambda calculus primitives are complete. How many times to I have to demonstrate that it's *not* complete? > So Jeff needs to show that his > way is simpler. How many examples do you need? Tell me what it requires, I'll provide it. jb
> Ok, so we got: > http://seller.com/thing > > -To which URI the Buyer POSTs an offer to buy (i.e. Purchase Order). > > And I'll focus on the case where the Seller responds to the Buyer > with an "Ack" document including a URI referring to an Acceptance or > Rejection document in the future. Which the Buyer will check in the > future. All the documents except the "Ack" are in the control of the > Seller. > > Sorry if this is tedious, but if I rephrase, it may tell you if I > understand or not. Did I? I think so, except perhaps for that last sentence. The ack is returned as a response, not as a POST request, so technically the seller still "controls" it. > Ok, then, next complication: the offer to buy should not be good > forever, it should have a time constraint. At the appointed time, > the Buyer could check the URI for the Acceptance or Rejection > document and if it's not there, the deal is off. How would you > handle that? We want it to be clear to both parties that the deal is > off, so they don't end up in court because the Seller tried to keep > going. You could do this two ways. One would be as Mike said, to include the time information in the document. There's nothing wrong with this at all. Another way would be to generalize the whole "message validity" mechanism and build an extension header with HTTP or SOAP to support it for any message. You'd need a mandatory extension mechanism to deploy it, otherwise you'd never know if the receiver knew what you were talking about. That would be an interesting extension, for sure. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I've created a new mailing list, rest-explore[1], which I would like to ask that folks use for "exploratory" discussions, such as the current discussion on opacity. rest-discuss is gaining new members, most of whom are likely REST beginners. They may easily be turned-off by these types of discussions. Thanks. [1] http://groups.yahoo.com/group/rest-explore/ MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > That's the same thing. There is no "linking to them" separate from > simply "writing down their URI". My point is that there are many ways to "write them down" that do not involve embedding them in a recognized, machine-usable hypertext. jb
Paul Prescod wrote: > Do you have any examples that are not a bit weak??? That depends on whether you can shake off the doctrine long enough to process the examples objectively. > That's fine. Use the query as an index over or redirect to the > hierarchical version. I don't want or need to provide two versions when a single one suffices. > Actually, this is just a convenience that makes mapping between > file systems and URIs easier. This is a false assertion. It's not that (hierarchy, or more correctly graph-structuring a namespace) is a convenience for mapping to filesystems, it's that it is (often) an appropriate information modeling technique. > It is not core to the web architecture at > all. No, of course not. The Web shouldn't prescribe particular information models for particular information spaces. > My point is that your arguments in each situation are not > problem-driven, they are theory-driven. If you had approached this whole > situation like: "I was working on this problem and I found it very hard > to solve with existing techniques." Sod off, Paul, really. If you yourself and your own efforts were subject to the same standards that you apparently want to subject everybody else to, nobody'd be willing to discuss WRDL or HttpEvents or whatever with you, either. > Google loses information in MSDN's URIs? That's ridiculous! The object's > canonical URI does not change because someone, somewhere has indexed it. I'm not saying the canonical URI changes, I'm saying that when you represent what is conceptually hierarchical information in query strings you're losing the conceptual hierarchy. This is a simple point. I know you can get it. jb
Paul Prescod wrote: > "S. Mike Dierken" wrote: > > > > JeffB consistently says that it is only one of many tools and can/should be > > used only in certain classes of problems, and he says that otherwise a pure > > hyperlink approach is better. > > ... > > That sounds very reasonable. But the hyperlink model is complete, in the > same way that GET/PUT/POST/DELETE is complete. This is a very sloppy statement. What do you mean by complete? What do you mean by "hyperlink model"? And how do you respond to the many, many examples that have been offered where objects nameable by URI are added to the Webspace but are not added to a hyperstructure. > In the same way that > lambda calculus primitives are complete. So Jeff needs to show that his > way is simpler. First, I'm happy to work on that if I can stop swatting away your spurious assertions long enough. Second, your sloppy claim above is the extraordinary claim. jb
This leaves a bad taste in my mouth. The "axiom" of URI opacity is --- for better or worse --- a part of the REST "doctrine." This list is --- I thought --- for discussing REST. Punting anything that questions any given part of the "official" REST dogma over somewhere else smacks of doctrinal purification, in some sense changing this list from a true, open discussion forum into an indoctrination forum. Having said that, I do agree that the back-and-forth with me and Paul mostly ceased to be useful or interesting some dozens of messages back. I'll kill that thread, and simply provide pointers to pages on the Wiki which are appropriately indicated as being "heretical." :-/ jb
> This leaves a bad taste in my mouth. The "axiom" of URI opacity is --- for > better or worse --- a part of the REST "doctrine." This list is --- I > thought --- for discussing REST. Punting anything that questions any given > part of the "official" REST dogma over somewhere else smacks of doctrinal > purification, in some sense changing this list from a true, open discussion > forum into an indoctrination forum. That isn't the intent at all. It's basically a "rest-discuss-advanced", where any advanced topic should be discussed, from very REST-friendly stuff, to pure unadulterated REST heresy. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Just curious - One of the things that Mark talks about from time to time is 'resource modeling' - as I understand it, the process of finding the most RESTful way to express an application as a resource or group of resources. To me, understanding of resource modeling is one of the things that blocks people from actually using REST and producing RESTful applications. Considering that process modeling / architecture tools are fairly well-known and valued tools these days, how much of a leap is it from them to expressing an application in REST? For example, can one reuse UML and the tools available for working with it to model an application using REST? (I'm asking from ignorance here; I know of these tools and appreciate their place in the universe, but don't use them.) Regards,
> Considering that process modeling / architecture tools are fairly > well-known and valued tools these days, how much of a leap is it from > them to expressing an application in REST? For example, can one reuse > UML and the tools available for working with it to model an application > using REST? For some stuff, probably. I stopped using these tools about the time I grokked REST, so it's hard for me to say for sure. You'd just have to start out with some common classes, such as those I define in RestRDF, from which all distributed components inherit their interfaces. Beyond that, most of these tools use methodologies which are not well suited to a data-transfer centric architecture such as REST, so any type of simulation or execution would likely be problematic. I'm sure we'll see the tools vendors catch up soon enough. > (I'm asking from ignorance here; I know of these tools and appreciate > their place in the universe, but don't use them.) I used to use them extensively. I'm glad I don't anymore. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> > Using a query you can reference the *same thing*, through one level of
> > indirection.
> >
> >
document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href))
>
> No. It's not the same. The case above is both more complex syntactically
and *less*
> meaningful. By pushing things into the query string, you've lost the
knowledge that
> $month bears a subordinate relationship to $year.
>
I know that using the '/' as a 'sub' concept is easy to do and useful, but
it probably is better to treat it as a sequence rather than containment (in
general).
The path part is a sequence of values (accessed by index or position) and
the query part is a set of properties (named values - a point in a
multi-dimensional information space) accessed by name. The sequence of
values does not always imply containment though, especially of 'deep'
sequences.
for paths
"/a/b" != "/b/a" (pretty obvious)
for query terms (and path segment properties)
"year=1999&month=june" == "month=june&year=1999" (another obvious example)
so
"/a/b/c/d" !imply "/a/*/c/d" (this is probably what you mean when you say
generative naming works best in non-sparse and regular information
structures [i'd call it a structure not a space, cause you traverse to data
rather than vector to data {or maybe that's the point, when a structure is
really a space}])
But it might be useful to be able to tell clients under what situations and
for what resources that containment does hold though.
mike
> I'm not saying the canonical URI changes, I'm saying that when you represent what is conceptually hierarchical information in > query strings you're losing the conceptual hierarchy. This is a simple point. I know you can get it. So, like you are claiming that taking a sequence of values (like an array) and converting it to named values (like a hashtable) then you lose information? Well you might be right. But what about the names that are introduced? are those an artifact of the conversion or 'more authoritative' information. And what about the inverse - taking a set of properties (named values) and turning them into a sequence of values. The names disappear, but a sequence (relationships) appear. Where did this presto magico information come from? (...and don't start on about zero-point energy...) Its interesting to think about function calls in procedural languages - some have parameters that are named but not sequenced (like Ada I think) and others have parameters that are sequenced but not named (like assembly) and others have source code with name and sequence but have compiled code with only sequence. Well, okay, its interesting to me...
Mark Baker wrote: > > Ok, then, next complication: the offer to buy should not be good > > forever, it should have a time constraint. At the appointed time, > > the Buyer could check the URI for the Acceptance or Rejection > > document and if it's not there, the deal is off. How would you > > handle that? We want it to be clear to both parties that the deal is > > off, so they don't end up in court because the Seller tried to keep > > going. > > You could do this two ways. One would be as Mike said, to include > the time information in the document. There's nothing wrong with > this at all. > > Another way would be to generalize the whole "message validity" > mechanism and build an extension header with HTTP or SOAP to support > it for any message. You'd need a mandatory extension mechanism to > deploy it, otherwise you'd never know if the receiver knew what you were > talking about. That would be an interesting extension, for sure. Regardless of how the time constraint is expressed (an element of the Order document is fine with me), the issue I was trying to raise was how to make the order explicitly defunct. Could be deleted, but that's often disallowed in business. So it should be canceled. And let's say that it is the Buyer's responsibility to do so. Just to indicate more where I am going with this line of inquiry, the next problem I want to think about is the "counteroffer pending" response, where the Seller will next make a counteroffer to the Buyer. Where I am trying to go is into the resource model for this stuff: what becomes a Web resource, where? -Bob Haugen
Jeff Bone wrote: > >... > > This is a very sloppy statement. What do you mean by complete? What do you mean > by "hyperlink model"? If an information provider wants to provide access to information objects, no matter how many or how opaque, and they have control over a web server then they can provide this access using hypertext documents. We have twelve years of experience to back that up. I can point to dozens of applications where opaque, regularly named information objects were served through the web without client-side URI munging. If an information provider chooses not to use the standard web mechanisms to reference their data objects then they are simply being irresponsible and shifting the burden onto their information consumers. As an information consumer, of course I may choose to "hack" based on things I notice about their namespaces. I might also choose to take advantage of things I know about their HTTP Server implementation or cache too. But that doesn't mean that it is *good practice* to make client-side assumptions about either namespace structure or web server implementation. > ... And how do you respond to the many, many examples that > have been offered where objects nameable by URI are added to the Webspace but are > not added to a hyperstructure. If somebody chooses not to give something a hypertext interface on the Web then I don't really see why I have any responsibility to help them. They could similarly complain that the Web forces you to give everything a URI. Yep. That's how it works. Anything can be given a URI without great expense and anything can be addressed through hypertext without great expense. REST is about simplifying component interfaces through constraints. These are two simplifying constraints. I would be similarly frustrated if someone started a big discussion about "should web addressing really be limited to URIs?" That's the last I'll say on rest-discuss on the issue. Paul Prescod
Fair enough. Mark Baker wrote: > > This leaves a bad taste in my mouth. The "axiom" of URI opacity is --- for > > better or worse --- a part of the REST "doctrine." This list is --- I > > thought --- for discussing REST. Punting anything that questions any given > > part of the "official" REST dogma over somewhere else smacks of doctrinal > > purification, in some sense changing this list from a true, open discussion > > forum into an indoctrination forum. > > That isn't the intent at all. It's basically a "rest-discuss-advanced", > where any advanced topic should be discussed, from very REST-friendly > stuff, to pure unadulterated REST heresy. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"S. Mike Dierken" wrote: > I know that using the '/' as a 'sub' concept is easy to do and useful, but > it probably is better to treat it as a sequence rather than containment (in > general). Yes! This is absolutely correct. In fact, this parallels how '/' is viewed and what paths mean in some of the more advanced filesystem namespace uses. Path elements can be more profitably viewed as named "views" on some part of an information space, and "/" becomes a mechanism for composing those views, expressing in some sense subordinate views which "narrow" a larger view. This is a general problem with modeling, too. This problem actually bit us in the ass at Clickfeed. We had "feeds" --- i.e., categories --- which contained "items" --- i.e., blogged or grazed metadata and annotations about blog items or external news articles. The problem was that, because of a strict notion of containment, it was difficult for a single item to be in more than one feed. Our 2nd-gen architecture addressed this by separating the feedspace from the itemspace, making feedspace a richer, composable namespace which indirectly and dynamically provided views on itemspace. jb
"S. Mike Dierken" wrote: > So, like you are claiming that taking a sequence of values (like an array) > and converting it to named values (like a hashtable) then you lose > information? Well you might be right. > But what about the names that are introduced? are those an artifact of the > conversion or 'more authoritative' information. Yes, there are pros and cons. A strings of things separated with "/"-type delimiters contains ordinal information and structural information. Pushing the same thing into named but non-ordinal query strings loses the ordinal and structural information but introduces descriptive information about the "type" of the elements. I'm working on a detailed example of using structured names to represent taxonomy that I'll post a link to later; hopefully, it addresses Paul's questions by providind a detailed and realistic example of why you don't want to just shove everything into the query string to accomodate some notion of what part of the URI should be "opaque." jb
Paul Prescod wrote: > If somebody chooses not to give something a hypertext interface on the > Web then I don't really see why I have any responsibility to help them. > They could similarly complain that the Web forces you to give everything > a URI. Yep. That's how it works. Let's review this again. Sure, the Web forces you to give everything a URI. HTTPspace is a subspace of URIspace. However, the Web *specifically* and *by design* does not force a hypertext interface for everything. The HTTP and URI specs have very little to say about hypertext specifically. HTMLspace / XMLspace are subspaces of HTTPspace. Anything in HTTPspace, or indeed in URIspace, can be addressed from *MLspace, but the extent of the larger spaces is not constrained by what is reified in the smaller spaces. I think it's a bad idea to assume equivalence. > Anything can be given a URI without > great expense and anything can be addressed through hypertext without > great expense. REST is about simplifying component interfaces through > constraints. These are two simplifying constraints. IMO, it's not a "simplifying" or empowering constraint to assume that, in order to use something, I have to reify a reference to it in hypertext. > That's the last I'll say on rest-discuss on the issue. Ditto. jb
> Regardless of how the time constraint is expressed (an element of the > Order document is fine with me), the issue I was trying to raise was > how to make the order explicitly defunct. Could be deleted, but > that's often disallowed in business. So it should be canceled. And > let's say that it is the Buyer's responsibility to do so. If the seller wants to give the buyer that option, I suppose it could return a 201 (Created) response with the URI of the offer in the Location header of the response. Then the buyer would just DELETE it to cancel the order. If richer cancellation semantics are required, a separate "cancel" document should be used, since I would expect that somebody would want to track that as a separate document. i.e the buyer POSTs a "cancel order" document which includes a link to the offer resource URI returned on the aforementioned 201 response. > Just to indicate more where I am going with this line of inquiry, the > next problem I want to think about is the "counteroffer pending" > response, where the Seller will next make a counteroffer to the > Buyer. Does the offer of a counteroffer infer a rejection of the original offer? I would expect so. So in that case, the response to the offer document being POSTed could be a rejection document which included a URI to a counteroffer. Or it could be included inline as part of the rejection. > Where I am trying to go is into the resource model for this stuff: > what becomes a Web resource, where? Everything with identity is a resource. That doesn't mean that a representation has to be retrieved with a GET though; it's fine for it to be sent as a request or response, with the Content-Location header included so that the recipient can do a GET later if required. In this case, the initial offer from buyer to seller would be POSTed with a Content-Location header, and the seller *could* invoke GET if they lost their copy 8-) (other cases might have a better use of GET). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I've added another heretical ;-) page [1] to the RESTWiki about the use of paths vs. query strings. It includes a semi-detailed taxonomic example and comparisons of the pros and cons of structural path-based URI, ordinal query-based URI, and keyword query-based URI. Followups on rest-explore. jb [1] http://conveyor.com/RESTwiki/moin.cgi/PathsAndQueryStrings
Mark Baker wrote: > If the seller wants to give the buyer that option, I suppose it > could return a 201 (Created) response with the URI of the offer > in the Location header of the response. Then the buyer would > just DELETE it to cancel the order. > > If richer cancellation semantics are required, a separate "cancel" > document should be used, since I would expect that somebody would > want to track that as a separate document. i.e the buyer POSTs a > "cancel order" document which includes a link to the offer resource > URI returned on the aforementioned 201 response. > > > Just to indicate more where I am going with this line of inquiry, the > > next problem I want to think about is the "counteroffer pending" > > response, where the Seller will next make a counteroffer to the > > Buyer. > > Does the offer of a counteroffer infer a rejection of the original > offer? I would expect so. Yes. You understand contract negotiation rules. > So in that case, the response to the > offer document being POSTed could be a rejection document which > included a URI to a counteroffer. Or it could be included inline > as part of the rejection. > > > Where I am trying to go is into the resource model for this stuff: > > what becomes a Web resource, where? > > Everything with identity is a resource. That doesn't mean that a > representation has to be retrieved with a GET though; it's fine for it > to be sent as a request or response, with the Content-Location header > included so that the recipient can do a GET later if required. > > In this case, the initial offer from buyer to seller would be POSTed > with a Content-Location header, and the seller *could* invoke GET if > they lost their copy 8-) (other cases might have a better use of GET). Ok, I am happy with this discussion at this stage. Thank you very much. I am now in the midst of working through this same example with a lot more detail in a couple of ebXML-related work groups. When they get done, I'll come back here and see if I can take the various clues and propose a RESTful offer-acceptance model that will also satisfy the ebXML groups. Then I will invite them to comment. In the meantime, I'm still reading most of the list traffic and may chip in from the peanut gallery now and then. -Bob Haugen
Jeff Bone wrote: > >... > > Followups on rest-explore. > > jb > > [1] http://conveyor.com/RESTwiki/moin.cgi/PathsAndQueryStrings My take: http://conveyor.com/RESTwiki/moin.cgi/UriFormsAreIrrelevantImho Paul Prescod
Has anyone done any serialized RDF as request messages? -- Here's an interesting message from the past: direct: http://lists.w3.org/Archives/Public/www-rdf-interest/1999Nov/0060.html google[0]: http://www.google.com/search?hl=en&q=serialized+rdf+request
Cool, another protocol from the W3C.
--
RDF Database Access Protocol
http://www.w3.org/2002/01/rdf-databases/protocol
--
Protocol Abstraction
We'll say that RDF Database Clients communicate with RDF Database Servers by
exchanging serialized objects. The serialization may look like SQL, LISP,
XML, N-Triples, etc. The underlying protocols may be TCP, UDP, HTTP, SMTP,
etc. In other words, something like
INSERT
INTO DATABASE <http://example.com/temperature-readings>
TRIPLE (<http://example.com/temperature-readings#reading311232>,
<http://example.com/temperature-readings#locationName>,
"Waltham");
is basically the same as
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://www.w3.org/2002/01/rdap/ont-1#" >
<InsertionRequest>
<database rdf:resource="http://example.com/temperature-readings" />
<rdf:subject
rdf:resource="http://example.com/temperature-readings#reading311232"
/>
<rdf:predicate
rdf:resource="http://example.com/temperature-readings#locationName"
/>
<rdf:object>Waltham</rdf:object>
</InsertionRequest>
</rdf:RDF>
and we wont worry about which kind of syntaxes people are using for now.
(These are just vague examples; I don't know if they are really workable
syntaxes.)
Note that we cannot nicely map this to an API, because some of the
operations have a recursive structure. For example we'd like "delete
triple(a,b,c)" and "foreach ?x where ?x=c do delete triple(a,b,?x)" to use
the same "delete" operation. We'd also like to be able to nest foreach
within foreach, etc. We can only do this with an API like "do(RequestObject)
returns ResponseObject". So our focus remains on designing Request and
Response objects.
We'll consider HTTP GET of an XML/RDF file as a kind of degenerate
query-for-everything, PUT as a replace-entire-database-contents. That works
for some things, but many other times we'll want more fine-grained access.
> Has anyone done any serialized RDF as request messages? This was one of the things I've considered doing with RestRDF. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> INSERT > INTO DATABASE <http://example.com/temperature-readings> > TRIPLE (<http://example.com/temperature-readings#reading311232>, > <http://example.com/temperature-readings#locationName>, > "Waltham"); > > is basically the same as > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns="http://www.w3.org/2002/01/rdap/ont-1#" > > <InsertionRequest> > <database rdf:resource="http://example.com/temperature-readings" /> > <rdf:subject > rdf:resource="http://example.com/temperature-readings#reading311232" > /> > <rdf:predicate > rdf:resource="http://example.com/temperature-readings#locationName" > /> > <rdf:object>Waltham</rdf:object> > </InsertionRequest> > </rdf:RDF> Tunneling alert! "InsertionRequest" is a verb dressed up as noun. POST is sufficient for meaning "insert". Also, the database should be the URI that is being POSTed to. I think I've figured out how to "resource model" SQL. I'll add it to my todo list to writeup. Nothing earth shattering, but it should hopefully put this issue to rest (so to speak 8-). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
----- Original Message ----- From: "Mark Baker" <distobj@...> > > The issue is, can somebody else infer that because they see; > > http://www.dierken.com/email/foo@... > > that there exists a URI > > http://www.dierken.com/email/asdfasdf@... > > I say no, unless somehow dierken.com asserts that /email is a container > of arbitrary email addresses. > Me too. So now on to the 'somehow' part. If dierken.com were to express that fact, what would it look like? Also, would it be 'dierken.com' asserting that, or 'www.dierken.com' or 'www.dierken.com/email' that did the asserting? What's the 'logical information authority' for asserting statements about resources?
> > The issue is, can somebody else infer that because they see; > > > > http://www.dierken.com/email/foo@... > > > > that there exists a URI > > > > http://www.dierken.com/email/asdfasdf@... > > > > I say no, unless somehow dierken.com asserts that /email is a container > > of arbitrary email addresses. > > > > Me too. So now on to the 'somehow' part. If dierken.com were to express that > fact, what would it look like? Actually, I'd like to change my mind and say that this still isn't a great idea because a query term already allows it. And the way that is currently asserted is if you see a HTML FORM that says; <form action="http://www.dierken.com/email/" method="get"> <input type="text" name="email"/> </form> > Also, would it be 'dierken.com' asserting that, or 'www.dierken.com' or > 'www.dierken.com/email' that did the asserting? What's the 'logical > information authority' for asserting statements about resources? Sorry, I mistyped. It's up to the registrant of dierken.com to decide this stuff. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > Actually, I'd like to change my mind and say that this still isn't a > great idea because a query term already allows it. And the way that is > currently asserted is if you see a HTML FORM that says; > > <form action="http://www.dierken.com/email/" method="get"> > <input type="text" name="email"/> > </form> So: in order to access the resource in question, a "client" needs to be able to understand not only URI+HTTP, but also HTML? jb
> > Actually, I'd like to change my mind and say that this still isn't a > > great idea because a query term already allows it. And the way that is > > currently asserted is if you see a HTML FORM that says; > > > > <form action="http://www.dierken.com/email/" method="get"> > > <input type="text" name="email"/> > > </form> > > So: in order to access the resource in question, a "client" needs to be able to > understand not only URI+HTTP, but also HTML? Not at all. I said "currently". Any machine processable format would suffice. I don't know that RDF has anything to say about query terms (hmm), but things like WRDL and WSDL do. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > > Actually, I'd like to change my mind and say that this still isn't a > > > great idea because a query term already allows it. And the way that is > > > currently asserted is if you see a HTML FORM that says; > > > > > > <form action="http://www.dierken.com/email/" method="get"> > > > <input type="text" name="email"/> > > > </form> > > > > So: in order to access the resource in question, a "client" needs to be able to > > understand not only URI+HTTP, but also HTML? > > Not at all. I said "currently". Any machine processable format would > suffice. I don't know that RDF has anything to say about query terms > (hmm), but things like WRDL and WSDL do. So let me restate my question: in order to access the resource in question, a "client" needs to be able to understand not only URI+HTTP, but also some form of hypermedia? jb
> So let me restate my question: in order to access the resource in question, a > "client" needs to be able to understand not only URI+HTTP, but also some form of > hypermedia? Of course. The client needs additional info, even in your solution. Otherwise they're just assuming stuff which doesn't help with the "uniform" part of "URI". MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
(NB: I'm posting this to rest-discuss as well as rest-explore because it's a reasonably fundamental question that may be useful in helping even newcomers to REST understand the doctrine.) So, simple question: *what breaks* if you allow clients and servers to agree on mechanisms for clients to generate / construct URI in the server's address space by name? As an example, The Wayback Machine at archive.org provides explicit details [1] on how users (and software) can construct strings to reference resources in the archive. Why this this a bad, subversive, dangerous thing? jb [1] http://web.archive.org/collections/web/advanced.html
Mark Baker wrote: > > So let me restate my question: in order to access the resource in question, a > > "client" needs to be able to understand not only URI+HTTP, but also some form of > > hypermedia? > > Of course. The client needs additional info, even in your solution. Not necessarily. If my goal is to, for instance, simply provide a naked, hierarchical, filesystem like space in which containers can be created and deleted and opaque blobs created, updated, and deleted --- all by name --- then I don't really need any more information at all other than the hierarhical organization. URI+HTTP suffice. jb
Jeff Bone wrote: > >... > > So, simple question: *what breaks* if you allow clients and > servers to agree on mechanisms for clients to generate / > construct URI in the server's address space by name? As an > example, The Wayback Machine at archive.org provides explicit > details [1] on how users (and software) can construct strings to > reference resources in the archive. > > Why this this a bad, subversive, dangerous thing? Nothing breaks. Things start to break if the *only way* to find out how to get information out of a web-based service is through generated URIs. The first thing that would break if this convention became common on the Web is the Wayback Machine itself (and Google!). After all, it collects information by spidering the web and spiders work through links, not generated URI names. I don't mind the half of your philosophy that says: "consistent, guessable names are usually a good idea." The part that I disagree with is: "Hey, if I use consistent, guessable names, I can get away without hypertext indexes of my data." If you have a collection of data on the web that you want people to treat as a true collection then you should provide an index to it. Paul Prescod
(NB: I'm crossposting this one as well because I think a detailed response to this might be useful both the the neophyte and the enlightened. Warning: this document does touch on some REST heresy. ;-) There are basically three ways to think about URI: they are pointers, or they are queries, or they are commands in an arbitrarily expressive (possibly computationally-complete) language. The official REST position is that they are pointers *only,* and provide a limited form of pointer arithmetic (relative URI) in a rigidly constrained context (embedded in hypermedia.) (Well, okay, even a REST purist agrees that pointers are not sufficient, and we must supplement opaque pointers with arbitrary query strings to make them useful. Thus the slippery slope begins...) The "heretical" position that I've been exploring is the treatment of URI as queries rather than pointers. By opening up the URI to interpretation and construction on both ends of a communication instead of just at the server, we turn the URI namespace into a robust query engine and open up the model space. Yet another way, even more questionable way to view URI is as commands. One very interesting piece of work that does this is AT&T Research's iProxy. iProxy is an application server deployed as a personal client-side proxy; it sits in the HTTP stream doing normal proxy-like stuff (e.g. caching) but supports arbitrary local applications (e.g. archiving) as well as stream applications on proxied HTTP traffic (e.g. filtering). It does this by allowing actual request URI to be supplemented by, essentially, appending "command strings" on the end of the URI. These commands are parsed out and interpreted by iProxy. The particular way they are doing it seems rather icky to me, but it's an interesting thought --- and I waffle between thinking that this is a decidedly non-RESTful thing (in particular, iProxy's own resource model isn't obvious or usefully exposed) and thinking it's very RESTful. Anyone (Mark, Paul, Mike?) care to take a look at iProxy and render an opinion? Cf. [1-5] jb [1] http://www.research.att.com/sw/tools/iproxy/ [2] http://www.research.att.com/~iproxy/webnet99 [3] http://www.research.att.com/~iproxy/archive [4] http://www.research.att.com/~iproxy/papers/imobile.pdf [5] http://www.research.att.com/~iproxy/iproxy-api.doc
Paul Prescod wrote: > I don't mind the half of your philosophy that says: "consistent, > guessable names are usually a good idea." The part that I disagree with > is: "Hey, if I use consistent, guessable names, I can get away without > hypertext indexes of my data." I have never, ever, ever said this in the course of our discussion. This is ghost of your own creation haunting your perception of this debate. I have been very explicit that, in the general case, hypertext indexes (lists, navigational structures, etc. --- the namespace is the query space regardless) are desirable wherever they are possible. > If you have a collection of data on the > web that you want people to treat as a true collection then you should > provide an index to it. So: drill down on what you mean, specifically, by index. jb
> Not necessarily. If my goal is to, for instance, simply provide a naked, > hierarchical, filesystem like space in which containers can be created and deleted and > opaque blobs created, updated, and deleted --- all by name --- then I don't really > need any more information at all other than the hierarhical organization. URI+HTTP > suffice. I wonder how this is different from a company which permits personal homepages (just as an example). At some point in the hierarchy, the company basically relinquishes any control over the namespace and the authority becomes the employee. But the "containment" relationship persists between authorities, whether that relationship represents "employment" (in this case) or "customer of" (in the case of, say, Yahoo/Geocities). Definitely a "Web of Trust" topic. But in your example, is it your intent that the person PUTting into this empty namespace be the authority for it? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
I'm taking this back to rest-explore...if the rest-discuss people wanted to be in on it they would have joined rest-explore. Jeff Bone wrote: > > Paul Prescod wrote: > > > I don't mind the half of your philosophy that says: "consistent, > > guessable names are usually a good idea." The part that I disagree with > > is: "Hey, if I use consistent, guessable names, I can get away without > > hypertext indexes of my data." > > I have never, ever, ever said this in the course of our discussion. This is > ghost of your own creation haunting your perception of this debate. I have > been very explicit that, in the general case, hypertext indexes (lists, > navigational structures, etc. --- the namespace is the query space > regardless) are desirable wherever they are possible. > > > If you have a collection of data on the > > web that you want people to treat as a true collection then you should > > provide an index to it. > > So: drill down on what you mean, specifically, by index. > > jb > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
NB: REST heresy? Or REST clarification? I've added a page to the Wiki exploring the implications of applying the axiom of opacity too strongly. It results again in a paradoxical result: if interpreted too stringently, it (or rather the (ab)use of its loophole, the query string) results in the inability to treat URI as opaque in contexts where that's necessary. I conclude that the axiom of opacity should be discarded and replaced by two better axioms, the "axiom of lexical equivalence" and the "axiom of canonical names." http://conveyor.com/RESTwiki/moin.cgi/QueryStringsConsideredHarmful jb
I agree with Paul, mostly, but from my investigation into URI opacity, I basically concluded that; http://foo.com/bar?a=b implies the existance of a resource identified by; http://foo.com/bar There's no such inferred relationship between http://foo.com/bar/b and http://foo.com/bar/ (or http://foo.com/bar - another reason why "/" has to be opaque) It's not clear to me what this means right now, but it is extra information that can be extracted from a URI that is unavailable in "/" based URI. Who knows what neat stuff we might be forgoing in the future by not using it? Also, a practical issue is that any web server I've used typically makes it a lot easier to bind a chunk of code to query based URI than hierarchical based URI. By that I mean that foo.com/bar?a=b, by default, gets processed by the processor bound to foo.com/bar, but you often have to jump through hoops (URI rewriting, etc..) to get foo.com/bar/baz/ processed by the processor bound to foo.com/bar/. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > I agree with Paul, mostly, but from my investigation into URI opacity, > I basically concluded that; > > http://foo.com/bar?a=b > > implies the existance of a resource identified by; > > http://foo.com/bar > > There's no such inferred relationship between > > http://foo.com/bar/b > > and > > http://foo.com/bar/ (or http://foo.com/bar - another reason why "/" > has to be opaque) This is all true. However, if in a hyptertext representation of http://foo.com/bar/b I encounter <a href=".."> I can infer --- indeed, the hypertext processor is being explicitly told --- that http://foo.com/bar/ is a resource. So my question is this: what is special about hypertext and hypertext processors that they should be allowed to do this? I'm not suggesting that this kind of inference is valid in the absence of explicit information, but I am wondering why the contract between client and server must be markup. There are cases where this is desirable, but there are cases where it is not. > It's not clear to me what this means right now, but it is extra > information that can be extracted from a URI that is unavailable in > "/" based URI. Who knows what neat stuff we might be forgoing in the > future by not using it? If I'm parsing this correctly, then this is precisely the point I'm making. The axiom of opacity is vague and --- clearly, given the discussion we've had about it --- open to interpretation, even among smart folks who would work hard to do things "the right way." The problem is we may be throwing the baby out with the bathwater. My conclusion from looking at how the axiom is used and abused and the implications of such abuse is that the real *technical* motivation for opacity is to allow (a) lexical equivalence testing by spiders, proxies, mapping systems, and so forth, and (b) canonical URI for resources. This is all well and good and desirable, but a too-strict interpretation of the axiom ironically encourages URI that do not achieve these goals. It would be better to state these goals explicitly as axioms rather than state an overgeneralization with paradoxical implications as an axiom. > Also, a practical issue is that any web server I've used typically > makes it a lot easier to bind a chunk of code to query based URI than > hierarchical based URI. Without a doubt. It's unfortunate that the very software that builds the most powerful namespace in the world so completely fails to give us tools for using that namespace in powerful, flexible ways. jb
> > Also, a practical issue is that any web server I've used typically > makes it a lot easier to bind a chunk of code to query based URI than > hierarchical based URI. By that I mean that foo.com/bar?a=b, by > default, gets processed by the processor bound to foo.com/bar, but you > often have to jump through hoops (URI rewriting, etc..) to get > foo.com/bar/baz/ processed by the processor bound to foo.com/bar/. In addition JSP and ASP prevent path based processing - you can't do foo.com/bar.asp/baz/ or foo.com/bar.jsp/baz/ - which just plain sucks rocks. (I built a system that /depended/ on path based access to sub-information. Its all broken now. Thanks JCP.)
On Monday, March 11, 2002, at 06:01 PM, Jeff Bone wrote: > > This is all true. However, if in a hyptertext representation of > http://foo.com/bar/b I encounter <a href=".."> I can infer --- indeed, > the > hypertext processor is being explicitly told --- that > http://foo.com/bar/ is > a resource. So my question is this: what is special about hypertext > and > hypertext processors that they should be allowed to do this? Absolutely nothing. This behaviour is specified by RFC1808, not the HTML spec. If you want to use a relative URI in Flash, in RDF, in SVG, in MIME messages, in XML - it acts the same way. It just happens that HTML is the most widely deployed. >> Also, a practical issue is that any web server I've used typically >> makes it a lot easier to bind a chunk of code to query based URI than >> hierarchical based URI. > > Without a doubt. It's unfortunate that the very software that builds > the > most powerful namespace in the world so completely fails to give us > tools for > using that namespace in powerful, flexible ways. I so agree. This is one of the things that URISpace [1] groped around; having one flexible, URI-savvy format for configuring your server (including authentication, authorisation, processing, http headers, etc.), your surrogate (aka reverse proxy), as well as things like robots control and privacy policies would be very powerful. 1. http://www.w3.org/TR/urispace.html -- Mark Nottingham http://www.mnot.net/
Mark Nottingham wrote: > Absolutely nothing. This behaviour is specified by RFC1808, not the HTML > spec. If you want to use a relative URI in Flash, in RDF, in SVG, in > MIME messages, in XML - it acts the same way. It just happens that HTML > is the most widely deployed. Exactly! :-) > I so agree. Fabulous! :-) jb
> From: S. Mike Dierken [mailto:mdierken@...] <snip/> > In addition JSP and ASP prevent path based processing - you can't do > foo.com/bar.asp/baz/ or foo.com/bar.jsp/baz/ - which just > plain sucks rocks. > (I built a system that /depended/ on path based access to > sub-information. > Its all broken now. Thanks JCP.) Actually, more recent versions of the servlet specs provide a standard mechanism for mapping paths to servlets. Using this, you can implement your own dispatcher in the form of a servlet. It just needs some URL base mapped to it. You could (I believe) have the dispatcher invoke JSPs. This is certainly more work, though, and current tools are certainly not geared toward the sort of approach to web development advocated by REST. And for ASP, AFAIK you'd have to implement an ISAPI filter to do this, which is not trivial and is beyond the skill set of the typical web developer.
----- Original Message -----
From: "Michael Brennan" <michael_brennan@...>
>
> Actually, more recent versions of the servlet specs provide a standard
> mechanism for mapping paths to servlets. Using this, you can implement
your
> own dispatcher in the form of a servlet. It just needs some URL base
mapped
> to it. You could (I believe) have the dispatcher invoke JSPs.
The standard mechanism for mapping paths to servlets is conceptually broken.
From the servlet 2.3 spec (in web friendly PDF) on the JCP site:
http://jcp.org/aboutJava/communityprocess/first/jsr053/servlet23_PFD.pdf
"If the last node of the url-path contains an extension (.jsp for example),
the servlet container will try to match a servlet that handles requests for
the extension. An extension is defined as the part of the path after the
last '.' character."
The section is ambigous about handling urls of the form
"/a/b/foo.xap/x/y/z" - it implies that "/a/b/foo.xap" must be registered
with the servlet container (often via a manually edited text file). I was
going for any number of *.xap files on disk.
I've never met an ASP/JSP programmer that cared in the least what this meant
for their larger design. They didn't notice that relative URLs aren't
possible and the server has to compute static text constantly.
The dispatcher that I wrote a few years ago was a servlet. It handled files
with an extension of .xap (xml application page) anywhere in a URI path. The
'extra path info' that many web server environments provides became
unavailable after a certain version of the servlet specification (it was
working earlier). You can find the code at http://xml.apache.org/xang/ (the
dispatching framework in that project geared writing servlets in a 'resource
modeling' fashion, it also did some rpc-ish stuff but after actually
building stuff with it, I moved away from custom verbs into a minimal common
set - hence my interest in rest)
> And for ASP, AFAIK you'd have to implement an ISAPI filter to do this,
which is
> not trivial and is beyond the skill set of the typical web developer.
Nah, implementing ASP is easy, its a file format after all.
- parse text into script sections
- load up JavaScript engine (Rhino is really good, FESI is okay too)
- provide java objects that implement MS's Request and Response interfaces
- provide some global functions/classes like ActiveXObject("classId")
- ignore the existing body of COM objects and just use Java class
identifiers instead.
But it doesn't matter because ASP/JSP is just wrong anyways (mixing
user-agent specific ui with data access as code).
REST purports to be an architectural style that embodies the principled design of the Web. That sort of statement generates lots of questions, the first being "what is the Web?" If REST is an architectural style that rests on certain principles, what are those principles, what motivates them, how do they relate, what tradeoffs have been made or considered? Asking such questions may yield many useful insights and answers; unf., merely studying The RFCs and The Thesis and The Paper and The Apocrypha often don't yield good answers. All the following describe different sets with different relationships to each other. By studying the relationships between these and other similar sets, it may be possible to produce a stratified scheme for assessing and categorizing the various principles that guide Web architecture and consequently achieve a reasonable separation of concerns with respect to architectural concepts and components. Is the Web: (U) ...all things that have URI? (B) ...all things that a browser can get, given a URI? (H) ...all things that a browser can get, given an HTTP URI? (G) ...the transitive closure of all URI-addressible hypergraphs (i.e., linked to or from)? (J) ...the transitive closure of all HTTP URI-addressible hypergraphs? (L) ...all things that are linked from some piece of hypermedia? (M) ...all things in markup-with-links, regardless of having dereferenceable URI? Opinions and drill-down appreciated. jb
> (U) ...all things that have URI?
I'd say this one, but I'd add;
... and whose access and manipulation can be achieved via a
REST interface (including through an intermediary)
It's a tautology really, as all things with URIs *can* be accessed and
manipulated in this way. But it highlights the role of REST.
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > (U) ...all things that have URI? > > I'd say this one, but I'd add; > > ... and whose access and manipulation can be achieved via a > REST interface (including through an intermediary) > > It's a tautology really, as all things with URIs *can* be accessed and > manipulated in this way. But it highlights the role of REST. I like this. But... What is a "REST interface?" Does that mean: * any form of representational state transfer, i.e., ftp:// is encompassed? * an HTTP interface? * an HTTP + any hypermedia interface(s) for representations? * an HTTP + some specific hypermedia interface(s) for representations? jb
> What is a "REST interface?" Does that mean: > > * any form of representational state transfer, i.e., ftp:// is encompassed? > * an HTTP interface? > * an HTTP + any hypermedia interface(s) for representations? > * an HTTP + some specific hypermedia interface(s) for representations? It means any interface for which the semantics are generic to all things with identity. So ftp: is encompassed, because I can map GET and PUT to FTP RETR and STOR. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Good answer! :-) jb Mark Baker wrote: > > What is a "REST interface?" Does that mean: > > > > * any form of representational state transfer, i.e., ftp:// is encompassed? > > * an HTTP interface? > > * an HTTP + any hypermedia interface(s) for representations? > > * an HTTP + some specific hypermedia interface(s) for representations? > > It means any interface for which the semantics are generic to all > things with identity. > > So ftp: is encompassed, because I can map GET and PUT to FTP RETR and > STOR. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Jeff Mogul has a paper that's been accepted to WWW2002 which may be of interest; it calls out problems in the HTTP's terminology and specification (mostly regarding clarity) that give a nice counterpoint to REST. http://www.research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint. pdf This may also be useful in the context of the current discussions on the TAG. -- Mark Nottingham http://www.mnot.net/
Assuming this group is still alive (I know everybody's been busy evangelizing in W3C lists), I have a followup question on the purchase order scenarios. There is a standard function in an ERP system called Available to Promise, or ATP for short. "Available" means "not already promised to somebody". It is used to decide if a purchase order can be fulfilled or not. It is usually used for purchase orders for products, so that is what I will describe here. There are a variety of APIs and algorithms, but they boil down to two main queries, which I will describe in plain English, not code: 1. How much of a product is available to promise at a future time? For example, how many blue shoes can I get by tomorrow? The answer is a quantity. 2. Is a specified quantity of a product at a specified time? For example, can I get 100 blue shoes tomorrow? The answer is a boolean. This query might be offered to a customer to use before they place an order, or it might be used by the order-taking Web resource before accepting an order. In REST terms, I assume this is a GET with parameters, and the Web resource to address is the Product (i.e. BlueShoe). How would you say it? Thanks, Bob Haugen
Interesting. The URI (path+query) would point to the answer you want to give, having the 'path only' point to the product is neato, but not required. To get the availability: http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow To get the threshold (more than 100) http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow&ab ove=100 But of course there are a million ways to slice it. You can narrow down the choices based on whether PUT/DELETE/POST are needed on the same resource - and they probably aren't. POST might be used to allocate out of the availability - but a business document probably will have that information & so you'd just submit it to the 'orders' collection & let the values be updated via business logic (meaning that the values from these two sample queries are 'synthetic' properties, derived from data manipulated via other actions) ----- Original Message ----- From: "bhaugen32" <bhaugen32@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, April 04, 2002 10:42 AM Subject: [rest-discuss] Restifying Available to Promise > Assuming this group is still alive (I know everybody's been busy > evangelizing in W3C lists), I have a followup question on the > purchase order scenarios. > > There is a standard function in an ERP system called Available to > Promise, or ATP for short. > > "Available" means "not already promised to somebody". > > It is used to decide if a purchase order can be fulfilled or not. > It is usually used for purchase orders for products, so that is what > I will describe here. > > There are a variety of APIs and algorithms, but they boil down to two > main queries, which I will describe in plain English, not code: > > 1. How much of a product is available to promise at a future time? > For example, how many blue shoes can I get by tomorrow? > The answer is a quantity. > > 2. Is a specified quantity of a product at a specified time? > For example, can I get 100 blue shoes tomorrow? > The answer is a boolean. > > This query might be offered to a customer to use before they place an > order, or it might be used by the order-taking Web resource before > accepting an order. > > In REST terms, I assume this is a GET with parameters, and the Web > resource to address is the Product (i.e. BlueShoe). > > How would you say it? > > Thanks, > Bob Haugen > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
"S. Mike Dierken" wrote: > > Interesting. > > The URI (path+query) would point to the answer you want to give, having the > 'path only' point to the product is neato, but not required. > > To get the availability: > http://www.myinventory.foo/products/blueshoes/availability/? when=tomorrow > > To get the threshold (more than 100) > http://www.myinventory.foo/products/blueshoes/availability/? when=tomorrow&ab > ove=100 I like it! Maybe just plain http://www.myinventory.foo/products/blueshoes/availability would present something like an MRP inquiry, starting with the blue shoes on hand, followed by a list of scheduled receipts. (That's the way an ATP report often looks.) > But of course there are a million ways to slice it. > You can narrow down the choices based on whether PUT/DELETE/POST are needed > on the same resource - and they probably aren't. POST might be used to > allocate out of the availability - but a business document probably will > have that information & so you'd just submit it to the 'orders' collection & > let the values be updated via business logic (meaning that the values from > these two sample queries are 'synthetic' properties, derived from data > manipulated via other actions) I agree. Allocation requires a business commitment from a customer, usually in the form of an order. Thanks, Mike. -Bob Haugen
I had a good friend ask me about whether Model-View-Controller is a good framework for building apps on a Java App Server. This led me to thinking about how different people view the job of building 'web applications'. I've always thought of MVC as useful way of building single-user/single-machine apps - classical programming. But I also see the separation of data, presentation and logic being very important and used in multi-tier large-scale systems - the two are very related. The interesting part is that I think different audiences view 'the web' as one of these three facets of a large system; - REST advocates view the Web as an information system - the 'model' part - majority of web app developers and web app tools (asp/jsp/etc.) view it as user interface - the 'view' part - many soap developers view it as functional services - the 'controller' part (sort of, i'm probably stretching the analogy here) I think it is wonderful that the Web is rich enough to be viewed in these different ways, but I see it as a wholistic blending of all these. Knowing where other people are coming from can help in understanding each other and in communicating with and educating each other. In my view, the current crop of Web application development tools is overly focused on user interface aspects. When I see development tools and servers project 'MVC' as a good way to build applications, it seems like they are looking from the server inward and applying MVC, where I see the value in looking at the server outward and applying MVC concepts. Design a system to separate data, presentation and logic /outside/ the web server. This lets you build applications that span a single server - whether clustered or not. Another thought I had was to daydream about what a real REST oriented Web server development environment would look like. I'm imagining a blend of a RDBMS interface with HTTP/REST concepts - rather than saying "create table users (userid int, email varchar(255))" we could say "create collection users (userid uri)" or something. And we could easily build user interface without putting the UI template in the URI. "when user-agent like mozilla%" or "when accept like text/%" or something. Mike
"S. Mike Dierken" wrote: > I had a good friend ask me about whether Model-View-Controller is a good > framework for building apps on a Java App Server. > - REST advocates view the Web as an information system - the 'model' part > - majority of web app developers and web app tools (asp/jsp/etc.) view it > as user interface - the 'view' part > - many soap developers view it as functional services - the 'controller' > part (sort of, i'm probably stretching the analogy here) Alternatively, in REST: 'model' = resource 'view' = representation 'controller' = handler of GET, POST, PUT, DELETE, etc. (I'm less sure of the controller.) -Bob Haugen
bhaugen32 wrote: > Alternatively, in REST: > 'model' = resource > 'view' = representation > 'controller' = handler of GET, POST, PUT, DELETE, etc. Right on the money, IMHO. jb
I suppose everybody is tired of Yahoo groups by now, but the REST gang doesn't seem to want discussion on the Wiki, so I don't know where else to post this question-for-discussion. How much of the current kludges for session state management could be avoided by making session state(s) into Web resources? Paul Prescod has hinted at this a couple of times. Here's an example of people struggling with the issues without considering REST: http://c2.com/cgi/wiki?DoesAnyoneActuallyUseStatefulSessionBean Thanks, Bob Haugen
> How much of the current kludges for session > state management could be avoided by making > session state(s) into Web resources? > Thanks, > Bob Haugen I think there's a project to be done of working out a RESTy session management protocol. ...just have to sit down and do it, that's all. - Lucas
bhaugen32 wrote: > >... > > How much of the current kludges for session > state management could be avoided by making > session state(s) into Web resources? I tend not to think about session state as a thing. A client interacts with a service and in so doing the service may create new resources. They may be short or long-lived. Is there, in general, a requirement to reify this as a "session"? Opinions requested. One reason that I resist this is because I would like for it to be possible to construct a single logical client from many different "HTTP clients". i.e. for me to dispatch part of the job to a totally different software component merely by sending it a URI. "Tax form verification code service, please check my tax form before I send it. It is at http:///". This gets much more complicated if the client and server have a shared, implicit notion of where we are in the multi-step process. One way it would help deal with the issues discussed on that c2.com wiki is by spreading out the state among multiple resources so that you might not need to load balance any particular resource. As the "state" is spread among different URIs, each new step in the process can switch machines if necessary. Still, the steps will often need to share information so you still need to push this back to the database and that will still be somewhat expensive. Paul Prescod
Paul Prescod wrote: > bhaugen32 wrote: > > > >... > > > > How much of the current kludges for session > > state management could be avoided by making > > session state(s) into Web resources? > > I tend not to think about session state as a thing. A client interacts > with a service and in so doing the service may create new resources. > They may be short or long-lived. Is there, in general, a requirement to > reify this as a "session"? Opinions requested. No. I wish I had not framed the question that way. In fact, the reason I asked it was because you hinted in some previous messages that the resources created by interactions would eliminate the need to reify and keep track of "sessions". To the extent that the idea holds up, it could also eliminate all kinds of crufty buggy baggage. > One reason that I resist this is because I would like for it to be > possible to construct a single logical client from many different "HTTP > clients". i.e. for me to dispatch part of the job to a totally different > software component merely by sending it a URI. "Tax form verification > code service, please check my tax form before I send it. It is at > http:///". This gets much more complicated if the client and server have > a shared, implicit notion of where we are in the multi-step process. Unfortunately, business exchanges require trading partners to agree on states, but they could be states of resources, not processes. (Or to put it another way, the states of a business process can be modeled as states of resources.) For example, trading partners need to know if an order has been accepted, rejected, fulfilled, etc. but those are states of the order, and both the order and its state(s) could be Web resources. -Bob Haugen P.S. Paul, I could search for the hints in previous messages if you want me to, but maybe you remember them? I didn't bookmark any of them, unfortunately - a lightbulb went on when I was reading the Wiki page and thinking you had the seed of a better way.
Hi, I would like to see a document where you can learn REST by example. For one reason, to understand it better and also because there is growing interest in the Ruby community to consider using a REST architecture as an alternative to a SOAP based approach. This document would start with very simple examples and gradually evolve into more complex situations (along with explanations why thing should be done that way). What would be good examples to start with? I was thinking about things like 'hello world', a calculator, an addressbook, a simple chat program. Is the REST wiki a good place to start such a document, or should I put it on the Ruby wiki? (the document could have different versions for other programming languages as well). Any suggestions would be most welcome. Erik Terpstra.
Lucas Gonze wrote: > I think there's a project to be done of working out a RESTy session > management protocol. ...just have to sit down and do it, that's all. What would be the simplest or most generally congenial environment where a group could collaborate in some REST experiments?
> What would be good examples to start with? I was thinking about things > like 'hello world', a calculator, an addressbook, a simple chat program. The calculator might be a bad sample problem, because it doesn't show the utility of REST - transferring the state of a calculator is unnecessary because the state can be completely algorithmically regenerated on the client. A 'shared calculator' might be interesting though. The addressbook is a really good example - there is a wide range of approaches, from simple ones to get the general feel and style of REST, and some more complex ones that get into the tougher areas of collections, nesting, multi-protocol linking, security, etc. The chat might be better cast as discussion groups, since 'hot live chat' isn't that common with pure HTTP (unless you use KnowNow technology.) Another thing to think about is to avoid the 'browser == web' mentality that throws people off the http trail. Toss XML around (without worring about using 'industry standard schemas') and do some linking between things (possibly between apps...). > Is the REST wiki a good place to start such a document, or should I > put it on the Ruby wiki? (the document could have different versions > for other programming languages as well). > Any suggestions would be most welcome. > > Erik Terpstra. > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Hi, I would like to see a document where you can learn REST by example. For one reason, to understand it better and also because there is growing interest in the Ruby community to consider using a REST architecture as an alternative to a SOAP based approach. This document would start with very simple examples and gradually evolve into more complex situations (along with explanations why thing should be done that way). What would be good examples to start with? I was thinking about things like 'hello world', a calculator, an addressbook, a simple chat program. Is the REST wiki a good place to start such a document, or should I put it on the Ruby wiki? (the document could have different versions for other programming languages as well). Any suggestions would be most welcome. Erik Terpstra.
Don't know, and I think this list is for more general things, but I'd be happy to participate wherever the work ends up happening. A year ago I would have said Yahoogroups. ...suppose the thing to do is set up a mail list anywhere convenient. - Lucas On Tue, 16 Apr 2002, bhaugen32 wrote: > Lucas Gonze wrote: > > I think there's a project to be done of working out a RESTy session > > management protocol. ...just have to sit down and do it, that's > all. > > What would be the simplest or most generally congenial environment > where a group could collaborate in some REST experiments?
Hi Erik,
There is already a page on the Wiki ("How to convert RPC to REST") for
what you are thinking about. The fact that you didn't find it means that
there's a UI problem. I have edited the text of the front page to
indicate that the "how to convert..." page includes examples.
Changed title
== Comparing REST to Other Things ==
to
== Comparing REST to Other Things: REST by Example ==
More examples on the HowToConvertRpcToRest page would be a good thing.
- Lucas
Lucas Gonze wrote: > Don't know, and I think this list is for more general things, but I'd be > happy to participate wherever the work ends up happening. A year ago I > would have said Yahoogroups. ...suppose the thing to do is set up a mail > list anywhere convenient. A Wiki works for me for conversation and documentation. If the REST Wiki admins don't want it, maybe set up another somewhere. But I was also thinking about development environment, language, server, etc. so components might work together more easily. I know REST doesn't care, but some of the head-scratching about REST that I go through includes what happens behind the representation. I don't care if it's something I don't know now (e.g. Ruby). Should just be lightweight and simple and cheap (I think).
Erik wrote: > However, I am not particularly interested in converting any existing > technology into REST based ones. > > I am interested in simple (small) examples that demonstrate the REST > approach with a 'readable' language like Ruby or Python, using only HTTP > and URIS (and in more complex examples XML). During the morning commute I came to more or less the same conclusion. In general there needs to be a listing of design issues with an example for each. The stuff on the REST Wiki right now is too abstract. Design issue: resources not methods Example: SQL insert One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax. For example, GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable A REST way of doing this would * be strict about not using GET to change server state * have the back end target be a resource rather than a procedure New way: POST /tables/myTable?id=25&val=fooVal - Lucas
Lucas Gonze wrote:
> There is already a page on the Wiki ("How to convert RPC to REST") for
> what you are thinking about. The fact that you didn't find it means that
Thanks, but the top of that page states:
---
Here we aim to demonstrate by example how to convert existing XML-RPC or
SOAP/RPC based services into REST based ones that used only HTTP and
URIs (and optionally XML).
---
However, I am not particularly interested in converting any existing
technology into REST based ones.
I am interested in simple (small) examples that demonstrate the REST
approach with a 'readable' language like Ruby or Python, using only HTTP
and URIS (and in more complex examples XML).
Erik.
http://api.google.com/search/beta2 Grrrr!
They used to have an XML interface via POST/GET. But you had to pay to get in. Don't know what happened to it. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: <rest-discuss@yahoogroups.com> Sent: Wednesday, April 17, 2002 7:58 AM Subject: [rest-discuss] Things that make you go "Grrrr!" > http://api.google.com/search/beta2 > > Grrrr! > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
----- Original Message ----- From: "Erik Terpstra" <erik@...> > > However, I am not particularly interested in converting any existing > technology into REST based ones. > > I am interested in simple (small) examples that demonstrate the REST > approach with a 'readable' language like Ruby or Python, using only HTTP > and URIS (and in more complex examples XML). > What kind of code examples do you want - client or server? How about Java code? Regarding server based code, I have some Java code from a few years ago that tried to be HTTP and resource oriented. It's a still available at http://xml.apache.org/xang/ - there are two pieces, a Servlet based framework for dispatching requests into 'resource managers'. There is also a part that let you build the url structure and method handlers in xml and script, but that might not be what you are looking for (but xml and script do make for easy visual communication). I also have some examples of a servlet using that approach to expose LDAP and NNTP through simple URIs and as XML. http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/ There is also a project to do a 'canonical HTTP API for JMS' on sourceforge (java & servlet based): http://sourceforge.net/projects/destiny/ Something I haven't done but would like to is to write an HTTP client library in Java that is an application API rather than a protocol API - rather than talking about headers and stuff, talk about resources, representations, etc.
Mark Baker wrote: > > http://api.google.com/search/beta2 > > Grrrr! I am half-way though an xml.com article on this topic. The argument in favor of HTTP is so overwhelming that i would hope and expect that beta3 will have both interfaces. In fact, the SOAP interface feels like a light layer of SOAP over a native HTTP interface already! Paul Prescod
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Lucas, On Thu, 18 Apr 2002 02:19, Lucas Gonze wrote: >�Erik wrote: >�> However, I am not particularly interested in converting any existing >�> technology into REST based ones. >�> >�> I am interested in simple (small) examples that demonstrate the REST >�> approach with a 'readable' language like Ruby or Python, using only HTTP >�> and URIS (and in more complex examples XML). Erik: along side the address book example, what about a bookmark manager? It could manage bookmarks in one central place. >�During the morning commute I came to more or less the same conclusion. >�In general there needs to be a listing of design issues with an example >�for each. �The stuff on the REST Wiki right now is too abstract. As a very new comer to REST I am still having a hard time thinking about how it works with a real application from an implementation point of view. >�Design issue: resources not methods >�Example: SQL insert > >�One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax. >�For example, >�GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable > >�A REST way of doing this would >�* be strict about not using GET to change server state >�* have the back end target be a resource rather than a procedure > >�New way: >�POST /tables/myTable?id=25&val=fooVal > >�- Lucas Surely this would be very bad as anyone could insert whatever data they wanted into your database. Database access/manipulation IMHO is something that should definately live behind a facade. I would generally prefer to not even expose dataaccess routines to the outside world but wrap those up in something that communicates what the data is doing. Without doing a REST example, because I don't understand it yet. I would do something like employee.create, or update etc...This is commonly termed as the CRUD approach. In REST would this be something like the following? http://somehost.com/employee/create?id=12345 http://somehost.com/employee/update?id=12345 Then on the server side there would be a create, update method on the employee that takes an id parameter? - -- Signed, Holden Glova -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8vnjn+mF116Lw2cQRAoddAJ9HIDZXui5D0I6yumnsY5kUVVE9QQCZAXdM j3S51ro8ojOn+3kG4PMZqBE= =uvr+ -----END PGP SIGNATURE-----
Please do not forward this too widely yet. I intend to publish it on
xml.com. In particular, please don't forward links to it yet. It's
canonical home should be xml.com. Still needs proof reading and comments
are welcome, as always.
=====
Google's Gaffe
Google's release of an Application Programming Interface has
been heralded as a bright moment for web services. It is true
that it is an exciting development, but at the same time there
is a subset of the programmer community that is disappointed.
Google had a similar XML-based API a year ago, but did not
document it or hype it. Merely by adding the URL fragment
"/xml" to your query, you could get back an XML representation
of a query, for processing by any XML-aware programming
language or tool. It became a pay-only service last fall. We
were disappointed but understood why that would happen -
lacking in advertisements, the service was a straight money
loser.
Imagine our surprise when we heard the big announcement
recently. Google had revived the service, added new features,
documented it and promoted it, but had moved it to a an
inferior technical platform: SOAP. Over dozens of mailing
lists, weblogs and discussion groups the reaction was mixed:
"An official Google API! But why use SOAP?" It feels like one
step forward and two backwards.
This article will demonstrate that the choice to use SOAP was
a poor one. The much simpler HTTP URI technique was easier to
use and more powerful at the same time. I will recast the new
Google API back into a URI and HTTP-based API and demonstrate
the virtues of the simpler HTTP strategy.
Why Google Is Special
In the past, I have demonstrated how SOAP-based services can
be re-engineered around pure HTTP. These services can be
arbitrarily complex, transactional, read-write and secure.
There are thousands of web services out there and I do not
have time to re-invent each and every one of them as
HTTP-based service. But the new Google API is special for a
variety of reasons.
* Google has had an XML and HTTP based API in the past.
Their choice to use SOAP would seem to indicate a need to
move beyond HTTP. My experiment demonstrates that this is
not so.
* Google's service seems almost unique in how simply and
clearly one can establish an HTTP interface. In essence,
it feels like a thin SOAP wrapper over a simple HTTP
service. Making an HTTP interface for Google is a
"no-brainer".
* Google the corporation has always been known for its
technological acumen and general cluefulness. I think that
they can be convinced to do the right thing and restore
the HTTP interface (perhaps alongside the buzzword
compliant SOAP interface).
In addition, I think that the Google move is important
symbolically. I take the SOAP-ifying of Google as a sign that
the web services hype has now reached overdrive. I now
regularly hear from customers that they have working XML
systems but: "we know we'll have to move to SOAP soon." This
is simply not true.
SOAP is an unproven technology with a questionable design.
Worse, when it is misused (as in the Google API) it has a
detrimental effect on the growth of the Web. As I will
demonstrate, at the heart of the Web is the concept of URIs.
The Google API substitutes a proprietary addressing mechanism
for URIs and thus hides information from Web-based software
such as XSLT engines and XInclude implementations.
Google's SOAP API
Let's take a look first at Google's SOAP API. This is our
starting point. Here is a complete message from client to
server using their API:
I set maxResults to 0 so that I won't actually get any
results. Google returns a ton of XML metadata about the query
itself so working with query "hits" would make my examples too
long.
The message starts with HTTP headers because the Google API
runs SOAP over HTTP. The only SOAP-specific header is the
SOAPAction header which is theoretically useful for filtering
SOAP traffic. Practically speaking it is optional and thus not
a good basis for filtering.
The XML part of the message starts with some namespace
declarations, and a SOAP encodingStyle declaration (more or
less boilerplate). After that comes a set of ordered
parameters. The parameters to the operation consist of an
ordered list of values. The allowed values for the
doGoogleSearch command is are "key" (userid/password), "q"
(query text), "start" (where in the results to start
returning), "maxResult" (number of allowed results), "filter"
(filtering out very similar results), "restrict" (country or
topic restrictions), "safeSearch" (pornography filter), "lr"
(language restrict), "ie" (input encoding) and "oe" (output
encoding) properties.
The "key" property is special. It is more or less a password
assigned to a particular software developer. The Google API
seems not to support SSL so these always pass across the wire
in cleartext.
As you can see, parameters are strongly typed. The client and
server know the types in advance but for some reason, most
SOAP toolkits will inline the types into the messages. As you
will see, this is entirely unnecessary.
Here is the message Google returns:
Note that the resultElements element is empty. I warned you
that we would have quite a bit of XML to work with even
without looking at any hits!
There are two more methods. doSpellingSuggestion requests a
spelling correction suggestion. For instance it would suggest
that "britney speers" be corrected to "britney spears". It
takes only a key and string as parameters, and returns only a
string for the suggestion.
doGetCachedPage requests a cached page from Google. It takes a
key and a URI as parameters and returns Base64-encoded data
for the cached page.
HTTP Equivalent
To reinvent this as an HTTP-based web service, I merely have
to translate the properties into "query parameters" in a URI.
A couple of hundred lines of Python serve to implement the
mapping from these query parameters into Google SOAP.
Here is the sort of URI used to address into my version of the
service:
http://localhost/scripts/search.py?key=0000&q=constantrevolution+rules+
xml&maxResults=10
That's pretty ugly, but consider that nobody (even a
programmer) ever needs to look at this URI. It can be
generated, just as the SOAP message is. For instance here is a
complete Python program to fetch the information from that
URI:
import urllib
params = {"key":"0000",
"q":"constantrevolution rules xml",
"maxResults":"0",
}
urllib.urlopen("http://localhost/scripts/search.py?" +
urllib.urlencode(params))
HTTP deals with optional arguments much more gracefully than
do most WSDL-based SOAP toolkits, so I've left out any of the
arguments that can be inferred or omitted.
Let's zoom in on the special key parameter. HTTP has a
built-in authentication mechanism so really that would be a
better way to handle it. Recent implementations of HTTP have a
challenge/response [1]authentication scheme which is more
secure than simply passing a key in cleartext. Of course for
ultimate security (at a price in performance), I would
recommend you SSL encrypt the entire message. SOAP does not
itself support authentication yet, and authentication is (as
of this writing) still an [2]open issuefor SOAP's
RPC-over-HTTP binding. I will leave key as a parameter for
simplicity and to more closely parallel the SOAP version.
Here is the message that gets sent on the wire:
GET /scripts/search.py?maxResults=0&key=XXX&q=constantrevolution+rules+
xml HTTP/1.0
Host: localhost
User-agent: Python-urllib
That's all!
Now some might complain that the query parameters are all
"just strings" whereas the SOAP parameters were strongly
typed. This is not necessarily true. On the wire, of course
the parameter are just strings, just as SOAP messages are just
strings. Only at the client and the server are the strings
interpreted as other types. The client must know the types of
the parameters in order to have made the call. The server must
know the types of the parameters in order to have implemented
the service. Given both parties already know the types, it is
a waste of bandwidth to declare the types of the parameters in
each and every message. Even SOAP does not require this. It is
merely a common SOAP idiom.
This leaves the question of how that is communicated. Later I
will show a way to declare the types strongly and statically
enough to satisfy the most ardent Java or C# masochist.
HTTP allows any media type in the response to a message. It
could return any XML vocabulary whatsoever. Insofar as the
Google SOAP API already embeds a simple schema, it makes sense
to use that. I merely have to remove a few SOAP-isms (the
arrayType attribute, the SOAP-env element, etc.) and choose a
new root element type (I chose searchResult). I hereby
christen the purified language GoogleML. I've written an XSLT
stylesheet that I call "pureGoogle.xsl" which translates
GoogleSOAP into GoogleML. The resulting documents are much
smaller, simpler and easier to read.
Here is the stylesheet (minus a few namespace declarations):
And here's a GoogleML equivalent to the response from before:
HTTP provides the envelope so there would be no need for a
redundant, second SOAP envelope. The types are known in
advance so they are stripped (although I could just as easily
have left them in). GoogleML documents are not constrained to
the features of XML supported by SOAP. GoogleML documents can
use a DOCTYPE and DTD, and could use processing instructions.
The most dramatic improvement comes in the getCachedPage
request. HTTP can efficiently handle non-XML data. HTTP
delivers terabytes of binary data every day. Conversely, SOAP
requires non-XML data to be Base-64 encoded (unless the use of
the non-standards-track SOAP With Attachments specification).
Base64 data is always more verbose than unencoded binary data
so the HTTP/URI/GoogleML version of the service will always
save bandwidth and CPU power.
Compare the SOAP doGetCachedPage request:
Now compare that to an HTTP-style cachedPage request:
Compare the SOAP response (embedding base64-encoded data):
to the HTTP-style response:
Because HTTP has no problem directly embedding HTML
(well-formed or not!), there is no reason to base64-encode the
data.
Finally compare the old-style SOAP doSpellingSuggestion
response:
To the HTTP version:
I could have used XML for the response, but why? It is
overkill for this job.
Declaring Types
Unfortunately many believe that the difference between
HTTP-based services and RPC-based services is that the former
are loosely or dynamically typed and the latter are strongly
or statically typed. This is not really true. The choice
between HTTP and SOAP is a choice between protocols. The
decision to statically type-check information passing across
the wire is more concerned with service description. The two
issues are totally separate.
I've already demonstrated how one can strongly type-declare
the responses to HTTP-based services using XML Schema. If you
want to type-declare the query parameters then you can use a
language designed for type-declaring HTTP-based services like
my Web Resource Description Language (WRDL).
WRDL is still under development but in fact you can already
solve this problem today using the more popular "industry
standard" language WSDL. WSDL has some basic HTTP-declaration
features. Although WSDL is most often used with SOAP, it can
in fact type-declare the parameters for simple HTTP services.
Here is the relevant bit of a WSDL for my HTTP version of the
doGetCachedPage method:
It turns out that WSDL's handling for the <http:urlEncoded/>
works almost perfectly. It gets the parameter names from the
operation's part names. If you know WSDL then that will
probably be clear to you. If not, don't worry about it. The
input description for the other two methods is identical, so
we will concentrate on the output element.
The output for the doSpellingSuggestion has a media-type of
"text/plain":
Finally, the output for doGoogleSearch
This refers to a part named searchResult which is based upon
an element type of the same name.
Now I do not want to oversell WSDL's HTTP features. You cannot
define sophisticated HTTP-based web services with WSDL. WSDL
falls down as soon as a web resource generates links to
another web resource. WSDL cannot express the data type of the
target resource. In other words it can describe only one
resource and not the links between Web resources. SOAP lacks a
first-class concept "of resource" and especially lacks a
syntax for linking them. It is thus not surprising that WSDL
inherits this flaw. Nevertheless, I hope that this weakness
will be corrected in future versions of WSDL. In the meantime,
this is the primary reason for the existence of the WRDL
language.
For instance, imagine if the search API returned a URI to the
cached page, just as it does in the HTML version of Google.
You could declared in WRDL (as opposed to WSDL) that the
cachedPage element of searchResult resources points to a
document of type text/html. I could also define a resource
type for Google "directory catalogs", then I have strong types
for the links from search results to the directory catalogs
and back. WRDL is designed (okay, being designed) to mirror
the structure of the Web, rather than impose a
component-oriented view on top of it.
Still and all, you do not have to wait for WRDL. WSDL is
sufficient for Google's current API because the API does not
make use of hyperlinks. This is a common failing of SOAP-based
APIs which follows from the component-centric thinking that
pervades the SOAP community.
Advantages of the HTTP API
Let's consider the benefits of the HTTP version. First, I have
already discussed how HTTP has standardized ways of doing
authentication and of handling non-XML (including non-textual)
data.
The message size is a tiny fraction of the original. More
important, it is much, much easier for a typical system
security administrator to read. It is also vastly easier to
filter, log and monitor. The CPU load is also likely to be
significantly smaller. I don't even want to know how many
cycles are being wasted around the world building those silly
Google SOAP messages (sometimes base64'ing data!) and then
parsing them down again on the other side. Remember that each
and every message is also an HTTP message and must be built
and parsed as such. Californian readers should remind Google
that electricity is precious. They could switch to HTTP and
turn off a couple of wasted server clusters.
I have no need to install a SOAP implementation like .NET's or
Apache's. You can use any HTTP implementation, including
Internet Explorer, Netscape, Mozilla, Lynx, Opera, wget,
"java.net.URL", Python's httplib.HTTPConnection, Perl's LWP,
etc. In fact, you could easily test the API through a plain
old HTML form!
The HTTP version is highly amenable to caching. You can set up
a standard HTTP cache on your local network, or use one at
your ISP. Google could also do server-side caching using
something as simple as Squid. Of course caching of SOAP is
also possible: if you write the cache implementation yourself.
With HTTP, you can install any one of a variety of free or
commercial caching proxy implementations.
The HTTP version could use the little-known feature of HTTP
known as content negotiation. "Conneg" as it is known to its
fans, allows each URI to map to a resource that can deliver up
various representations of itself. For instance the service
could return the same URI in GoogleML, SOAP, XML-RPC and HTML,
depending on the preferences of the caller.
But all of these advantages are like the tiny diamonds that
ring the Big Rock.
The Web's Crowning Glory
The most important advantage is that an HTTP version is part
of the Web rather than merely being behind the web. This point
is subtle but the most central. A piece of information is on
the Web if it has a URI or is embedded in a resource with a
URI. When I expose the Google API through SOAP it is behind
the Web because the object with the web URI is the SOAP
component, not the actual query results. Only the component is
on the Web. But in the HTTP way of thinking about it, every
possible query result has its own URI and thus is a
first-class web data object.
This assigning of URIs is incredibly powerful. First, it means
that in standard hypertext documents it is possible to link to
query results. There are thousands of links around the Web to
Google search result resources. Google's HTML incarnation is
an important part of the web community as a service but it is
also an important part of the web through the thousands of
virtual "resource documents" it hosts like:
[3]http://www.google.com/search?hl=en&q=xml+-soap
Now it is time to move this concept into XML. You may recall
the days when XML was intended to be a way of publishing
structured information on the Web. One of the great virtues
was [4]supposed tobe that result sets could be more compact
and could be manipulated (e.g. sorted and filtered) using
client-side scripting. Somehow I got sidetracked with RPC
models and SOAP, but the core idea of delivering XML to the
desktop is alive and well in [5]Internet Explorer and
[6]Mozilla.
Of course public websites cannot depend upon client-side XML
support being widely deployed yet, but companies like Google
should be laying the groundwork for a future XML-based Web
rather than burying XML for use only in machine to machine
applications. One of the virtues of XML we promoted in the
1997 edition of the XML Handbook was that XML brought the
representation of information for machines and humans
together. We still have not achieved that and will not until
machines and humans use the same access protocol: HTTP.
But URI-addressability is important even for information that
will never be seen by humans. Addressable XML can be composed
into extremely sophisticated "compound-documents" using
technologies like XInclude, XSLT, XLink, RDF and Topic Maps.
For instance, consider a document that uses XInclude to
aggregate query results:
Now consider an XSLT template that does the inclusions:
And then a template in another XSLT transform could collect
the URL and snippet elements in the merged data, sort them by
URL and transform them to HTML:
Next consider an RDF assertion that related the query results
to an individual's home pages:
This is the fundamental power of the Web. The Web's strength
is that it allows us to address, link, compare, relate and
otherwise combine resources. The point that has not yet
filtered through to the mainstream of web services
implementors is that this is just as important for machine to
machine applications as it is for human-facing applications.
To repeat: linking is just as important for machine to machine
applications as it is for human-facing applications. If it is
impossible to link to SOAP-exposed resources then they are
less powerful and useful than HTTP-exposed ones. Let me
rephrase that: until SOAP has an addressing mechanism as rich
as HTTP URIs, SOAP is less, not more, powerful than HTTP.
A less generous person might argue that SOAP services are
called "web services" because they wish to partake of the
Web's success -- yet do not wish to build upon its core
technologies: URIs and HTTP.
Service as API
An important issue in all of this is ease-of-use. If it is no
longer simple for programmers to access the information then
the service will fail.
Let's start from the point of view of a programmer with no
special toolkit at all, just a standard programming language
distribution or IDE. Obviously the HTTP solution wins because
SOAP and WSDL support is not yet embedded in most programming
language distributions. It takes five lines of Java to get a
cached page or spelling correct from my version of the
service. You don't need even an XML parser installed. Of
course working through search results will require an XML
parser but it will not require a SOAP engine on top.
On the other hand, what if you already have a SOAP/WSDL
toolkit? Well if the toolkit is complete (good luck!) then it
will support WSDL's HTTP binding. You can use exactly the same
API to access the service as if you were using the SOAP
version. For instance I can generate a statically typed C#
interface from my WSDL description and it is functionally
identical to the SOAP version. Truth in advertising: to get it
actually working I did have to work around a few small bugs in
Microsoft's WSDL toolkit. WSDL implementors: please take
WSDL's HTTP bindings seriously and implement them properly!
Note that there is also a prototype of a WRDL->C# tool which
will do the same for WRDL descriptions.
If you are opposed to external service descriptions, there are
a variety of inline-type annotation techniques you could use.
Examples include the OMG's XMI, Jacobson's MIME-RPC, Winer's
XML-RPC, Allaire's WDDL and even SOAP's "section 5" encoding.
No one of these has become standardized because the common
wisdom in the strongly typed XML world is that it will be much
more common to express the types in some form of external
schema such asXML Schema, RELAX NG, Schematron or DT4DTDs.
HTTP/WRDL works perfectly with all of these and unlike the
SOAP/WSDL combination has no preference for one over the
other.
If you like neither inline typing nor schemas then you have a
third choice: you can use a language-specific databinding
technology such as Castor, JAXB or [7].NET Data Binding.
In other words, parsing XML into language-native data types is
a problem that has been solved over and over again. If you
happen to prefer the SOAP solution then use the SOAP encoding.
SOAP is XML and can be used with various XML technologies. But
remember that you can use the SOAP encoding without buying the
whole SOAP RPC-over-HTTP model. If you use the SOAP encoding
with HTTP-based URIs then you preserve the essential heart of
the Web: the ability to address information.
What Would Frodo Do?
Back in the days where XML was called SGML, we enthusiasts
were like Hobbits in the Shire, hearing tales of the distant
wars between Wizards (tools vendors), Dragons (database
vendors) and Armies (MIS departments). But we were relatively
sheltered from them. Those days have long since passed. XML
users have a special understanding of the possibilities of the
marriage of hyperlinks, XML and the Web. We have a
responsibility to go out of the Shire and educate the other
residents of Middle Earth. Google is like the wizard Saruman,
a benign and powerful force inexplicably turned from the path
of virtue. Nevertheless, I am confident that they can be won
back! The white robe awaits on the delivery of the Google API
beta 3.
What we need to do is gather together a fellowship of
like-minded Hobbits, Dwarves, Elves and men and go on a quest
to improve the world in whatever small way we can. You can
join the quest by signing the [8]petition available , and if
you don't mind registering for Yahoo Groups, you can also
participate in the thread discussing this topic. Please
forward this article to mailing lists.
We must help our fellow technologists to use SOAP only after
they have understood its limitations and to understand that
they can make the Web a richer place by putting XML-based data
on the Web rather than behind it Yes, there are Wizards,
Dragons and Armies about, but Hobbits can influence events
also.
References
1. http://www.ietf.org/rfc/rfc2617.txt
2. http://www.w3.org/TR/soap12-part2/#simpleauthfeat
3. http://www.google.com/search?hl=en&q=xml+-soap
5. http://www.xml.com/pub/a/2000/05/03/msie/
6. http://www.mozilla.org/newlayout/xml/
7.
http://msdn.microsoft.com/msdnmag/issues/01/03/cutting/cutting0103.asp?frame=true
> Surely this would be very bad as anyone could insert whatever data they > wanted into your database. Database access/manipulation IMHO is something > that should definately live behind a facade. I would generally prefer to not > even expose dataaccess routines to the outside world but wrap those up in > something that communicates what the data is doing. Without doing a REST > example, because I don't understand it yet. > > I would do something like employee.create, or update etc...This is commonly > termed as the CRUD approach. In REST would this be something like the > following? > > http://somehost.com/employee/create?id=12345 > http://somehost.com/employee/update?id=12345 > > Then on the server side there would be a create, update method on the > employee that takes an id parameter? Hey Holden, The REST answer to CRUD is that employee.create should not be exposed in a broadly distributed setting because it is a method as opposed to a resource. So http://somehost.com/employee/create?id=12345 should be, instead, POST http://somehost.com/new_employees (get back an ID, and then do...) POST http://somehost.com/employees/$ID?department=accounting So you wouldn't expose data access routines to the outside world, but you would expose data access resources. Then you just control access to the data access resources using standard HTTP access control. The net effect is precisely to wrap up the SQL in something that controls access, a.k.a. by exposing a public representatation of a private resource. - Lucas
http://xmlhack.com/read.php?item=1615 "Amazon goes REST, Google goes SOAP" Paul Prescod
IBM just dropped a submarine patent on ebXML. http://zdnet.com.com/2100-1106-884681.html Follow this thread a little to see the consequent turmoil in ebXML- related projects: http://lists.ebtwg.org/archives/ebtwg/200204/msg00056.html I work with ebXML and UN/CEFACT projects that model business protocols independently of technical implementation. I have been looking very seriously at REST (as some of you know from previous posts) and think that REST could handle all of the required business protocols. While I think the IBM will probably do something to remove the cloud over ebXML, the fact remains that everything they said they contributed and now claim patents over can be done in other ways, that is, REST. I am not a lawyer, but my guess is that using REST would have a pretty good chance of avoiding the patent claims. People who are lawyers are examining the claims as we speak, and I'll post more details as they become available (assuming there is interest). -Bob Haugen
Patent number: 6,148,290 http://www.uspto.gov/patft/ or (the long URL): http://patft.uspto.gov/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=5 0&s1='6,148,290'.WKU.&OS=PN/6,148,290&RS=PN/6,148,290 Seems to cover almost any kind of agreement on how to do business electronically, including those conducted by humans at each end. Lots of prior art has already come out of the woodwork. I can't believe this. Ok, I can.
Paul, it's wonderful! Great argument, lots of convincing detail. Suggestion for improvement: If you could put something really short illustrating the difference right after this paragraph, the attention-deficit reader (vast majority) would not need to wade through so much before getting the main point: "This article will demonstrate that the choice to use SOAP was a poor one. The much simpler HTTP URI technique was easier to use and more powerful at the same time. I will recast the new Google API back into a URI and HTTP-based API and demonstrate the virtues of the simpler HTTP strategy." <Put the main contrast here> Google SOAP: Google HTTP:
----- Original Message ----- From: "Holden Glova" <dsafari@...> > > I would do something like employee.create, or update etc...This is commonly > termed as the CRUD approach. In REST would this be something like the > following? > > http://somehost.com/employee/create?id=12345 > http://somehost.com/employee/update?id=12345 > > Then on the server side there would be a create, update method on the > employee that takes an id parameter? The URLs should be objects that support the generic methods of get, put, post, and delete rather than urls with the methods themselves (no matter how tempting it may be, and I'm just as guilty of ignoring that as anyone.). The 'post' operations means 'modify' and it could be implemented to add/subtract/extend/whatever. It can also optionally return the ID of a newly created resource. In HTTP there are similar but different operations for CRUD type of functionality. Two are easy, GET=Read and DELETE=Delete. With HTTP you have two choices to create new data, POST and PUT, depending on who knows the desired ID, as well as how you want to deal with safely repeatable operations (idempotency). You use PUT when the client knows the desired ID and POST when the server will generate the ID. So in your example, you only need to use one HTTP method (since the client is providing the ID of the new employee) PUT http://somehost.com/employee/12345/ In a database if you INSERT with a duplicate key, it fails. If you UPDATE a record that doesn't exist it fails. With PUT the record is created if it doesn't exist or updated if it does - an 'upsert'. With POST a record is created and the key is returned - and wacky things happen if you call it twice... CRUD (create, read, update, delete) is a framing of REST over relational databases (or vice-versa...) REST has the attitude of 'lots of nouns, few verbs'. Databases follow this very succesfully. Although we always talk about GET/PUT/POST/DELETE, those are just one example as applied by the HTTP. It is useful to compare the two (and others.. I should start a page on the Wiki...) and consider issues like: - are the operations safely repeatable - who controls the ID (primary key, etc) - can you create an empty resource and fill it in later
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Lucas, On Thu, 18 Apr 2002 02:19, Lucas Gonze wrote: > Erik wrote: > > However, I am not particularly interested in converting any existing > > technology into REST based ones. > > > > I am interested in simple (small) examples that demonstrate the REST > > approach with a 'readable' language like Ruby or Python, using only HTTP > > and URIS (and in more complex examples XML). Erik: along side the address book example, what about a bookmark manager? It could manage bookmarks in one central place. > During the morning commute I came to more or less the same conclusion. > In general there needs to be a listing of design issues with an example > for each. The stuff on the REST Wiki right now is too abstract. As a very new comer to REST I am still having a hard time thinking about how it works with a real application from an implementation point of view. > Design issue: resources not methods > Example: SQL insert > > One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax. > For example, > GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable > > A REST way of doing this would > * be strict about not using GET to change server state > * have the back end target be a resource rather than a procedure > > New way: > POST /tables/myTable?id=25&val=fooVal > > - Lucas Surely this would be very bad as anyone could insert whatever data they wanted into your database. Database access/manipulation IMHO is something that should definately live behind a facade. I would generally prefer to not even expose dataaccess routines to the outside world but wrap those up in something that communicates what the data is doing. Without doing a REST example, because I don't understand it yet. I would do something like employee.create, or update etc...This is commonly termed as the CRUD approach. In REST would this be something like the following? http://somehost.com/employee/create?id=12345 http://somehost.com/employee/update?id=12345 Then on the server side there would be a create, update method on the employee that takes an id parameter? - -- Signed, Holden Glova -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8vdlD+mF116Lw2cQRAsc4AJ4nsg8pRCE7YdYpTK8DQs8ve1x9jQCdEJFI LrLuNyMH2c/Z+MhKwJlI/m0= =/bI4 -----END PGP SIGNATURE-----
> While I think the IBM will probably do something to remove the cloud > over ebXML, the fact remains that everything they said they > contributed and now claim patents over can be done in other ways, > that is, REST. IBM statement, prodded by ebXML threats to vote against any encumbered feature and probably also general uproar: (my comments below) >>From: Robert S Sutor [mailto:sutor@...] >>Sent: Thursday, April 18, 2002 6:27 PM >> >>1. ebXML followed the OASIS intellectual property policy. >>2. IBM believes we followed the OASIS intellectual property policy process. >>3. IBM will NOT charge royalties on either the patent related to TPA or >>the additional one whose application we disclosed. >>We will not be amending our declaration to you, just qualifying it to you >>as above. * * * >>IBM is proud of our work in ebXML and proud of our past and current >>participation in OASIS. OASIS will be an important organization for IBM >>and the industry as we all move to a common infrastructure for >>successfully conducting business on the Internet. * * * >> >>Robert S. Sutor, Ph.D. >> Director, IBM e-business Standards Strategy I won't comment on Sutor's statement. The fact remains that these particular patterns were not the only ones lurking behind the Web service technologies. And I'm still guessing, but can't prove, that REST would be more free of such encumbrances. (Although IBM's patent was very broad, and I guess that's the way the patent lawyers write them.)
I am just getting to grips with REST and its ramifications and have a question on event notifications. Are there any attempts being made to standardise event notifications (ala http events, http notifications) at the w3 level or similar and are there any projects implementing these ideas? TIA Robert
Per the W3C and standardization, I believe consensus is that it is too soon. - Lucas Robert Leftwich wrote: > I am just getting to grips with REST and its ramifications and have a > question on event notifications. Are there any attempts being made to > standardise event notifications (ala http events, http notifications) at > the w3 level or similar and are there any projects implementing these > ideas?
You have wandered into a deep swamp, Robert. There has been a _lot_ of discussion about http notifications here -- probably too much. See Mark Nottingham's work (sorry, I don't have a URL handy on my work computer), Paul Prescod et al on the REST Wiki (http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents), and my own http://www.gonze.com/http-notifications.html - Lucas On Fri, 19 Apr 2002, Robert Leftwich wrote: > I am just getting to grips with REST and its ramifications and have a > question on event notifications. Are there any attempts being made to > standardise event notifications (ala http events, http notifications) at > the w3 level or similar and are there any projects implementing these > ideas? > > TIA > > Robert
I'm trying to make a passthrough app that will restify the Google API. I want to allow the end-user to choose whether they want to pass the Google "key" (essentially a username) as a keyword parameter or as an HTTP user name. I think this would be not too tricky except that I need to capture the HTTP user name *as* a key and pass that on to Google. The code is just simple CGI for portability. The problem is that I don't think that Apache is sending me the username, password or anything else I can use. In particular I don't get the HTTP_AUTHORIZATION header. Any ideas? Paul Prescod
At 12:13 AM 20/04/2002, Lucas Gonze wrote: >You have wandered into a deep swamp, Robert. I'm hoping that a lot of people have wandered into the same swamp before me and I can stand on the shoulders of some giants :-) >There has been a _lot_ of >discussion about http notifications here -- probably too much. See Mark >Nottingham's work (sorry, I don't have a URL handy on my work computer), >Paul Prescod et al on the REST Wiki >(http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents), and my own >http://www.gonze.com/http-notifications.html Yes, I have seen those proposals and am now contemplating how best to move forward. Robert
At 01:01 AM 20/04/2002, Lucas Gonze wrote: >Per the W3C and standardization, I believe consensus is that it is too >soon. That was my impression, I wanted to make sure I hadn't missed anything. The question then becomes, if I want to implement a REST-full solution and I require notifications, which path is the best one to take? Do I base my implementation on one of the proposed solutions (all of which have merit - at least to my not yet fully REST-ified mind) or do I not support notifications and rely on a polling solution instead (which in my case is probably borderline acceptable, at least for the initial phase)? Robert
Robert Leftwich wrote: > >... > > The question then becomes, if I want to implement a REST-full > solution and I require notifications, which path is the best > one to take? Do I base my implementation on one of the proposed > solutions (all of which have merit - at least to my not yet > fully REST-ified mind) or do I not support notifications and rely > on a polling solution instead (which in my case is probably > borderline acceptable, at least for the initial phase)? Doing notifications using HTTP is not difficult. At its heart all you are doing is setting up an HTTP server on both sides. We got bogged down trying to work out models that would be applicable to all or almost all possible event notification situations. It is highly likely that doing notifications for your particular application is relatively simple. If you discuss your requirements maybe we can help. I think that the biggest PRACTICAL issue with HTTP notifications is the same as with every other protocol: firewalls, NAT and other types of assymettric connectivity at the IP level. Paul Prescod
I don't think there are any W3C projects, there may be some related IETF and other projects that did events with HTTP. Search for "GENA General Event Notification Architecture" http://www.isr.uci.edu/events/twist/wisen98/presentations/Cohen/ and "ISEN Internet Scale Event Notification" http://www.ics.uci.edu/pub/ietf/notify/ You may also be interested in "A Survey of Event Systems, by Adam Rifkin and Rohit Khare" http://www.cs.caltech.edu/~adam/isen/event-systems.html I started a project on SourceForge to expose JMS via HTTP http://sourceforge.net/projects/destiny Its an example of how HTTP can be used for asynchronous things. Its rough and only in the early stages, but its a place to start for some things. Mike ----- Original Message ----- From: "Robert Leftwich" <robert@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, April 19, 2002 5:05 AM Subject: [rest-discuss] Event notifications in http > I am just getting to grips with REST and its ramifications and have a question on event notifications. Are there any attempts being made to standardise event notifications (ala http events, http notifications) at the w3 level or similar and are there any projects implementing these ideas? > > TIA > > Robert > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
It's possible that Apache doesn't pass the raw headers through to prevent security holes. They might extract, validate and passthrough the account name, though in a CGI environment variable REMOTE_USER. -- old bits -- http://www.w3.org/1999/02/26-modules/User/Apache-defer-auth.html Abstract Currently apache requires recompilation to allow a CGI script access to the authorization information. The maintainer must recompile with -DSECURITY_HOLE_PASS_AUTHORIZATION. There are security vulnerablilties associated with this patch: system users All information is passed from the web server to the CGI script via environment variables. Users on the system may examine the environment of a spawned script and extract the authentication credentials for that were passed to the script. script authors Any script author may get the authentication credentials for a user in any realm on the server. This means you have to trust all script authors to be resoponsible with user credentials. If These patches are for a system where there are no untrusted users but there may be unstrusted scripts. The patch allows the administrator to defer authentication to scripts on a per-directory basis. On systems with remote authoring, ie no untrusted users with shell access, but untrusted users able to insert scripts of their choosing into the resource tree. It would probably be prudent to disable Options in .htaccess files (AllowOverride None). Status This patch is not submitted to apache as it has not been tested. It is unlikely to be incorporated if it is submitted as it marginally increases the ease of introducing a security hole (editing httpd.conf or .htaccess instead of recompiling apache). ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, April 19, 2002 12:54 PM Subject: [rest-discuss] Capturing HTTP userid in CGI > I'm trying to make a passthrough app that will restify the Google API. I > want to allow the end-user to choose whether they want to pass the > Google "key" (essentially a username) as a keyword parameter or as an > HTTP user name. I think this would be not too tricky except that I need > to capture the HTTP user name *as* a key and pass that on to Google. The > code is just simple CGI for portability. The problem is that I don't > think that Apache is sending me the username, password or anything else > I can use. In particular I don't get the HTTP_AUTHORIZATION header. Any > ideas? > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
----- Original Message ----- From: "Robert Leftwich" <robert@...> > > Yes, I have seen those proposals and am now contemplating how best to move forward. > What's the problem you are trying to solve? What constraints do you have? Bringing up the problem domain may result in someone with experience with event systems and another with HTTP/REST and we may get some collaboration going. In general REST and event notification go hand in hand. When applied to HTTP, I take the point of view that "events are messages about changes to information". The 'about' part implies a reference or URI. The 'changes' part implies a set of operations. The message part doesn't necessarily imply who initiates the message - which means you can poll for messages or receive them spontaneously. My view on events is that they allow talking 'about information' across a lifetime of a resource - before it exists and after it is gone. I also think the 'changes' that are broadcast should be restricted to the methods of the generic interface you are using.
At 03:28 PM 20/04/2002, S. Mike Dierken wrote:
>What's the problem you are trying to solve? What constraints do you have?
>Bringing up the problem domain may result in someone with experience with
>event systems and another with HTTP/REST and we may get some collaboration
>going.
For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf).
From this document:
"The overall flow of this example is as follows: A traveler will plan her trip by specifying the various stages of his overall journey and all of its participants. For each of the stages, the traveler specifies the location that she wants to visit as well as the date when she wants to begin and the date when she wants to end the particular stay. When the traveler is finished with this, she sends this information together with the list of all participants of the trip as well as the information about the credit card to be charged for the ordered tickets to the travel agent. The credit card information has been passed when the business process was instantiated. Next, the traveler will await the submission of the electronic tickets as well as the final itinerary for the trip. When the agent receives the traveler�s trip order, he will determine the legs for each of the stages, which includes an initial seat reservation for each of the participants as well as the rate chosen. To actuall
y make the corresponding ticket orders the agent submits these legs together with the information about the credit card to be charged to the airline company. Then, the agent will wait for the confirmation of the flights, which especially includes the actual seats reserved for each of the participants. This information is completed into an itinerary, which is then sent to the traveler.
When the airline receives the ticket order submitted by the agent, the requested seats will be checked and if available assigned to the corresponding participants. After that, the credit card will be charged, and the updated leg information is sent back to the agent as confirmation of the flights. After that, the airline sends the electronic tickets by e-mail to the traveler. Information about the recipient of the tickets has been specified by the traveler when instantiating the trip order process and this information is passed to the agent as well as to the airline."
In order to focus on the event notification issues, assume that the rest of the system is implemented using REST (we might return to this later). The points of interest are as follows
1. Trip information to the travel agent
2. Ticket orders to the airline(s)
3. Confirmation from the airline(s) to the agent
4. Itinerary from agent to the traveller
5. e-tickets from airline(s) to the traveller and notification to agent
Some other requirements may include a monitoring service that registers an interest in all the points above to make sure things are happening in a timely manner, an auditing service and an operations management reporting service for the agents.
So the events of interest may be :
Trip request received
Trip created
Ticket order required
Ticket ordered
Ticket confirmed
Itinerary creation required
Itinerary created
Itinerary delivery required
Itinerary delivered
E-ticket received
Trip completed
How is this for a starting point?
Robert
An interesting article on JISC's Information Environment, part of the Electronic Libraries Program (http://www.ukoln.ac.uk/services/elib/), and how it compares to the web services model. Andy Powell is asking for comments. JISC: http://www.jisc.ac.uk/ Seth Johnson -------- Original Message -------- Subject: The JISC Information Environment and Web services Date: Mon, 22 Apr 2002 15:17:38 +0100 From: Andy Powell <a.powell@...> People might be interested in the following article in the current Ariadne (issue 31): The JISC Information Environment and Web services http://www.ariadne.ac.uk/issue31/information-environments/ I'd certainly be interested in hearing any comments that people have about this article. For info, a couple of new FAQs are also available on UKOLN's JISC Information Environment Web pages http://www.ukoln.ac.uk/distributed-systems/dner/arch/faq/ A general FAQ and an OAI FAQ have been added to the existing RSS FAQ. I've tried to base at least some of the questions and answers on the issues that came up at the 5/99 projects meeting in Manchester a while back. Again, comments welcome. Andy -- Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933 Resource Discovery Network http://www.rdn.ac.uk/
I feel like I'm totally out of touch with HTTP's formatting features... http://www.dynamicdrive.com/dynamicindex3/document2.htm Paul Prescod
Good lord, they used <html><head><meta http-equiv=""> (html/head/meta/@http-equiv) for that? ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <fork@...>; <rest-discuss@yahoogroups.com> Sent: Tuesday, April 23, 2002 2:03 PM Subject: [rest-discuss] HTTP's Page-Enter header` > I feel like I'm totally out of touch with HTTP's formatting features... > > http://www.dynamicdrive.com/dynamicindex3/document2.htm > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Robert Leftwich wrote: > > At 03:28 PM 20/04/2002, S. Mike Dierken wrote: > > >What's the problem you are trying to solve? What constraints do you have? > >Bringing up the problem domain may result in someone with experience with > >event systems and another with HTTP/REST and we may get some collaboration > >going. > > For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf). I haven't forgotten about or ignored this -- I want to read the appendix carefully and think it through. Paul Prescod
At 02:44 PM 24/04/2002, Paul Prescod wrote: >Robert Leftwich wrote: >> >> At 03:28 PM 20/04/2002, S. Mike Dierken wrote: >> >> >What's the problem you are trying to solve? What constraints do you have? >> >Bringing up the problem domain may result in someone with experience with >> >event systems and another with HTTP/REST and we may get some collaboration >> >going. >> >> For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf). > >I haven't forgotten about or ignored this -- I want to read the appendix >carefully and think it through. I look forward to any and all thoughts on this subject. Given the intense debate on the TAG list, I would be surprised if anyone who is subscribed to it has any spare time :-) Robert
Hi Paul Great article :-) On Thu 18-Apr-2002 at 02:29:02AM -0700, Paul Prescod wrote: > > I hereby christen the purified language GoogleML. I've written an XSLT > stylesheet that I call "pureGoogle.xsl" which translates GoogleSOAP > into GoogleML. The resulting documents are much smaller, simpler and > easier to read. Have you considered RSS 1.0 [1] for this rather than / in addition to 'GoogleML'? The things that can't be done with RSS 1.0 could be added to RSS with a Google RSS module. The advantage of not inventing a new language is that there are lots of tools out there for processing RSS and it's perhaps the widest used XML variety after XHTML and as result developers who are familiar with RSS might 'get it' (advantages of REST) quicker? Using RSS as a format for returning search engine results has been suggested before and was mentioned in an article on xml.com almost two years ago [2]. Chris [1] http://pulr.org/rss/1.0/ [2] http://www.xml.com/pub/a/2000/07/05/deviant/rss.html -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
> I haven't forgotten about or ignored this -- I want to read the appendix > carefully and think it through. Yah, ditto. My first impression is that it looks really good from a resource modelling point of view, but it appears to break down in the WSDL where operations rather than types are defined. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > I haven't forgotten about or ignored this -- I want to read the appendix > > carefully and think it through. > > Yah, ditto. My first impression is that it looks really good from a > resource modelling point of view, but it appears to break down in the > WSDL where operations rather than types are defined. I think workflow is a bad model for the Web for reasons that are analogous to why RPC is a bad model. Workflow is organized around procedures, not resources. RosettaNet started by trying to use a procedural workflow model but abandoned it for a conversational state alignment model. I'm not suggesting the RosettaNet model for REST, becsuse RNet is a message- passing system, as in message-oriented SOAP. But I am pretty sure that REST also needs to adopt an appropriate orchestration model that is different from procedure-oriented workflow. And that the REST model should be oriented around resource state. (Others have said similar things on the REST wiki.) I also think that a resource state model will end up being much simpler than workflow. -Bob Haugen
I was wondering if there might be a way to "slice" this that may be a little more RESTful. In REST a resource represents a service or a data element, and every significant resource should have a URI. In the given system there were two services: "availabiltiy amount" and "is quantity available", and one data element: the BlueShoe product. It seems that each of these should have their own URI so: Availability amount service: http://www.myinventory.com/services/availablequantity Is quantity availabilty service: http://www.myinventory.com/services/isavailable BlueShoe: http://www.myinventory.com/product/blueshoe Then to do the queries the following URIs would be used: 1) http://www.myinventory.com/services/availablequantity? product=http://www.myinventory.com/product/blueshoe&when=tomorrow 2) http://www.myinventory.com/services/isavailable? product=http://www.myinventory.com/product/blueshoe&when=tomorrow &above=100 Like I said, this seems a little more RESTful to me, and I'm trying to figure out what the advantages of this approach would be other than that it just seems to be the right way. One thing is that it uses a standard way of naming the products (via URIs) instead of naming them by adding to a sub-path of an existing URI. This seems more extensible: to add new products into the system, you don't add new paths to the URI, just use new query strings. I Is this a real advantage? Are there any other advantages to doing it this way? Opinions would be appreciated. Thanks, Toivo Lainevool New Iron Systems --- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > > Interesting. > > The URI (path+query) would point to the answer you want to give, having the > 'path only' point to the product is neato, but not required. > > To get the availability: > http://www.myinventory.foo/products/blueshoes/availability/? when=tomorrow > > To get the threshold (more than 100) > http://www.myinventory.foo/products/blueshoes/availability/? when=tomorrow&ab > ove=100 > > But of course there are a million ways to slice it. > You can narrow down the choices based on whether PUT/DELETE/POST are needed > on the same resource - and they probably aren't. POST might be used to > allocate out of the availability - but a business document probably will > have that information & so you'd just submit it to the 'orders' collection & > let the values be updated via business logic (meaning that the values from > these two sample queries are 'synthetic' properties, derived from data > manipulated via other actions) > > > ----- Original Message ----- > From: "bhaugen32" <bhaugen32@y...> > To: <rest-discuss@y...> > Sent: Thursday, April 04, 2002 10:42 AM > Subject: [rest-discuss] Restifying Available to Promise > > > > Assuming this group is still alive (I know everybody's been busy > > evangelizing in W3C lists), I have a followup question on the > > purchase order scenarios. > > > > There is a standard function in an ERP system called Available to > > Promise, or ATP for short. > > > > "Available" means "not already promised to somebody". > > > > It is used to decide if a purchase order can be fulfilled or not. > > It is usually used for purchase orders for products, so that is what > > I will describe here. > > > > There are a variety of APIs and algorithms, but they boil down to two > > main queries, which I will describe in plain English, not code: > > > > 1. How much of a product is available to promise at a future time? > > For example, how many blue shoes can I get by tomorrow? > > The answer is a quantity. > > > > 2. Is a specified quantity of a product at a specified time? > > For example, can I get 100 blue shoes tomorrow? > > The answer is a boolean. > > > > This query might be offered to a customer to use before they place an > > order, or it might be used by the order-taking Web resource before > > accepting an order. > > > > In REST terms, I assume this is a GET with parameters, and the Web > > resource to address is the Product (i.e. BlueShoe). > > > > How would you say it? > > > > Thanks, > > Bob Haugen > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@y... > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > >
"tlainevool" wrote: > I was wondering if there might be a way to "slice" this that may be a > little more RESTful. In REST a resource represents a service or a > data element, and every significant resource should have a URI. "Service" seems to me a lot more like SOAP than REST. I think of resource as a significant business entity or an aggregation of business entities. Usually larger granularity than a data element. > In > the given system there were two services: "availabiltiy amount" > and "is quantity available", and one data element: the BlueShoe > product. It seems that each of these should have their own URI so: > > Availability amount service: > http://www.myinventory.com/services/availablequantity > > Is quantity availabilty service: > http://www.myinventory.com/services/isavailable Let's contrast that with Mike Dierken's original suggestion: http://www.myinventory.foo/products/blueshoes/availability/ "Availability" is actually an aggregate business entity. It is the aggregate of on hand inventory plus the stream of expected receipts, minus the stream of expected demands. It might also be called MRP (Material Requirements Plan). "Availability" even has a standard representation: a time-phased table of planned inventory inputs and outputs with a running balance. A query into this table can show the available balance at some future date. As an old MRP jock, I like Mike's suggestion better. As to which is more RESTful, I leave that to further discussion. I'm a rookie here myself. -Bob Haugen
> > > > Is quantity availabilty service: > > http://www.myinventory.com/services/isavailable > > Let's contrast that with Mike Dierken's original suggestion: > http://www.myinventory.foo/products/blueshoes/availability/ > > > As to which is more RESTful, I leave that to further discussion. > I'm a rookie here myself. My thoughts on REST are that one aspect implies 'lots of nouns, few verbs'. When applied to HTTP, this means each URI would reasonably support GET/PUT/POST/DELETE. If the system accepted changes to availability via HTTP, then a PUT to the URI might make sense - in this example, 'availability' is a very synthesized entity and it probably doesn't make sense. The differences between the two are fairly minor. http://www.myinventory.com/services/availablequantity?product=http://www.myi nventory.com/product/blueshoe&when=tomorrow http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow I chose not to use full a URI to indicate the product, because I felt the owner of the resources would have their own 'internal ID' of the product, and I didn't expect them to be fully URI based for their keys - but they could just as easily be URIs. I also didn't break the problem down into functions and parameters - I tried to break it down into addressable information entities. This way it would be easy to 'hang new properties' off of a product via the path segments of a URI. But that is purely a stylistic opinion - I just like path based rather than query string based addressing. It helps me concentrate on information rather than function+parameters. Something I'm still thinking about is how a client acquires the URI to begin with. Either of these two approaches could return the same data, so they are equivalent from that point of view - but is one easier to use from the client? This gets into the "hyperlink .vs. generative" argument. I like the hyperlink approach because it has the promise of a client talking to these two different styles of URIs without knowing or caring - more loose coupling. But I like the generative approach because the client may have a fragment of information that is not part of the name/location of the hyperlink that has the URI, but is actually part of the value of the URI. Here are some concrete examples that help me think about the issues. In both cases the text 'productId' is a coordinating name. In both cases the client also knows the value 'blueshoes'. One difference is that the hyperlink examples has to list all possible values - which might be a bit much. --hyperlink1-- <stuff> <availability productId='blueshoes'>http://www.myinventory.foo/products/blueshoes/availabi lity/?when=tomorrow</availability> </stuff> --hyperlink2-- <product productId='blueshoes'> <availability>http://www.myinventory.foo/products/blueshoes/availability/?wh en=tomorrow</availability> <description>http://www.myinventory.foo/products/blueshoes/description/</des cription> </stuff> --generative1-- <stuff> <availability>http://www.myinventory.foo/products/%productId%/availability/? when=tomorrow</availability> </stuff> --generative2-- <stuff> <availability>http://www.myinventory.foo/products/<productId />/availability/?when=tomorrow</availability> </stuff> --generative3 (not recommened, since entities scare the bunnies and break lots of code)-- <stuff> <availability>http://www.myinventory.foo/products/&productId;/availability/? when=tomorrow</availability> </stuff>
A while ago I wrote up a set of ideas for RESTifying a service. I
began implementing those ideas, but abandoned them as the code began
to get more and more repetitive. Writing a REST application seems
naturally suited to a code generator.
However, what description format should this code generator take?
Paul uses a WSDL example in his latest xml.com article, but observes
that WSDL doesn't support links. I also noticed that the WSDL note
only mentions HTTP GET/POST, and for a code generator you'd want to
say what other HTTP operations (DEL, PUT, &c) are supported on a
resource. Also, the authors of the note are all from large companies
that have embraced SOAP, making me pessimistic about the likelihood of
improving the WSDL HTTP binding.
The other option is Paul's WRDL, but its current state of completion
isn't clear, though the TODO list does seem to be mostly second-order
things.
Anyone have suggestions on which format would be the best choice?
--amk (www.amk.ca)
"Symbols have *power*, Netley... Power enough to turn even a stomach such as
yours, or to deliver half this planet's population into slavery."
-- Gull, in FROM HELL #4
Code for client or server? What do you have so far - in terms of common code/api tasks? ----- Original Message ----- From: "Andrew Kuchling" <akuchlin@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, April 25, 2002 1:00 PM Subject: [rest-discuss] Autogenerating REST code: which format? > A while ago I wrote up a set of ideas for RESTifying a service. I > began implementing those ideas, but abandoned them as the code began > to get more and more repetitive. Writing a REST application seems > naturally suited to a code generator. > > However, what description format should this code generator take? > Paul uses a WSDL example in his latest xml.com article, but observes > that WSDL doesn't support links. I also noticed that the WSDL note > only mentions HTTP GET/POST, and for a code generator you'd want to > say what other HTTP operations (DEL, PUT, &c) are supported on a > resource. Also, the authors of the note are all from large companies > that have embraced SOAP, making me pessimistic about the likelihood of > improving the WSDL HTTP binding. > > The other option is Paul's WRDL, but its current state of completion > isn't clear, though the TODO list does seem to be mostly second-order > things. > > Anyone have suggestions on which format would be the best choice? > > --amk (www.amk.ca) > "Symbols have *power*, Netley... Power enough to turn even a stomach such as > yours, or to deliver half this planet's population into slavery." > -- Gull, in FROM HELL #4 > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Andrew Kuchling wrote: > > A while ago I wrote up a set of ideas for RESTifying a service. I > began implementing those ideas, but abandoned them as the code began > to get more and more repetitive. Writing a REST application seems > naturally suited to a code generator. I'm somewhat surprised to hear you say that, because in my experience, code generators are for people using lesser languages. ;) Python programmers can typically do at runtime what code generators do at compile time -- and with more flexibility and ease of use. So I would say that you are in a good position to start with your code and factor away the irrelevancies using Python constructs until you have essentially factored the code into a declarative portion and an executable portion. If the declarative portion corresponds exactly to WRDL then I'm on the right track with it. > However, what description format should this code generator take? > Paul uses a WSDL example in his latest xml.com article, but observes > that WSDL doesn't support links. I also noticed that the WSDL note > only mentions HTTP GET/POST, and for a code generator you'd want to > say what other HTTP operations (DEL, PUT, &c) are supported on a > resource. Also, the authors of the note are all from large companies > that have embraced SOAP, making me pessimistic about the likelihood of > improving the WSDL HTTP binding. WSDL is not a W3C project so you are not subject to the whims of W3C politics which may make you feel better or not. They have accepted my requirement that WSDL should support links as an official requirement (so far) but in my thinking about this issue, it is not trivial so they may be tempted to do it in a half-assed way when they actually sit down to implement. WSDL is kind of a complicated language with many different layers of abstraction. This will make code generation a pain in the ass. The AXIS SOAP toolkit's "wsdl2Java" is almost 9000 lines of non-comment Java code. Plus, I don't know how far you will get with WSDL given its current state of link-support. It's not that I'm biased in favor of my own language: I would love to have an "industry standard" language that already supported REST. If you can make WSDL work for you then more power to you, maybe I can learn something. > The other option is Paul's WRDL, but its current state of completion > isn't clear, though the TODO list does seem to be mostly second-order > things. True. In my mind the primary weakness with WRDL is that it isn't integrated into any kind of data binding framework. To clarify: WSDL more or less depends upon XML Schema. That means that if you figure out a way to map XML Schema into your language (as many languages have done -- at least for simple stuff) then you can generate wrapper classes that know how to serialize and deserialize themselves "for free". If C#/Java programmers have to go back to working with a DOM then they will not be happy with WRDL. On the other hand, I am loathe to make WRDL explicitly depend on XML Schema when that is such a hard language to implement and use. I also don't want to choose RELAX when XML Schema is where the rest of the industry is going. In theory I could say: "use whatever schema language you want" but then a WRDL implementation that uses RELAX will not be entirely interoperable with one that uses XML Schema. Still, that's probably the way I will go and let the market decide. A third option is to ignore the schema and make a simple data binding language -- maybe compile the different schema languages to that. Also, as an implementation issue, WRDL should naturally "extend" the data binding process by making elements and attributes of type anyURI strongly typed. That could be difficult in many data binding frameworks. :( If you are happy working with a DOM instead of data-bound, bi-directional "objects" then I think WRDL is a good place to start. Paul Prescod
On Thu, Apr 25, 2002 at 03:52:22PM -0700, Paul Prescod wrote:
>So I would say that you are in a good position to start with your code
>and factor away the irrelevancies using Python constructs until you have
>essentially factored the code into a declarative portion and an
>executable portion. If the declarative portion corresponds exactly to
There were two problems, at least when doing this in Quixote. The
first was that I ended up writing a class to represent each object and
sub-object; so if there was a Service URI, and Services contain
Tickets, I needed to write Service and Ticket classes. The second was
that my method implementations all looked like:
def metadata (request):
rm = request.environ['REQUEST_METHOD']
if rm == 'GET':
# retrieve data & return it
elif rm == 'PUT':
# read body & store it
elif rm == 'POST':
# whatever POST does
I suppose some clever base class could do this work, and call
metadata_get() and metadata_put() methods.
>They have accepted my
>requirement that WSDL should support links as an official requirement...
Wouldn't PUT/DEL also need to be supported in order to implement all
of REST?
>True. In my mind the primary weakness with WRDL is that it isn't
>integrated into any kind of data binding framework. To clarify: WSDL
>more or less depends upon XML Schema. That means that if you figure out
>a way to map XML Schema into your language (as many languages have done
>-- at least for simple stuff) then you can generate wrapper classes that
>know how to serialize and deserialize themselves "for free".
Does this matter for a dynamic language, though? You could just
return XML-marshalled objects of whatever type, agreeing on the DTD
beforehand, and let the chips fall at runtime.
--amk (www.amk.ca)
"Yes, but who do you work for?"
"Work for? I don't work *for* anybody; I'm just having fun."
-- Rigg and the Doctor, in "Nightmare of Eden"
akuchlin@... wrote: > > ... > > There were two problems, at least when doing this in Quixote. The > first was that I ended up writing a class to represent each object and > sub-object; so if there was a Service URI, and Services contain > Tickets, I needed to write Service and Ticket classes. Some people would call that "resource object binding" and call it a feature. Plus you could use a base class for anything repetitive. >... > I suppose some clever base class could do this work, and call > metadata_get() and metadata_put() methods. Good idea. > >They have accepted my > >requirement that WSDL should support links as an official requirement... > > Wouldn't PUT/DEL also need to be supported in order to implement all > of REST? I'm planning to submit that as a "WSDL 1.1 bug report" and see if it gets fixed. I'm somewhat of a REST heretic in that I think that you get a big chunk of the benefit from GET and POST is a way to handle non-idempotent stuff. I'm not saying that's ideal but that its probably sufficient. Worse comes to worse, you > >True. In my mind the primary weakness with WRDL is that it isn't > >integrated into any kind of data binding framework. To clarify: WSDL > >more or less depends upon XML Schema. That means that if you figure out > >a way to map XML Schema into your language (as many languages have done > >-- at least for simple stuff) then you can generate wrapper classes that > >know how to serialize and deserialize themselves "for free". > > Does this matter for a dynamic language, though? You could just > return XML-marshalled objects of whatever type, agreeing on the DTD > beforehand, and let the chips fall at runtime. It is nice to know when you see the XML whether it should be treated as a struct or array, integer, string or boolean. The schema can tell you that -- otherwise you need to treat all child nodes as a string (in case you happen to have repeated elements) and all attributes as "just strings". Paul Prescod
bhaugen32 wrote: > > "tlainevool" wrote: > > I was wondering if there might be a way to "slice" this that may be > a > > little more RESTful. In REST a resource represents a service or a > > data element, and every significant resource should have a URI. > > "Service" seems to me a lot more like SOAP than REST. > I think of resource as a significant business entity > or an aggregation of business entities. > Usually larger granularity than a data element. > I'm not sure if this is true. Roy Fielding dissertation defines a resource as "Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on." HTTP defines it as "A network data object or service that can be identified by a URI". It seems like services are a valid concept to assign a URI to. Toivo Lainevool
S. Mike Dierken wrote: > > My thoughts on REST are that one aspect implies 'lots of nouns, few > verbs'. > When applied to HTTP, this means each URI would reasonably support > GET/PUT/POST/DELETE. If the system accepted changes to availability via > HTTP, then a PUT to the URI might make sense - in this example, > 'availability' is a very synthesized entity and it probably doesn't make > sense. > This is one concept I keep trying to get my head wrapped around. I've been developing and using ORBs for a while, so I always leap to a very RPCish view. I see this as one of the main differences between RPC and REST: RPC's whole reason for existing is to define NEW verbs, REST limits them so that the underlying architecture can use the verbs intelligently when doing things like security and caching. I have to keep reminding myself that URIs do not identify methods or groups of methods, they identify resources. > > Something I'm still thinking about is how a client acquires the URI to > begin > with. Either of these two approaches could return the same data, so they > are > equivalent from that point of view - but is one easier to use from the > client? This gets into the "hyperlink .vs. generative" argument. I like > the > hyperlink approach because it has the promise of a client talking to these > two different styles of URIs without knowing or caring - more loose > coupling. But I like the generative approach because the client may have a > fragment of information that is not part of the name/location of the > hyperlink that has the URI, but is actually part of the value of the URI. > This is an interesting topic. When it comes to the underlying components in a RESTful system, the URI are opaque. The servers, proxies and gateways don't care what the internal format of the URIs are, but the system you build on top of it could care about the details. Having the client be able to work with the format of the URI might make for a more powerful system. If the system has a resource for returning a product catalog, e.g.: <products> <product name="http://www.myinventory.foo/product/blueshoe"> <product name="http://www.myinventory.foo/product/redshoe"> ... etc ... </products> In that case it would be reasonable for the client to do a GET on the name URI and receive a product information document. PUT/POST/DELETE could also be used for modifying/deleting the product information. The client could then also use these same product names in the query part of the availability URIs, as I explained earlier, like this: http://www.myinventory.com/services/availablequantity?product=http://www .myi nventory.com/product/blueshoe&when=tomorrow In the earlier suggestion where the following URI was used: http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro w The "blueshoe" product would be known by two names by the client, the URI and the name "blueshoe". I guess my point is that since we already have a way of naming things in a REST system (i.e. URIs), why not use it for every name in the system? This was one of the points made in Paul Prescod's xml.com article about a RESTful version of UDDI; why use GUIDs when you already have URIs? Toivo Lainevool
"Toivo \"Deutsch\" Lainevool" wrote: > > > bhaugen32 wrote: > > > > "tlainevool" wrote: > > > I was wondering if there might be a way to "slice" this that may be > > a > > > little more RESTful. In REST a resource represents a service or a > > > data element, and every significant resource should have a URI. > > > > "Service" seems to me a lot more like SOAP than REST. > > I think of resource as a significant business entity > > or an aggregation of business entities. > > Usually larger granularity than a data element. > > > > I'm not sure if this is true. Roy Fielding dissertation defines a > resource as "Any information that can be named can be a resource: a > document or image, a temporal service (e.g. "today's weather in Los > Angeles"), a collection of other resources, a non-virtual object (e.g. a > person), and so on." HTTP defines it as "A network data object or > service that can be identified by a URI". It seems like services are a > valid concept to assign a URI to. I am not a purist, and can go along with assigning a URI to a service. But when you already have a Product resource, it seems to me that asking a Service for availability by Product is going backwards to something more like a Web service. I like much better asking the Product resource for its availability, especially when "availability" itself is a well-recognized business aggregation with a standard definition from APICS, the Production and Inventory Control Society. In a Web business situation, I want my significant business entities to be resources with URIs: products, orders, disbursements and receipts, etc. I want them also to be hyperlinked to each other: products to orders, orders to products, disbursements and receipts to orders, etc. All of the above is why REST makes more sense to me from a business modeling perspective than SOAP. As Mike Dierken says, I want more nouns than verbs. As I said, this is just the way I think about it as a rookie. But I've been working my way through some common business situations and it's holding up pretty well so far. -Bob Haugen
Mark Baker wrote in http://lists.w3.org/Archives/Public/www-tag/2002Apr/0290.html "I think that if SOAP has a future on the Web (as opposed to on the Internet), it will be with the chameleon use where both SOAP and HTTP are used by developers at the same time (though an EDI-like use of SOAP over POST is fine, it's a niche)." ebXML (where I still spend a lot of time) is an example of the niche of EDI-like use of SOAP over POST. I'm finding it instructive to consider RESTifying ebXML. When you do EDI-like messaging over SOAP, all the messages get sent to what amounts to a mailbox with a URI. Behind the mailbox is a dispatcher that forwards the messages to some internal system function that will handle them. Which means ebXML messages need to be tagged with a bunch of dispatching addresses that are usually not URIs. ebXML has a collaboration containment hierarchy that goes like: BusinessCollaboration ..BusinessTransaction ....BusinessAction (Requesting or Responding) So a message needs to be tagged with identifiers for each layer in that hierarchy to get to its eventual destination (the handler for the BusinessAction). And all (or at least many) messages need to go through the same dispatcher. If I consider that from a REST perspective, we're collaborating about some business deal which is usually embodied in a common business entity: let's say an Order. So if I make the Order into a Web resource, created by the initial POST, then all subsequent POSTs or GETs are addressed either to that Order resource or one of its sub-resources (LineItems, Deliveries, Invoices, Payments, etc.) I consider Transactions to be business entities, so they could be sub- resources. So I no longer have one gateway URI with a dispatcher behind it, I am directly addressing the relevant business resource. Seems much simpler and more scalable to me. (By the way, if anybody from ebXML is reading this, I think this is all compatible with the business principles behind ebXML...so don't shoot me yet.) Does this make sense to anybody else? -Bob Haugen
On Fri, Apr 26, 2002 at 05:09:09PM -0000, bhaugen32 wrote: > Does this make sense to anybody else? Yep, that's exactly my thinking too. Plus, because you're identifying the mailbox at a more granular level than just a catch-all mailbox, GET, PUT, and DELETE makes sense. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > because you're identifying the mailbox at a more granular > level than just a catch-all mailbox, GET, PUT, and DELETE makes > sense. If it the resource is not really a mailbox, but a business entity, then GET always makes sense. The business entity can always summon up a representation of its current state. Permission for PUT and DELETE would be up to the resource, and may depend on its current state (for example you can't delete the resource for an airline ticket after it's been issued, and even cancellation may invoke a penalty). -BH
----- Original Message ----- From: "Toivo "Deutsch" Lainevool" <tlainevool@...> > > In that case it would be reasonable for the client to do a GET on the > name URI and receive a product information document. PUT/POST/DELETE > could also be used for modifying/deleting the product information. > > The client could then also use these same product names in the query > part of the availability URIs, as I explained earlier, like this: > http://www.myinventory.com/services/availablequantity?product=http://www > .myi > nventory.com/product/blueshoe&when=tomorrow > > In the earlier suggestion where the following URI was used: > http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro > w > The "blueshoe" product would be known by two names by the client, the > URI and the name "blueshoe". > You are right about the need for two names - I'm just not sure what the best way of doing it is. It seems that using a URI for everything is a bit excessive, but I haven't spent a lot of time in this area.
"S. Mike Dierken" wrote: > > ----- Original Message ----- > From: "Toivo "Deutsch" Lainevool" <tlainevool@n...> > > > > > In that case it would be reasonable for the client to do a GET on the > > name URI and receive a product information document. PUT/POST/DELETE > > could also be used for modifying/deleting the product information. > > > > The client could then also use these same product names in the query > > part of the availability URIs, as I explained earlier, like this: > > http://www.myinventory.com/services/availablequantity? product=http://www > > .myi > > nventory.com/product/blueshoe&when=tomorrow > > > > In the earlier suggestion where the following URI was used: > > http://www.myinventory.foo/products/blueshoes/availability/? when=tomorro > > w > > The "blueshoe" product would be known by two names by the client, the > > URI and the name "blueshoe". > > > You are right about the need for two names - I'm just not sure what the best > way of doing it is. It seems that using a URI for everything is a bit > excessive, but I haven't spent a lot of time in this area. I don't understand the two names argument. What two names do you mean? URI including "blueshoes" plus "blueshoes" all by itself? Why is that a problem? Nor do I understand "services/availability/?product=" vs "products/blueshoes/availability". What am I missing? >It seems that using a URI for everything is a bit > excessive, but I haven't spent a lot of time in this area. Why isn't it better for more things to have identities? (I'm not sure where "excessive" begins, but for each product to have its own URI does not seem to be even close to the edge.)
> > I don't understand the two names argument. > What two names do you mean? > URI including "blueshoes" plus "blueshoes" all by itself? Yes. > Why is that a problem? Anytime you have to keep track of one with two names I think you are asking for trouble. > > Nor do I understand "services/availability/?product=" > vs "products/blueshoes/availability". > > What am I missing? The difference is not major. To the underlying components (HTTP servers, caches, etc) they are identical. The difference comes if you want to be able to generate these URIs and you want to use URIs for the name of the product. Then the first one works. > > >It seems that using a URI for everything is a bit > > excessive, but I haven't spent a lot of time in this area. > > Why isn't it better for more things to have identities? > (I'm not sure where "excessive" begins, but for each product to have > its own URI does not seem to be even close to the edge.) > I think he meant "using a URI" is excessive not "a URI for everything" is excessive. I personally don't think it is excessive because hopefully all this is automated so the user never sees these names. URIs don't cost anything to create vs. a simple string. (Well maybe a little extra memory, but not enough to really matter.) Toivo Lainevool
> > > > Nor do I understand "services/availability/?product=" > > vs "products/blueshoes/availability". > > > > What am I missing? > > The difference is not major. To the underlying components (HTTP > servers, caches, etc) they are identical. The difference comes if you > want to be able to generate these URIs and you want to use URIs for the > name of the product. Then the first one works. I agree that historically it has been easier to construct a uri via query terms - but that doesn't make path based URI construction difficult, it just means nobody has provided a commonly recognized way to do it. It ends up being an implementation preference, in my opinion, because I think you are right when you point out that the underlying components see them as identical. I suppose that the choice between a short identifier and a URI (for product ID in the examples) depends on how you acquire that product ID - in most cases you will just echo back what the server gave to you initially (and a full uri probably works better as a query term). A full-blown hypertext approach would be URI through and through, but I believe that has problems with interoperability - every service that wants to participate must know the full URI of the product, which to me seems very constraining on implementation choices. But it also means some sort of correlation ability needs to exist - which might add too much complexity. I need to spend some time and try different approaches out (which will be quite a while...) > > > > > >It seems that using a URI for everything is a bit > > > excessive, but I haven't spent a lot of time in this area. > > > > Why isn't it better for more things to have identities? > > (I'm not sure where "excessive" begins, but for each product to have > > its own URI does not seem to be even close to the edge.) > > > I think he meant "using a URI" is excessive not "a URI for everything" > is excessive. Yes. > I personally don't think it is excessive because > hopefully all this is automated so the user never sees these names. > URIs don't cost anything to create vs. a simple string. (Well maybe a > little extra memory, but not enough to really matter.) I agree also - but without playing with a couple systems that do this - and try to connect between them without them being aware of it - I'm not sure if it is doable. It just seems that to bridge autonomous services (unaware of each other) you are going to have to do uri mapping (not to mention message format mapping...)
I'm not sure I understand this "two name" problem. If I have a URI identifying me, and I want another URI that identifies the clothes I'm currently wearing, the latter URI does not need to use the former URI in a query term, or in any other fashion. Just have; http://www.markbaker.ca/ and http://www.markbaker.ca/current-clothes/ Any relationship between the two should be expressed as an assertion someplace. e.g. <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/> MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Fri, 2002-04-26 at 21:56, S. Mike Dierken wrote: > > It ends up > being an implementation preference, in my opinion, because I think you are > right when you point out that the underlying components see them as > identical. > Actually, there are some differences beyond the aesthetic; cf. the "generative naming" discussions here on list and on the Wiki about a month ago. Short version: there are things we can guarantee about path-based URI that can't be easily or at all guaranteed with path-based constructions. $0.02, jb
On Fri, 2002-04-26 at 23:14, Jeff Bone wrote: > > that can't be easily or at all guaranteed with path-based > constructions. "with query-based constructions." jb
Hi amk, I've been plugging away (slowly) at a framework I'm calling Tarawa for a while. It's basically a toolkit for writing RESTful web applications, and is an outgrowth/generalisation of the exploration I did in Wallal [1]. The idea is to play off of the similarities between objects and REST; instance -> resource (noun) method -> method (verb) parameters -> parameters / query return value -> representation Thus, tarawa would define a class, Resource, which you could subclass into a specific kind of resource, say a homepage, and then hang methods off it, which would handle content negotiation; class Homepage(tarawa.Resource): def GET_text_html(self, parameters, query_args): [ process ] return representation def text_xml_PUT_text_html(self, parameters, query_args, representation): [ ... ] return representation and so forth. This gives you a nice way to resource-model apps, and the ability to drop in a variety of back-ends (e.g., CGI, medusa, etc.) State would live with the instance, and can be loaded and stored at instance __init__ and __del__ as appropriate. In the future, I'd like to have intermediate subclasses to handle things like authentication, caching, etc. It's now mostly a lot of pseudocode, although I think it's mostly functional at a high level; the conneg and dispatching stuff is pretty much ready for testing. If anyone's interested, I'll document what's there and throw it up; I'd be glad for some help / ideas / crit. Cheers, 1. http://www.mnot.net/wallal/ On Thursday, April 25, 2002, at 09:33 PM, akuchlin@... wrote: > On Thu, Apr 25, 2002 at 03:52:22PM -0700, Paul Prescod wrote: >> So I would say that you are in a good position to start with your code >> and factor away the irrelevancies using Python constructs until you >> have >> essentially factored the code into a declarative portion and an >> executable portion. If the declarative portion corresponds exactly to > > There were two problems, at least when doing this in Quixote. The > first was that I ended up writing a class to represent each object and > sub-object; so if there was a Service URI, and Services contain > Tickets, I needed to write Service and Ticket classes. The second was > that my method implementations all looked like: > > def metadata (request): > rm = request.environ['REQUEST_METHOD'] > if rm == 'GET': > # retrieve data & return it > elif rm == 'PUT': > # read body & store it > elif rm == 'POST': > # whatever POST does > > I suppose some clever base class could do this work, and call > metadata_get() and metadata_put() methods. > >> They have accepted my >> requirement that WSDL should support links as an official >> requirement... > > Wouldn't PUT/DEL also need to be supported in order to implement all > of REST? > >> True. In my mind the primary weakness with WRDL is that it isn't >> integrated into any kind of data binding framework. To clarify: WSDL >> more or less depends upon XML Schema. That means that if you figure out >> a way to map XML Schema into your language (as many languages have done >> -- at least for simple stuff) then you can generate wrapper classes >> that >> know how to serialize and deserialize themselves "for free". > > Does this matter for a dynamic language, though? You could just > return XML-marshalled objects of whatever type, agreeing on the DTD > beforehand, and let the chips fall at runtime. > > -- Mark Nottingham http://www.mnot.net/
"Toivo \"Deutsch\" Lainevool" wrote: > > > > I don't understand the two names argument. > > What two names do you mean? > > URI including "blueshoes" plus "blueshoes" all by itself? > > Yes. > > > Why is that a problem? > > Anytime you have to keep track of one with two names I think you are > asking for trouble. If you mean programmatically or in hyperlinks, if the URI is the identifier of the product, why would you ever need to use "blueshoes" all by itself? (Unless you were searching for its URI.) > > Nor do I understand "services/availability/?product=" > > vs "products/blueshoes/availability". > > > > What am I missing? > > The difference is not major. To the underlying components (HTTP > servers, caches, etc) they are identical. The difference comes if you > want to be able to generate these URIs and you want to use URIs for the > name of the product. Then the first one works. Re "name of the product": The "products/blueshoes" URI *is* the Web resource identifier of the product. I don't understand how "services" is a better name for a product. Re availability syntax: Either way I have to get either a full URI or a partial URI from somewhere: sent in a message or found by query or navigation. In your "services/availability/?product=" notation, I needed to know not only that syntax plus the URI of the product. If I have the URI of the product, I can ask it for its business protocols which could be expressed in some as-yet-to-be-defined business protocol representation, related to Paul's WRDL. If I want to find "services/availability", I would need to do something similar. In other words, I don't see any big technical advantage to the "services/availability/?product=" notation. And semantically it seems like a Web service, not a resource. But I am pretty sure that the product will have its own URI, and "availability" is a natural property (thus sub-resource) of a product. So semantically I like it better. I think it will be a better way to compose relationships between resources.
Mark Baker wrote: > > I'm not sure I understand this "two name" problem. > >... > > Any relationship between the two should be expressed as an assertion > someplace. e.g. > I want to stress this point. If you can connect things through hyperlinks rather than URI combinations then increasingly your "service description" can be considered an outgrowth of your "vocabulary description". I think of REST as pushing as much of the incompatibility of the world down into the vocabulary description. Vocabularies *must* vary (that's the whole point of XML). As we've demonstrated, method name do NOT NEED to vary, so push the incompatibility OUT of the method names and down into the markup. > <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/> Mark uses RDF. I would typically use plain old xml. <person> <clothes href="/current-clothes"/> ... </person> Of course the virtue of RDF is that it is easily done out-of-line but IMO, out-of-line declarations are much harder to discover and maintain (were it otherwise, XML markup itself would be out-of-line). So I would say that out-of-line declarations are a fallback and inline I would discriminate against RDF because I wouldn't want to add syntactic complexity to my documents. Paul Prescod
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > > The idea is to play off of the similarities between objects and REST; > > instance -> resource (noun) > method -> method (verb) > parameters -> parameters / query > return value -> representation > With HTTP the 'parameters' (query strings) aren't separate from the resource identifier. It makes for a nice code framework though. I built something with the same goals a number of years ago (with java in a servlet environment) and found that the system of objects exposed tended to be addressed purely through path segments and the parameters tended to be negotiation things (I wasn't able to use actual headers, as I was operating in a browser client environment) - for example I would put "do:accept=text/xml" in a query term in order to request an xml representation. I like the approach and encourage you to keep on going with your coding. The problem I found was that a lot of server environments didn't nicely support using uri paths segments to acquire 'object request handlers' or 'resource instances'. Another problem was the expectations and attitudes of the programmer community - putting everything into query terms is very popular, because generating URIs is the standard way of doing things - but hopefully this forum will help that issue.
> Mark Baker wrote: > > > > I'm not sure I understand this "two name" problem. > > > > Any relationship between the two should be expressed as an assertion > > someplace. e.g. > > I think my examples were not that great and caused some confusion. The hyperlinking approaches seem to work, and my initial concern about whether all parties would have the full URI or whether they would have only a 'short name' isn't all that worrisome. If the publisher of a product exposes the 'short name', then they could just as easily expose the full uri (but if we can't get them to expose the full uri, what are we to do?). The associations between resources still cause a well-known name to be used - but it is truly a name like 'availability' and not a value like 'blueshoes'. -- http://www.myinventory.foo/products/blueshoes/ -- <product> <availability>http://www.myinventory.foo/products/blueshoes/availability/?wh en=tomorrow</availability> <!-- OR --> <availability>http://www.myinventory.com/services/availablequantity?product= http://www.myinventory.com/product/blueshoe&when=tomorrow</availability> </product> The hyperlinking approach lets the URIs be completely unrelated - they can be 'path based' or 'service based' at the whim of the implementor. The 'coordinating interface' becomes the names used to extract the values from the mass of xml (or rdf or whatever). A question: - what kind of server implementation is required if the portion that emits the 'product info' needs to know the full uri of the portion that deals with 'availability' (it doesn't of course have to be an absolute uri, but whatever the uri looks like, all parts need to be aware of it)? Is there a way to avoid this apparent tight coupling on addressing? Am I missing something here?
On Saturday, April 27, 2002, at 04:11 PM, S. Mike Dierken wrote:
>> instance -> resource (noun)
>> method -> method (verb)
>> parameters -> parameters / query
>> return value -> representation
>>
> With HTTP the 'parameters' (query strings)
and URI parameters!
> aren't separate from the resource
> identifier. It makes for a nice code framework though.
Yes and no, IMHO. Mark went into this in his opacity investigations [1]
a bit. 2396 says:
The query component is a string of information to be interpreted by
the resource.
To me, this indicates that the query has a dual role; it has some
identifying properties in client systems, but the query component is
also interpreted by the resource in server systems.
> The problem I found was that a lot of server environments didn't nicely
> support using uri paths segments to acquire 'object request handlers' or
> 'resource instances'.
True, although I think that by "a lot of server environments," you mean
Java ;)
I haven't worked with ASP for a while; does it have the same problem? It
certainly seems to encourage people to lump all of their code in one
resource, resulting in abominations like
http://www.example.com/scripts/thingy.asp?page=/templates/marketing/fluff.
html
It would be interesting to do a survey of this (including Cold Fusion,
PHP, etc.); I've done surveys [2] of content generation engines in the
past, but my focus has been more on HTTP compliance rather than URI
capabilities. This could probably be done by looking at documentation,
rather than active testing.
> Another problem was the expectations and attitudes of
> the programmer community - putting everything into query terms is very
> popular, because generating URIs is the standard way of doing things -
> but
> hopefully this forum will help that issue.
There's definitely been an interest in REST since the wars on www-tag et
al started; I just wish they weren't quite so negative. However, if it
does the trick...
Thanks!
1. http://www.markbaker.ca/2002/01/UriOpacityInvestigation/
2. http://www.mnot.net/papers/capabilities.html
--
Mark Nottingham
http://www.mnot.net/
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > > On Saturday, April 27, 2002, at 04:11 PM, S. Mike Dierken wrote: > >> instance -> resource (noun) > >> method -> method (verb) > >> parameters -> parameters / query > >> return value -> representation > >> > > With HTTP the 'parameters' (query strings) > > and URI parameters! > Yes, you are right - I'm not familiar with them, but I think I saw a posting by RoyF or somebody that mentioned them. Pretty handy and I'd love to build that into a server dispatching framework. Sometimes my job gets in the way of the work I want to do...
On Sat, Apr 27, 2002 at 01:57:24PM -0700, Paul Prescod wrote: > > <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/> > > Mark uses RDF. I would typically use plain old xml. > > <person> > <clothes href="/current-clothes"/> > ... > </person> > > Of course the virtue of RDF is that it is easily done out-of-line but > IMO, out-of-line declarations are much harder to discover and maintain > (were it otherwise, XML markup itself would be out-of-line). So I would > say that out-of-line declarations are a fallback and inline I would > discriminate against RDF because I wouldn't want to add syntactic > complexity to my documents. I think in-line vs. out-of-line is a red herring. The RDF model can be serialized into many syntaxes to make in-line integration easier. What RDF provides is a generalized assertion model. That means that an RDF client can build up an understanding of a piece of representational state in an incremental manner, rather than the all-or-nothing approach of XML, where you either do or do not understand a schema. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
From: "Mark Nottingham" <mnot@...> > > The problem I found was that a lot of server environments didn't nicely > > support using uri paths segments to acquire 'object request handlers' or > > 'resource instances'. > > True, although I think that by "a lot of server environments," you mean > Java ;) > I haven't worked with ASP for a while; does it have the same problem? It > certainly seems to encourage people to lump all of their code in one > resource, resulting in abominations like > > http://www.example.com/scripts/thingy.asp?page=/templates/marketing/fluff. > html The problem isn't ASP, it's IIS. It doesn't have any convenient means of doing URL rewriting the way that Apache does which is extremely unfortunate. By the way, I've been working on generating code for C# (and the other .NET languages) for RESTful-like web services. I started using Paul's WRDL as the specification language but have since simplified it so that it's easier for one person (me) to tackle. I might be able to release some working examples pretty soon if anybody's interested. Jason
I've just uploaded my WRDL-inspired code generator for .NET [1]. I'm calling it RSDL to avoid any confusion with WRDL. I'm releasing it in the interest of experimentation and discussion not competition. Hopefully something cool will come of it. I've found that it's great for generating RPC-like proxies that only use URIs and HTTP. This isn't exactly the REST Way (and I belive that Mark Baker commented on this a while back) but I'm hoping that it proves more useful as more features are added. I think that using the generated bindings for representations will be especally eye-opening once that's achieved. My next goal is to get it to generate proxies that can work with all three of Paul's Google API operations. After that, there's generating server proxies, support for other target languagues, multiple schema languages, and probably more. Fun stuff, all of it. :-) Jason [1] http://radio.weblogs.com/0101391/2002/04/27.html#a14
> > The problem isn't ASP, it's IIS. It doesn't have any convenient means of > doing URL rewriting the way that Apache does which is extremely unfortunate. I don't know much about IIS, but I don't think I was successful with ASP page of the form: http://www.example.org/path/service.asp/sub-path/ It didn't seem to support 'extra path info'. Whatever.
> I don't know much about IIS, but I don't think I was successful with ASP > page of the form: > http://www.example.org/path/service.asp/sub-path/ > > It didn't seem to support 'extra path info'. Whatever. I didn't have to start using IIS until version 5 so maybe it didn't before. But it does now. The HttpRequest class has a PathInfo property. The problem (to me) is the ".asp" in the middle of the path. IIS uses extensions (and only extensions) to route requests to the appropriate ISAPI DLL. Is it just me or doesn't it seem like Microsoft is afraid of regular expressions? Jason
> I didn't have to start using IIS until version 5 so maybe it didn't before. > But it does now. The HttpRequest class has a PathInfo property. The problem > (to me) is the ".asp" in the middle of the path. IIS uses extensions (and > only extensions) to route requests to the appropriate ISAPI DLL. Is it just > me or doesn't it seem like Microsoft is afraid of regular expressions? Yeah - Sun did the same thing with JSP. It used to work, then it didn't. I might be able to get pathInfo() to work in a JSP if I re-map the URI for the JSP into a servlet (or something) via the config file for that application - but I hate digging through config file formats.
Does this generate client side code only? I only looked at it briefly.
I like it though - especially the part that maps client API methods into
HTTP methods - it bridges the two worlds where programmers want it their
custom way dammit but the architecture wants it a common way or else.
Ultimately I'd like to see a declarative mapping between API constructs and
HTTP messages - the full message with headers, etc available.
Something like the following (but I haven't figured out how to tie API parts
into request-message parts):
<!-- http request definition -->
<requestDef id='AddRequest'>
<http:method>GET</http:method>
<http:Accept>text/xml</http:Accept>
</request>
<!-- standard method/paramter definition stuff -->
<class name='XmlAdder'>
<operation request='AddRequest'>
<name>Add</name>
<param></param>
</operation>
</class>
<!-- sample -->
var adder=new XmlAdder(uri);
adder.Add(5,7);
PS
Take a look at http://xml.apache.org/xang/ for some server side stuff if you
like Java and servlet environments. It has a dispatching framework in there
that uses something like the following (the dispatch() was implemented with
a base class that used reflection to invoke the actual java method):
public interface IHTTPObject
{
// child objects
public IHTTPObject getChild(Vector idPath,int startingOffset);
public void releaseChild(IHTTPObject child);
// method invocation
public boolean dispatch(IHTTPContext context,Vector returnTypes,String
method,Hashtable parameters);
}
Mark Baker wrote:
>
>....
>
> I think in-line vs. out-of-line is a red herring. The RDF model can be
> serialized into many syntaxes to make in-line integration easier.
Yes, that's of course true. Here is why I think of it as in-line versus
out-of-line: I am an XML person and I think that syntax matters. One of
my complaints about SOAP is that it (and XLink, for that matter) is that
it introduces a foreign syntax into XML vocabularies and thus makes them
harder to teach and learn. That impacts their adoption characteristics.
Out-of-line, I can stand RDF's syntax because that is really what it is
optimized for: pointing into resources and making assertions about them.
But inline, I can hardly imagine ever doing this:
<rdf:RDF>
<rdf:Description about="#">
<s:Creator>Ora Lassila</s:Creator>
</rdf:Description>
</rdf:RDF>
Rather than:
<Creator>Ora Lassila</Creator>
I think that this sort of disagreement was behind the RSS conflict and
branch.
Likely the right way to merge the worlds is to have a sort of RDF
stylesheet which maps from XML into the RDF model. I would associate
that with my document through a processing instruction. I believe the
FourThought guys were working on such a technique.
> What RDF provides is a generalized assertion model. That means that an
> RDF client can build up an understanding of a piece of representational
> state in an incremental manner, rather than the all-or-nothing approach
> of XML, where you either do or do not understand a schema.
That's certainly valuable but in my personal opinion, most XML users
will not be willing to pay the price of designing their vocabularies
specifically for RDF compatibility. For instance I much prefer the
syntax of the real WSDL to the one outlined here:
* http://www-106.ibm.com/developerworks/library/ws-rdf/
For one thing, the idea of making one of the top-most elements "rdf:RDF"
rather goes against the design of almost every XML schema language I've
ever seen.
Paul Prescod
Jason, if you're intending to do a Java implementation, you might consider killing two birds with one stone. RSDL seems like a very nice, clean, simple subset of WSDL functionality. One way you could implement the Java binding is to implement WSDL/HTTP support for Axis (which is something I'd really love to have done) and then implement a simple RSDL->WSDL compiler. One benefit of doing it this way is that you could build on all of the nice type binding features in AXIS's WSDL engine. Of course I think the REST crowd needs its own languages but I've come to the realization that even with its limitations, WSDL's HTTP binding is about as powerful (in some ways more powerful) then its SOAP bindings. So we could win people incrementally to REST through it. I think that once they've given up their SOAP safety blanket they will be more open to new architectural ideas. Paul Prescod
"S. Mike Dierken" wrote: > my initial concern about > whether all parties would have the full URI or whether they would have only > a 'short name' isn't all that worrisome. If the publisher of a product > exposes the 'short name', then they could just as easily expose the full uri > (but if we can't get them to expose the full uri, what are we to do?). > > The associations between resources still cause a well-known name to be > used - but it is truly a name like 'availability' and not a value like > 'blueshoes'. The most common way for companies that engage in B2B electronic commerce to communicate product information is by publishing a catalog. It's common for customers to subscribe to the catalog and get periodic updates. The catalog will have URIs for each product. I expect something like 'Business Protocols" to become available soon. By "Business Protocols", I mean the scripts for getting catalogs, availability, ordering, claims, delivery and payment notifications, warranty service, etc. Many of those protocols will become available from libraries from standards groups and industry and trade associations. So "Business Protocols" might be a reference or a list of references to the common protocols a company can handle. So the first thing to do when you want to do business with a new trading partner is to get their business protocols. There is a catalog of common business processes here: http://www.ebxml.org/specs/bpPROC.pdf It contains categorized lists of business processes from EDI, RosettaNet, OAG, etc. Not much detail, just lists. Work is continuing on this catalog - adding more groups, including international trade processes. Executable international trade protocols will open the gates for many people who cannot engage in trade now because of the difficulties of the processes. Scripts for executable business processes are being developed in UN/CEFACT and ISO and several other organizations. For the most part, the scripts assume something like the EDI-mailbox Web service pattern. However, both UN/CEFACT and ISO are trying to be technology- independent, and so their process models should be able to be implemented in REST, at least via some twists. -Bob Haugen
----- Original Message ----- From: "Paul Prescod" <paul@...> > I think that once they've given up their SOAP safety blanket they will be > more open to new architectural ideas. SOAP == "security blanket" ... I love it...
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > The most common way for companies that engage in B2B electronic > commerce to communicate product information is by publishing a > catalog. It's common for customers to subscribe to the catalog and > get periodic updates. The catalog will have URIs for each product. Something that I've run into is that (product) catalogs sometimes have pricing embedded within the catalog - which causes the catalog to be unique to individual receivers - vendors don't have or want uniform pricing across customers. If their process cannot 'normalize' out this information into separate pricing documents then you get a huge amount of mostly redundant information across the system as a whole. And when it gets this big - 60GB per week for 10K customers lets say - then vendors feel they need batch operations, scheduled updates, etc. leading away from a more real-time/low-latency/event-driven message flow. > > I expect something like 'Business Protocols" to become available soon. > I agree with you. I think they will evolve from the coalescing of pockets of use, rather than from standardization organizations though.
From: "S. Mike Dierken" <mdierken@...> > Does this generate client side code only? I only looked at it briefly. Yes, it only generates client proxies at the moment. I have some experimental code working that makes it easy to write a server. It uses reflection to invoke the appropriate methods. I didn't include it in the distribution because I don't really think it's that elegant yet. > I like it though - especially the part that maps client API methods into > HTTP methods - it bridges the two worlds where programmers want it their > custom way dammit but the architecture wants it a common way or else. > > Ultimately I'd like to see a declarative mapping between API constructs and > HTTP messages - the full message with headers, etc available. I was thinking about something like this for the simple reason that query or header names in HTTP can be illegal in the language you're binding to. WRDL has an apiName attribute but I thought that maybe it could be possible to have some sort of configuration file that does the mapping on a per language basis. I really don't want to tie RSDL to any particular methodology (line OO) so I imagine that these configuration files would be on a per tool basis. Jason
Interestingly, XSLT2 allows you to specify a URI to write output documents to [1]. The WD goes to some pains to say that implementations can choose how to support (or not) different schemes, etc. It would be *nice* if it highlighted (or even made a requirement for conditional compliance) support for HTTP through PUT, lest the only support be for file: 1. http://www.w3.org/TR/xslt20/#element-destination -- Mark Nottingham http://www.mnot.net/
On Sun, 2002-04-28 at 02:03, Paul Prescod wrote: > Mark Baker wrote: > > > >.... > > > > I think in-line vs. out-of-line is a red herring. The RDF model can be > > serialized into many syntaxes to make in-line integration easier. > > Yes, that's of course true. Here is why I think of it as in-line versus > out-of-line: I am an XML person and I think that syntax matters. One of > my complaints about SOAP is that it (and XLink, for that matter) is that > it introduces a foreign syntax into XML vocabularies and thus makes them > harder to teach and learn. That impacts their adoption characteristics. > > Out-of-line, I can stand RDF's syntax because that is really what it is > optimized for: pointing into resources and making assertions about them. > But inline, I can hardly imagine ever doing this: > > <rdf:RDF> > <rdf:Description about="#"> > <s:Creator>Ora Lassila</s:Creator> > </rdf:Description> > </rdf:RDF> > > Rather than: > > <Creator>Ora Lassila</Creator> > > I think that this sort of disagreement was behind the RSS conflict and > branch. > > Likely the right way to merge the worlds is to have a sort of RDF > stylesheet which maps from XML into the RDF model. I would associate > that with my document through a processing instruction. I believe the > FourThought guys were working on such a technique. > > > What RDF provides is a generalized assertion model. That means that an > > RDF client can build up an understanding of a piece of representational > > state in an incremental manner, rather than the all-or-nothing approach > > of XML, where you either do or do not understand a schema. > > That's certainly valuable but in my personal opinion, most XML users > will not be willing to pay the price of designing their vocabularies > specifically for RDF compatibility. For instance I much prefer the > syntax of the real WSDL to the one outlined here: > > * http://www-106.ibm.com/developerworks/library/ws-rdf/ Quite dated, this is. I wrote it back in 2000, before I came to the same conclusion as you have: that it's more important to have mapping features from XML to RDF than to squeeze everything into RDF syntax. > For one thing, the idea of making one of the top-most elements "rdf:RDF" > rather goes against the design of almost every XML schema language I've > ever seen. You might, then, want to check out the updated article: http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Unfortunately, there is a bug in this article I've reported to the editor. An XInclude I used did not get expanded. You'll know what I mean if you read the article. If so, here's the link you want: http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt Might I also suggest my similar discussion WRT SOAP: http://www-106.ibm.com/developerworks/webservices/library/ws-soaprdf/ -- Uche Ogbuji Fourthought, Inc. uche.ogbuji@... http://fourthought.com http://4Suite.org http://uche.ogbuji.net Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
"S. Mike Dierken" wrote: > Something that I've run into is that (product) catalogs sometimes have > pricing embedded within the catalog - which causes the catalog to be unique > to individual receivers - vendors don't have or want uniform pricing across > customers. If their process cannot 'normalize' out this information into > separate pricing documents then you get a huge amount of mostly redundant > information across the system as a whole. An excellent point. Have you seen anybody do this normalization? How did it work out? > > I expect something like 'Business Protocols" to become available soon. > > > I agree with you. I think they will evolve from the coalescing of pockets of > use, rather than from standardization organizations though. I expect both of us are right. Here is some of my evidence for organizations working on common business protocols: * RosettaNet - electronics * CIDX, chemical, adopted a lot of RNet * PIDX, petroleum, adopting CIDX * agXML, agriculture, adopting CIDX * ebXML - took lots of ideas from RNet * RNet now adopting at least some of ebXML * AIAG, automotive, has previous X12 EDI standards, now adopting ebXML * HIPAA, health care, US government mandate * Travel (org?), adopting some of ebXML and also their own standards * UCC, retail, somewhat like travel * Telecom (org?), precursor to some of RNet One point being that there is a lot of overlap and cross-referencing between orgs. And whole bodies of commercial law and business customs underly all of these protocols. Many of these people do understand that "code rules" and so are attempting to codify legal business practices. And then some big companies like McDonalds and Walmart constitute their own little universes... Another point being that you could make up your own business protocols, but be aware you are planting in a field where a big gang plow is coming. It won't be as neat as the standards and industry orgs and big companies like, but in many cases, you will be required to follow some standardized protocol in order to do business.
On Sun, Apr 28, 2002 at 01:03:30AM -0700, Paul Prescod wrote: > Yes, that's of course true. Here is why I think of it as in-line versus > out-of-line: I am an XML person and I think that syntax matters. I think syntax matters too. That's why I'm not an XML person. 8-) > One of > my complaints about SOAP is that it (and XLink, for that matter) is that > it introduces a foreign syntax into XML vocabularies and thus makes them > harder to teach and learn. That impacts their adoption characteristics. > > Out-of-line, I can stand RDF's syntax because that is really what it is > optimized for: pointing into resources and making assertions about them. > But inline, I can hardly imagine ever doing this: > > <rdf:RDF> > <rdf:Description about="#"> > <s:Creator>Ora Lassila</s:Creator> > </rdf:Description> > </rdf:RDF> > > Rather than: > > <Creator>Ora Lassila</Creator> Sure, but there's more information available in the former case. If the XML is going to be processed by a machine anyways, why is the latter approach any better? I suppose if it were hand authored, but is that what we're talking about here? Also, I think the XML syntax for the RDF model is a horrible, nasty, unnecessary thing. It should be killed. > I think that this sort of disagreement was behind the RSS conflict and > branch. > > Likely the right way to merge the worlds is to have a sort of RDF > stylesheet which maps from XML into the RDF model. I would associate > that with my document through a processing instruction. I believe the > FourThought guys were working on such a technique. I've heard talk of adorning schemas with the information necessary to construct RDF. I like this in theory, though I fear for the practical implications; primarily, additional network round-trips. > > What RDF provides is a generalized assertion model. That means that an > > RDF client can build up an understanding of a piece of representational > > state in an incremental manner, rather than the all-or-nothing approach > > of XML, where you either do or do not understand a schema. > > That's certainly valuable but in my personal opinion, most XML users > will not be willing to pay the price of designing their vocabularies > specifically for RDF compatibility. For now, that's clearly true. As more RDF features are integrated into tools, the cost of doing this will come down. > For one thing, the idea of making one of the top-most elements "rdf:RDF" > rather goes against the design of almost every XML schema language I've > ever seen. True, but I consider XML schema and other languages at that level, to be transitional technologies. rdf:RDF (or something equivalent) will the be the root element for a whole lot of content in a few years. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Uche Ogbuji wrote: > >... > You might, then, want to check out the updated article: > > http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ > > Unfortunately, there is a bug in this article I've reported to the > editor. An XInclude I used did not get expanded. You'll know what I > mean if you read the article. Yeah, it seems as if you're making some kind of joke. Look: it's only one line! If so, here's the link you want: > http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt Typo in that URI (localhost) but I figured it out. Still doesn't really meet my requirements so I'll wait for more information on "document definitions" or whatever else you are working on. For instance the root namespace in this document is rdf:RDF which is not going to be acceptable to XML people! Maybe I'm unreasonable, but I'm looking for the total content of the RDF stuff in my document to be: <?rdf-metadata-mapping href=""?> I would even be satisfied to put the RDF stuff in my XML or RELAX schema. Paul Prescod
There are a lot of interesting presentations at that XML Europe convention (from a link from your mail) This one looks interesting, as it might be an additional implementation of the REST architectural style: Thursday, 23 May 11.00 Technical View XML Spaces - Beyond Web Services Presented by: Patrick Thompson, Chief Architect, Rogue Wave Software, United States XML Spaces is a new communication paradigm that brings together tuple spaces, XML, the Internet, security, and web services to create a simple yet powerful substrate for rich document exchange. XML Spaces extends the web services model with looser coupling, abstract addressing, asynchrony, arbitrary XML support, many-to-many interactions and document level security. XML Spaces supports ad-hoc collaboration seamlessly within an organization or across the Internet. The presenter will introduce the technology and describe how it can be applied to a wide variety of applications. ----- Original Message ----- From: "Uche Ogbuji" <uche.ogbuji@...> > XML, The Model Driven Architecture, and RDF @ XML Europe - > http://www.xmleurope.com/2002/kttrack.asp#themodel >
On Mon, Apr 29, 2002 at 09:48:22AM -0700, S. Mike Dierken wrote: > This one looks interesting, as it might be an additional implementation of > the REST architectural style: Well, I think it's a huge stretch to claim that a tuple space architecture is REST. There are definitely some similarities between the two styles, including the biggies (generic interface, operates on things with identity), but there's a lot of important differences. Stuff like definition of identity not very general, focus on APIs instead of protocols (so no streams), etc.. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Nottingham wrote: > > Interestingly, XSLT2 allows you to specify a URI to write output > documents to [1]. The WD goes to some pains to say that implementations > can choose how to support (or not) different schemes, etc. > > It would be *nice* if it highlighted (or even made a requirement for > conditional compliance) support for HTTP through PUT, lest the only > support be for file: That's an excellent idea! Do you want to contact Michael Kay or should I or what? What should be done about POST? If we need to choose just one of the two, POST is actually more compatible with deployed infrastructure though PUT is more inline with "overwrite" semantics. Pragmatically I would have to go with POST. Paul Prescod
On Mon, Apr 29, 2002 at 01:03:46PM -0700, Paul Prescod wrote: > What should be done about POST? If we need to choose just one of the > two, POST is actually more compatible with deployed infrastructure > though PUT is more inline with "overwrite" semantics. > > Pragmatically I would have to go with POST. The operation is semantically identical to PUT, so why use POST? There's idempotence issues too, of course; a script author expects overwrite, so they should get it. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
This time, including the group. Begin forwarded message: From: Mark Nottingham <mnot@...> Date: Mon Apr 29, 2002 01:20:04 PM US/Pacific To: Paul Prescod <paul@...> Subject: Re: [rest-discuss] XSLT2 I'll be happy to if we can come to some sort of consensus here. Is PUT really that much of an issue? The only issue that I can see is that in some situations, it may be easier to drop in a CGI POST hander that allows you to direct the result to a particular location; PUT requires some sort of handler on the server side (e.g., a module or a script that stores and retrieves the state). I'd much rather see PUT used, as I think it's a good way to broaden support for full PUT/DELETE, but I can certainly see that there would be initial pushback. Does anyone know if it's possible, and how difficult it is, to support PUT on ISS (any version)? I'd say support both, but that would require an attribute to select the method. On Monday, April 29, 2002, at 01:03 PM, Paul Prescod wrote: > Mark Nottingham wrote: >> >> Interestingly, XSLT2 allows you to specify a URI to write output >> documents to [1]. The WD goes to some pains to say that implementations >> can choose how to support (or not) different schemes, etc. >> >> It would be *nice* if it highlighted (or even made a requirement for >> conditional compliance) support for HTTP through PUT, lest the only >> support be for file: > > That's an excellent idea! Do you want to contact Michael Kay or should I > or what? > > What should be done about POST? If we need to choose just one of the > two, POST is actually more compatible with deployed infrastructure > though PUT is more inline with "overwrite" semantics. > > Pragmatically I would have to go with POST. > > Paul Prescod > -- Mark Nottingham http://www.mnot.net/
Mark Baker wrote: > >... > > The operation is semantically identical to PUT, so why use POST? > There's idempotence issues too, of course; a script author > expects overwrite, so they should get it. I agree that PUT is the right thing semantically. The only reason I consider POST is because if a person designs a web service without specifically taking into a account either REST or XSLT that service is likely to accept POST, not PUT. PUT isn't supported by either HTML or WSDL, so the GET/POST have become a popular pair! I suppose I would still end up going over to the PUT side because if XSLT will just ignore the result of the POST then it will be incompatible with may POST-based services anyhow. Paul Prescod
Why not suggest a method attribute for the xsl:result-document element? Then you could use either one. Jason ----- Original Message ----- From: "Paul Prescod" <paul@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, April 29, 2002 1:03 PM Subject: Re: [rest-discuss] XSLT2 > Mark Nottingham wrote: > > > > Interestingly, XSLT2 allows you to specify a URI to write output > > documents to [1]. The WD goes to some pains to say that implementations > > can choose how to support (or not) different schemes, etc. > > > > It would be *nice* if it highlighted (or even made a requirement for > > conditional compliance) support for HTTP through PUT, lest the only > > support be for file: > > That's an excellent idea! Do you want to contact Michael Kay or should I > or what? > > What should be done about POST? If we need to choose just one of the > two, POST is actually more compatible with deployed infrastructure > though PUT is more inline with "overwrite" semantics. > > Pragmatically I would have to go with POST. > > Paul Prescod > > Yahoo! Groups Sponsor > ADVERTISEMENT > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > >
On Mon, Apr 29, 2002 at 01:20:57PM -0700, Mark Nottingham wrote: > I'd say support both, but that would require an attribute to select the > method. Using POST is entirely different function. You're no longer producing a document, you're producing a message. I'm not convinced that a POST mechanism is desirable, but if somebody wants to suggest that, I'd *STRONGLY* recommend defining a new element, not an attribute on xsl:result-document. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Ah, but that's the interesting part - this is an argument for both PUT and POST support, with POST using a separate element (as Mark suggests); it allows you to represent the result of the POST in the XSLT for further processing; you might get XML back, which can be represented (bad word to use) as a result tree, you might get back a URI for a Content-Location, etc. This would allow you to do some pretty sophisticated coordination with XSLT... P.S. There should really be a REST IRC channel... On Monday, April 29, 2002, at 01:24 PM, Paul Prescod wrote: > Mark Baker wrote: >> >> ... >> >> The operation is semantically identical to PUT, so why use POST? >> There's idempotence issues too, of course; a script author >> expects overwrite, so they should get it. > > I agree that PUT is the right thing semantically. The only reason I > consider POST is because if a person designs a web service without > specifically taking into a account either REST or XSLT that service is > likely to accept POST, not PUT. PUT isn't supported by either HTML or > WSDL, so the GET/POST have become a popular pair! > > I suppose I would still end up going over to the PUT side because if > XSLT will just ignore the result of the POST then it will be > incompatible with may POST-based services anyhow. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > -- Mark Nottingham http://www.mnot.net/
XSLT2 allows you to specify a URI to write output documents to [1]. The current WD goes to some pains to say that implementations can choose how to support (or not) different schemes, etc. However, considering recent discussion on www-tag re: REST, the Web, interoperability, etc., it would be nice if it highlighted (or even made a requirement for conditional compliance) support for HTTP through PUT, lest the only support be for "file" URIs. Has this been discussed in the WG? Regards, 1. http://www.w3.org/TR/xslt20/#element-destination -- Mark Nottingham http://www.mnot.net/
That makes sense. Let's see what they come back with. On Monday, April 29, 2002, at 01:40 PM, Mark Baker wrote: > On Mon, Apr 29, 2002 at 01:20:57PM -0700, Mark Nottingham wrote: >> I'd say support both, but that would require an attribute to select the >> method. > > Using POST is entirely different function. You're no longer producing > a document, you're producing a message. I'm not convinced that a POST > mechanism is desirable, but if somebody wants to suggest that, I'd > *STRONGLY* recommend defining a new element, not an attribute on > xsl:result-document. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com > -- Mark Nottingham http://www.mnot.net/
Mark Nottingham wrote: > > Ah, but that's the interesting part - this is an argument for both PUT > and POST support, with POST using a separate element (as Mark suggests); Now we're talking about going from saying: "please support HTTP" to "please add these HTTP-specific features to the language". I don't think it would fly. Maybe if we asked them to "please support SOAP over HTTP POST in XSLT." ;) I'm pretty sure IIS supports PUT. The method name is just a paramater on the "HttpRequest" object, otherwise it doesn't care much. One small issue is that the default security configuration probably allows GET,POST, not GET,PUT,POST. Paul Prescod
Okay - you are probably right. I don't know what a tuple space is - I've only read one paper from RogueWave's site - but several times people have compared HTTP/REST with tuple spaces... so I thought it relevant. I didn't mean to categorically claim tuplespaces === REST. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "S. Mike Dierken" <mdierken@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, April 29, 2002 11:57 AM Subject: Re: [rest-discuss] XML Spaces - another implementation of REST over networks? > On Mon, Apr 29, 2002 at 09:48:22AM -0700, S. Mike Dierken wrote: > > This one looks interesting, as it might be an additional implementation of > > the REST architectural style: > > Well, I think it's a huge stretch to claim that a tuple space > architecture is REST. There are definitely some similarities between > the two styles, including the biggies (generic interface, operates on > things with identity), but there's a lot of important differences. > Stuff like definition of identity not very general, focus on APIs > instead of protocols (so no streams), etc.. > > MB > -- > Mark Baker, Chief Science Officer, Planetfred, Inc. > Ottawa, Ontario, CANADA. mbaker@... > http://www.markbaker.ca http://www.planetfred.com >
Sjoerd Visscher suggests (at http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a lot of rules of both functional and object oriented programming", because it has "a small API" (presumably referring to GET, POST, PUT as the REST API). I'm not convinced that REST's reliance on HTTP primitives necessarily restricts flexibility of function. I'd really like to see an example of something useful that can be expressed in SOAP style much more clearly than in REST style. -Jason
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----- Original Message ----- From: "Mark Baker" <distobj@...> > > Well, I think it's a huge stretch to claim that a tuple space > architecture is REST. There are definitely some similarities > between the two styles, including the biggies (generic interface, > operates on things with identity), but there's a lot of important > differences. Stuff like definition of identity not very general, > focus on APIs instead of protocols (so no streams), etc.. Mark, what did you mean by no streams in tuplespaces? Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPM54UeaWiFwg2CH4EQKn5ACg2NkH9mpqOK0uKMhs3GZh5wYwSTEAnivn Aa1A5mgPL8TwT5twKRabBcUd =3C6i -----END PGP SIGNATURE-----
On Tue, Apr 30, 2002 at 04:19:38AM -0000, jmay wrote: > Sjoerd Visscher suggests (at > http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a > lot of rules of both functional and object oriented programming", > because it has "a small API" (presumably referring to GET, POST, PUT > as the REST API). Yah, I saw that. I have my own opinions on that claim, but really, my response is "So what?". The criteria with which one evaluates a distributed architecture is *entirely* different than the criteria with which a software program is evaluated. > I'm not convinced that REST's reliance on HTTP primitives Isn't that the other way around? 8-) > necessarily restricts flexibility of function. I'd really like to > see an example of something useful that can be expressed in SOAP > style much more clearly than in REST style. You and me both! MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
On Tue, Apr 30, 2002 at 11:56:18AM +0100, Bill de h�ra wrote: > Mark, what did you mean by no streams in tuplespaces? That a tuple is of fixed size. So you can't use a space to identify a large number resources whose representations can be streams. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > > On Tue, Apr 30, 2002 at 11:56:18AM +0100, Bill de hra wrote: > > Mark, what did you mean by no streams in tuplespaces? > > That a tuple is of fixed size. So you can't use a space to > identify a large number resources whose representations can > be streams. Thanks Mark, I may get back you about this, I take your point for now. (I'm surprised you could even read my post; convert to html dutifully turned off) Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPM6FluaWiFwg2CH4EQKocgCggmf/LGB53NFTWq7kQpT86Z04jgUAniOX aYERlD+EkGKxEup4mK+izoUd =8Z6x -----END PGP SIGNATURE-----
On Mon, 2002-04-29 at 23:19, jmay wrote: > Sjoerd Visscher suggests (at > http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a > lot of rules of both functional and object oriented programming", > because it has "a small API" (presumably referring to GET, POST, PUT > as the REST API). It certainly does violate a lot of "rules" of OOP: the focus on composition of generic interfaces is the antithesis of OOP's type-specific interfaces and encapsulation. OTOH, I'm not sure that it's incompatible with functional programming in any real sense. Like functional programming, the focus is on composition. Resources, like monads, hide state --- any given interaction is stateless in some sense. These are just a couple of obvious parallels; it's an interesting question, though, and I would suggest that the similarity is much deeper than it might appear at first glance. (In fact, my own as-yet unfruitful efforts to formally demonstrate certain things about the complexity of REST-like vs. OOP systems relies on a certain functional model of REST; one of these days, maybe hopefully, that investigation will be ready for prime time. :-) BTW, let's be careful not to facilely and incorrectly assume that REST being "incompatible" with OOP says anything negative about REST; indeed, I'm beginning to think that there are several research and engineering trends converging towards a recognition that OOP doesn't give us what we wanted in terms of re-use, maintainability, etc.... jb
Thanks for the comment. I think it's hard for us to be prescriptive about this. An XSLT processor designed solely for use on TV set-top-boxes might have no market requirement (or technical possibility) to write output to an HTTP PUT destination, nor indeed to anywhere other than the TV screen. We want language interoperability, but we can't assume that all processors execute in the same kind of environment. I don't mind, however, putting in some kind of note giving examples of the sorts of URI that permit writing. Michael Kay > -----Original Message----- > From: Mark Nottingham [mailto:mnot@...] > Sent: 29 April 2002 21:36 > To: xsl-editors@... > Cc: rest-discuss@yahoogroups.com > Subject: XSLT2.0 and HTTP-PUT > > > XSLT2 allows you to specify a URI to write output documents > to [1]. The > current WD goes to some pains to say that implementations can choose > how to support (or not) different schemes, etc. > > However, considering recent discussion on www-tag re: REST, the Web, > interoperability, etc., it would be nice if it highlighted > (or even made > a requirement for conditional compliance) support for HTTP > through PUT, > lest the only > support be for "file" URIs. > > Has this been discussed in the WG? > > Regards, > > > 1. http://www.w3.org/TR/xslt20/#element-destination > > -- > Mark Nottingham > http://www.mnot.net/ > >
Jeff Bone wrote: > > On Mon, 2002-04-29 at 23:19, jmay wrote: > > Sjoerd Visscher suggests (at > > http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a > > lot of rules of both functional and object oriented programming", > > because it has "a small API" (presumably referring to GET, POST, PUT > > as the REST API). > > It certainly does violate a lot of "rules" of OOP: the focus on > composition of generic interfaces is the antithesis of OOP's > type-specific interfaces and encapsulation. On the other hand, I think the consensus of OOP practitioners who have developed large distributed object systems (or even heavily layered systems) is toward something more RESTful than "classic OOP" with lots of little methods. By that I mean whenever you cross boundaries (distributed, trust, even processes), larger granularity is better than small. I.e. use facades at boundary crossings and pass back and forth large- grained representations of a composite object behind the facade. I.e. use URIs to identify resources and pass representations of their state around. I am certain that the SOAP RPC programmers will learn this from sad experience over time. Selections on related topics from WikiWiki: http://c2.com/cgi/wiki?DomainObjectStateHolder http://c2.com/cgi/wiki?BagOfJumpingBeans http://c2.com/cgi/wiki?DataTransferObject http://c2.com/cgi/wiki?HalfObjectPlusProtocol -Bob Haugen
----- Original Message ----- From: "jmay" <jmay@...> > Sjoerd Visscher suggests (at > http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a > lot of rules of both functional and object oriented programming", > because it has "a small API" (presumably referring to GET, POST, PUT > as the REST API). I think this is in reference to: "Translated to programming terms it is like having a huge set of global variables (the state of the program) which are read and written directly." This is not what REST says. There are 'lots of nouns, few verbs' but you still go through interfaces to make any changes - you just style things to reuse simple interfaces. REST is more about state transfer across large scale applications than an API approach that uses generic local object interfaces. There are similarities between distributed state-exchaning applications and 'programming with interfaces' - but they shouldn't be equated.
"Kay, Michael" wrote: > > Thanks for the comment. I think it's hard for us to be prescriptive about > this. An XSLT processor designed solely for use on TV set-top-boxes might > have no market requirement (or technical possibility) to write output to an > HTTP PUT destination, nor indeed to anywhere other than the TV screen. We > want language interoperability, but we can't assume that all processors > execute in the same kind of environment. > > I don't mind, however, putting in some kind of note giving examples of the > sorts of URI that permit writing. Speaking for myself, I would be very happy with a non-normative note that would get across the point (in appropriate spec-ese) that HTTP is in fact a bidirectional protocol and that it would make just as much sense to PUT to an HTTP URI as to a file system path. If at all possible, please use the word "PUT" (if even in a non-normative example) so that we have a chance of interoperability among implementations. (there will be a tempation to use the more popular "POST" even though it does not have the same "overwrite file" semantic). Something like: "For example writing to a file://... URI would overwrite a file. Writing to an http://... URI would invoke the HTTP PUT method." Paul Prescod
Sam says: > I've been doing some reading on REST. I'm not convinced that REST > dictates GET. Here are three quotes from Roy Fielding, the > "inventor" of REST: > > REST is an architectural style -- it does not dictate protocol syntax. > There's no basis for "everything must use GET" in Web architecture. > there is a trade-off between GET and POST that usually involves the > size of the parameter content. > > I'm now convinced that one can architect a system in accordance > to the principles of REST and then implement that system using > RPC style, HTTP transport, POST binding, SOAP. http://radio.weblogs.com/0101679/2002/04/28.html#a414 I think that most REST fans would agree this far. You *could* architect a system according to these principles. After all, SOAP is just a syntax. But if the relevant specifications do not encourage or require this, then you will have no interoperability with someone else who happens also to have read Roy's thesis but, for instance, to have called his "GET" method "fetch" and his "PUT" method "chuck." And furthermore, the WAY you say "where to get from" and "where to put to" will be non-standard: SOAP does not encourage nor require you to use URIs as resource identifiers. HTTP is a *standard* way of doing REST over the Internet. Now of course we could reinvent REST-on-the-Internet in SOAP syntax two layers above HTTP but it seems a little bit ridiculous to me. A better strategy is to use SOAP as an extension to HTTP that adds the features HTTP lacks. > ... In fact, I'll go > further and state that the GoogleSearch is an instance of this. I disagree. Here are the four principle ideas of REST: 1. identification of resources; Google does not identify resources explicitly. I had to infer that every method/parameter combination was a resource. Then I built a layer that identified each of those URIs through the Web's addressing mode: URIs. 2. manipulation of resources through representations; SOAP has no concept of either resources or representations and the Google API certainly did not add them! 3. self-descriptive messages; Okay, I'll concede this: SOAP may be ugly but its not quite binary! Still on a scale of 1 to 10, the HTTP version wins! But more important, the HTTP version is self-descriptive to *any HTTP intermediary* including a cache or proxy. The SOAP version is self-descriptive only to intermediaries trained to expect the particular method names. 4. and, hypermedia as the engine of application state In order to shorten the article, I left out a couple of paragraphs with examples of ways that Google *could* have used hypertext as the engine of application state. "For instance, imagine if the search API returned a URI to the cached page, just as it does in the HTML version of Google. I could declare in WRDL (as opposed to WSDL) that the cachedPage element of searchResult resources points to a document of type text/html. I could also define a resource type for Google "directory catalogs", then I could declare strong types (XML namespaces or schemas) for the links from search results to the directory catalogs and back. WRDL is designed (okay, being designed) to mirror the structure of the Web, rather than impose a component-oriented view on top of it." It would be great to have bidirectional links from the Google XML repository to the Open Directory XML repository! It would take much more effort to do the thing with SOAP and it would not scale as well to several directory services (with potentially varying APIs) and several search engines (with potentially varying APIs). I've documented the technical weaknesses of the Google solution. In particular, nothing is addressable and that makes it incompatible with any tool that can only work with addressable information. The ones I happened to mention will probably elicit a yawn from the SOAP crowd (XSLT -- so 1999) but the more important point is that any other web service that wants to interoperate with Google will have to explicitly hard-code those three methods instead of "just knowing" that a URI is sufficient to get information out. I didn't mention REST in the article because I think that we make more progress when we approach from a concrete technical point of view. Plus, I suspect Roy is getting sick of the REST hype. Paul Prescod
jmay wrote: > > Sjoerd Visscher suggests (at > http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a > lot of rules of both functional and object oriented programming", > because it has "a small API" (presumably referring to GET, POST, PUT > as the REST API). I'll repeat what others have said: comparing OO and REST is comparing apples and elephants. One is about building networked systems that cross organizational boundaries and integrate well with other systems. The other is about building individual programs so that they are robust and extensible. Also: I've never seen a deployed SOAP web service that was even remotely "object oriented" so even if that adjective applied, we'd have to compare REST to CORBA or DCOM, not SOAP. And functional? I'm trying hard to imagine how you'd make a "functional" web service without making it useless! Paul Prescod
If you found that weblog entry interesting, I'm sure that you will enjoy this one: http://www.oreillynet.com/cs/weblog/view/wlg/1351 - Sam Ruby
On 2002-04-30 07:05 PM, "Sam Ruby" <rubys@...> wrote: > If you found that weblog entry interesting, I'm sure that you will enjoy > this one: > > http://www.oreillynet.com/cs/weblog/view/wlg/1351 Sam, I am sincerely disappointed in this misleading characterization of REST. If it stems from just not knowing about the issues, then I hope that you'll correct the article. While REST per se may not require to HTTP GET, the TAG has a draft finding that does. Meanwhile, REST requires many other things for HTTP compatibility which SOAP does not provide. As Roy Fielding has stated on the TAG list, the key things SOAP needs to do is: - use proper HTTP response codes - use different URIs for each object - use proper cache-control headers To say that pure query interfaces with no side effects meet [REST] criteria. Even if they use HTTP POST." is at best misleading and at worst false. I'm sure others on the list can expand further. -- [ "Aaron Swartz" ; <mailto:me@...> ; <http://www.aaronsw.com/> ]
On Tue, Apr 30, 2002 at 08:05:14PM -0400, Sam Ruby wrote: > If you found that weblog entry interesting, I'm sure that you will enjoy > this one: > > http://www.oreillynet.com/cs/weblog/view/wlg/1351 Sam, really, you need more than "a few days" to grok REST, especially when you're likely used to seeing the world through RPC tained eyes. It took me about three years to really get a solid grasp of it, and I have a lot of experience in distributed systems theory and practice. You also took Roy's comments completely out of context. Yes, you do not need to use GET to be using REST. But that means you can't retrieve things (unless you want to do that ugly hack that Paul talked about), which I'm sure you'd agree is useful. If you're only using POST, then all you can do is EDI; send a document for processing, never knowing how it impacted the state of the system. You might want to try incorporating some more of his words into your next article; "The problem with SOAP is that it tries to escape from the Web interface. It deliberately attempts to suck, mostly because it is deliberately trying to supplant CGI-like applications rather than Web-like applications." "This bears repeating: The difference between an application-level protocol and a transport-level protocol is that an application-level includes application semantics, by standard agreement, within the messages that the protocol transfers. That is why HTTP is called a Transfer protocol. It is impossible to conform to an application-level protocol without also conforming faithfully to its message semantics." "As a *separate* issue, Web Services cannot be considered an equal part of the Web until they allow their own resources to become interconnected with the rest of the Web. That means using URI to identify all important resources, even if those URI are only used via non-SOAP mechanisms (such as a parallel HTTP GET interface) after the SOAPified processing is complete." Please, feel free to ask us any questions. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
ARRGGHHH!!!
[mailed and posted: http://www.oreillynet.com/cs/user/view/cs_msg/7147] I'm not convinced that it is productive to do a point-by-point argument against the weblog. If you want to discuss REST then I think a mailing list is a more productive way to do it. We could make a whole new one if you want an "even ground" or "decentralization" might be an interesting place. So I won't go through point by point and just try to re-emphasize the central point of my article. Yes, I exaggerated the seriousness of Google's crime because I'm trying to motivate action rather than just dryly analyze. But Google's "crime" is that they deprived the Web of approximately a billion useful XML URIs. We could have used those URIs in XInclude, XSLT, XPath, XPointer, RDF. And of course we could ALSO have used them in Java, Perl, Python, C#, Ruby, ... URIs are declarative, like SQL. You type them in and declarative data comes back. Just as you can type SQL in a little one-line window and get back records, you can type a URI in a little one-line window and get back representations of resources. Just as you can integrate tables using joins, you integrate XML/URI-based web services using XInclude and RDF. Before the relational model (and query language) was widely circulated, the whole concept would have seemed ridiculous to database programmers. You could just use the "API" (surely not the terminology they used back then, but...). You want to integrate two tables...you write some code that iterates over one and the other and correlates them. As long as you like coding glue, and don't care about scalability, this is a great system! It took years for people to understand the subtle benefits of a system that is consistent but also very restrictive. That's where we are today, with Web Services and REST. Precisely because the issues are subtle, we have to yell loud to be heard. In particular, the fundamental benefit of publishing through URIs is interoperability: * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0286.html * http://www.xml.com/pub/a/2002/02/06/rest.html Until there is more than one useful web service on the Internet, it's really hard to demonstrate interoperability advantages... Paul Prescod
[mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7148] > > I'm not convinced that it is productive to do a point-by-point > argument against the weblog. If you want to discuss REST > then I think a mailing list is a more productive way to do it. Perhaps we could have a F2F discussion at the ETCON? Want to schedule a BOF? I hear that Nelson Minar is going to be there... I'd love to find some common ground and jointly author some recommendations on the subject... - Sam Ruby
Huh? Their genius was in recoginizing that "content is king" and they've got the content - and the poor schmucks trolling for something interesting to do with SOAP would jump on a dressed up GET request and provide them a quick marketing buzz. Can't wait for the AOL boyz to hand out the free SOAP API to retrieve content from their pay-to-play network... imagine where CompuServe and Prodigy would be today if they had something like SOAP to affect their reach... > Google's Genius? > To pick a wire format for which there are dozens of toolkits poised to directly translate the protocol into readily consumable bits. How many toolkits can do HTTP GET? Correctly? Why would a stream of XML from a response to a GET be less readily consumable? > To directly test interop against a small but diverse set of platforms. You don't need SOAP to do that. > To provide early access to an undisclosed number of other interested parties. They had an HTTP API that provided XML via GET - but you had to pay to play. If they open that one up, you'd get just as many people incorporating it into products as the SOAP API. > To provide a sample that runs on wide range of operating systems and instruction set architectures. Uh, so does HTTP? > To document the wire protocol adequately, including all the optional type annotations. > And to provide sufficient metadata, in the form of WSDL, so that a large number of developers can be instantly up and running. Don't know how to do that in pure HTTP - that's a missing piece. Not enough to through out the baby with the bathwater though. ----- Original Message ----- From: "Sam Ruby" <rubys@...> To: "Paul Prescod" <paul@...> Cc: <rest-discuss@yahoogroups.com> Sent: Tuesday, April 30, 2002 5:05 PM Subject: [rest-discuss] Re: GoogleAPI is Rest? > If you found that weblog entry interesting, I'm sure that you will enjoy > this one: > > http://www.oreillynet.com/cs/weblog/view/wlg/1351 > > - Sam Ruby > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
On Tue, 30 Apr 2002, Asynch Messaging wrote: > > And to provide sufficient metadata, in the form of WSDL, so that a large > > number of developers can be instantly up and running. > Don't know how to do that in pure HTTP - that's a missing piece. Not enough > to through out the baby with the bathwater though. There are a bunch of missing pieces. WSDL for HTTP resources needs to happen. Work on event models needs to get finished. Maybe store and forward (the email workalike we discussed here a few months ago) needs to happen. SOAP-RPC already offers solutions to all of the above. They're not as good as HTTP solutions could be but at least they're out there. Until the REST stack gets filled out to the same degree as the XML RPC stack, we are in ivory tower land. - Lucas
In <http://www.oreillynet.com/cs/weblog/view/wlg/1351>, Sam Ruby writes: > Google's Genius? To pick a wire format for which there are dozens > of toolkits poised to directly translate the protocol into readily > consumable bits. Agreed. I've seen way too many XML apps traipse through raw DOMs picking out their data. Getting the your data in readily consumable bits is a great service. Is the huge amount of SOAP infrastructure a means to simply get data in readily consumable bits? What if RESTful toolkits with marshalling code were common. Where would we be in discussing the architectural styles between <that which SOAP generally exhibits but which has no name*> and REST? In simple implementations, like XML-RPC, marshalling is about half of the implementation with procedure call semantics the other half. Creating an HTTP request library that just marhsalls data should be that much simpler than one that relays calls. -- Ken * I don't think of this as a SOAP vs. REST debate per se, maybe we can come up with a better term for the SOAP style than "that which is not REST but is like messaging or RPC".
On Tue, 2002-04-30 at 18:43, Paul Prescod wrote:
>
> And functional? I'm trying hard to imagine how you'd make a "functional"
> web service without making it useless!
That's a failure of imagination. ;-) Seriously, the parallels are quite
significant. In effect, URIs are generic functions that dispatch on
message, parameter, conneg and other headers to a fixed set of
functions, i.e. the supported HTTP method implementations. The abstract
resource itself can be regarded as a monad that encapsulates the
side-effecting state changes on e.g. PUT and POST. The various pieces
of input ("parameters", headers) define the domain of the specific
function and the set of possible representations associated with that
function is the codomain / range.
That may stretch the way you think of "functional", but it works quite
well. With a bit more formality and rigor in these definitions it
becomes possible to begin talking about Web interactions using a
compositional algebra, and you can reason about Web architecture using
the tools of category theory.
jb
On Wed, May 01, 2002 at 09:34:09AM -0400, Lucas Gonze wrote: > There are a bunch of missing pieces. WSDL for HTTP resources needs to > happen. Perhaps, but with nowhere near the urgency, and nowhere near the complexity of WSDL. WSDL exists, and is a necessary part of Web Services, because you don't know anything about an interface. With REST, you start off with a lot of information. It's not *all* the information everybody would ever need, but it's more than enough for most. > Work on event models needs to get finished. Maybe store and > forward (the email workalike we discussed here a few months ago) needs to > happen. Yes. > SOAP-RPC already offers solutions to all of the above. They're not as SOAP doesn't have an event model, or a store and forward model. It has an intermediary model, just like HTTP, only better specified. > good as HTTP solutions could be but at least they're out there. Until the > REST stack gets filled out to the same degree as the XML RPC stack, we are > in ivory tower land. Oh, please. Without any further work, I can get a whole lot done with REST right now, between uncoordinated parties . The same is not true for SOAP/Web-services. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Jeff Bone wrote: > > On Tue, 2002-04-30 at 18:43, Paul Prescod wrote: > > > > And functional? I'm trying hard to imagine how you'd make a "functional" > > web service without making it useless! > > That's a failure of imagination. ;-) What I meant was: a defining characteristic of functional programming is a lack of side-effects and mutation. In other words, if f(x,y) returns z today, it will always return z. This maps to the subset of "Web Services" known as the "static Web". If you start from a different definition of functional, your conclusions will of course vary. Paul Prescod
Lucas Gonze wrote: > > On Tue, 30 Apr 2002, Asynch Messaging wrote: > > > And to provide sufficient metadata, in the form of WSDL, so that a large > > > number of developers can be instantly up and running. > > Don't know how to do that in pure HTTP - that's a missing piece. Not enough > > to through out the baby with the bathwater though. > > There are a bunch of missing pieces. WSDL for HTTP resources needs to > happen. Work on event models needs to get finished. Maybe store and > forward (the email workalike we discussed here a few months ago) needs to > happen. WSDL for HTTP is -- as far as I can tell -- exactly as functional as WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean that your next sentence is misleading: > SOAP-RPC already offers solutions to all of the above. How does SOAP-RPC handle "event models"???? > ... They're not as > good as HTTP solutions could be but at least they're out there. Until the > REST stack gets filled out to the same degree as the XML RPC stack, we are > in ivory tower land. We are already more filled out. WSDL is broken for HTTP but just as broken for SOAP. UDDI is entirely useless for both. Our rough ideas at event models are better than what I've seen for SOAP. We have *some* form of authentication. Most important: we have an addressing and resource manipulation model. They don't even know that they lack one yet (despite that I've been telling them for six months!). Paul Prescod
Mark Baker wrote: > > I think syntax matters too. That's why I'm not an XML person. 8-) Mark Baker wrote: > > Sure, but there's more information available in the former case. If the > XML is going to be processed by a machine anyways, why is the latter > approach any better? The "only machines will see it" argument is the typical of the approach of people who don't care about syntax. ;) > ... I suppose if it were hand authored, but is that > what we're talking about here? Well yes, some of it is completely hand-authored. But at some level it is ALL hand-authored. After all, somebody has to write and debug the programs that works with this stuff. Admittedly, RDF (no matter how ugly) is not quite as bad as binary but nevertheless I see this: "don't worry what it looks like" argument as a slippery slope to unreadability and ultimately back to binary. > Also, I think the XML syntax for the RDF model is a horrible, nasty, > unnecessary thing. It should be killed. You mean that RDF should not be XML-expressible at all? Use s-expressions? Or do you mean you dislike all of the weird minimizations? >... > I've heard talk of adorning schemas with the information necessary to > construct RDF. I like this in theory, though I fear for the practical > implications; primarily, additional network round-trips. The relationship between documents and schemas will typically be many to one so you can do a lot of caching of schemas. Sophisticated RDF use is already dependent on schemas (RDF schemas) to get subclassing and inferencing information, isn't it? So if you want high volume use of RDF I think you'll have to figure out schema caching technologies. Is it really feasible to use RDF without one of: a) a schema or b) a priori knowledge of the vocabulary? >... > > That's certainly valuable but in my personal opinion, most XML users > > will not be willing to pay the price of designing their vocabularies > > specifically for RDF compatibility. > > For now, that's clearly true. As more RDF features are integrated into > tools, the cost of doing this will come down. I don't see it as a tools cost but as a readability cost. Sprinkling all of that RDF junk through my document is, imo, as unacceptable as sprinkling SOAP voodoo into my messages. I guess it boils down to: I think you optimize the XML for readability and processability *as XML* and then figure out how to get the benefits of protocols and metadata engines etc. You think that RDF is primary and that XML is just a container for it. But if that's true then RDF should use an optimized-for-RDF syntax, not XML at all. Paul Prescod
> WSDL for HTTP is -- as far as I can tell -- exactly as functional as > WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean > that your next sentence is misleading: > > > SOAP-RPC already offers solutions to all of the above. Point taken. > How does SOAP-RPC handle "event models"???? By allowing SOAP-RPC to be transported over event protocols such as JMS, and by having a more fleshed out model for intermediaries. Precanned support for HTTP intermediaries is limited to real time proxying. Otherwise you have to get out the power tools and write a gateway by hand, which is too low level a job for most projects. Rather than argue over the details of what is and isn't available, lets focus on building. People are getting the impression -- false IMO -- that REST is a religious war. That's what Sam Ruby was mainly reacting to, and what Dave Winer has been ranting about on scripting news. The kind of obscurantia that we've been arguing over, e.g. URI opacity, needs to be solved and polished well enough to allow app developers to focus on application needs. I don't believe anyone here thinks that's already done. Maybe evangelizing is a part of the work. For example, make the point that service description tools, specifically Visual .NET, apply equally to REST development. So let's do it. but let's not fool ourselves into thinking that once somone embraces the one true faith they'll find full featured toolkits. - Lucas
--- In rest-discuss@y..., Ken MacLeod <ken@b...> wrote: > > Is the huge amount of SOAP infrastructure a means to simply get data > in readily consumable bits? Pretty much. Paul may consider optional parameters a simplification, but from a toolkit perspective it is a complexity. It also doesn't help that there isn't a one-to-one and onto mapping between section 5 defined types and implementation languages like Java. Or that section 5 diverges from XML Schema. There are a few other considerations, such as headers which allow for cross-cutting concerns to be addressed, and some investment in transport independence. > In simple implementations, like XML-RPC, marshalling is about half of > the implementation with procedure call semantics the other half. > Creating an HTTP request library that just marhsalls data should be > that much simpler than one that relays calls. In Axis, the RPC provider is just one modest sized class. It extends the Java provider, and I must confess that there is some other knowledge of RPC that bleeds through in some minor ways in other parts of the implementation (clearly not ideal, but I'm being brutally honest here). The RPC advocates have clearly articulated how such a marshalling infrastructure can be used to implement their preferred style of interaction. I can't help but wonder if it would be possible for this to be done with REST.
--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > What I meant was: a defining characteristic of functional programming is > a lack of side-effects and mutation. In other words, if f(x,y) returns z > today, it will always return z. This maps to the subset of "Web > Services" known as the "static Web". Which is exactly the subset that should use HTTP GET. It might be interesting to compare all REST features with the features of 'unpure' functional languages. Sjoerd Visscher
sjoerd_visscher wrote: > > --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > > What I meant was: a defining characteristic of functional programming is > > a lack of side-effects and mutation. In other words, if f(x,y) returns z > > today, it will always return z. This maps to the subset of "Web > > Services" known as the "static Web". > > Which is exactly the subset that should use HTTP GET. > It might be interesting to compare all REST features with the features > of 'unpure' functional languages. But GET is also good for fetching information that changes over time: like stock quotes. Paul Prescod
Paul Prescod wrote: > sjoerd_visscher wrote: >>--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: >>>What I meant was: a defining characteristic of functional programming is >>>a lack of side-effects and mutation. In other words, if f(x,y) returns z >>>today, it will always return z. This maps to the subset of "Web >>>Services" known as the "static Web". >> >>Which is exactly the subset that should use HTTP GET. >>It might be interesting to compare all REST features with the features >>of 'unpure' functional languages. > > But GET is also good for fetching information that changes over time: > like stock quotes. Yes, that's why languages like Haskell have some side-effect mechanisms. But they are designed very careful and maybe comparing those features with REST will add some interesting information to the discussion. Sjoerd
On Wed, 2002-05-01 at 11:40, Paul Prescod wrote: > > What I meant was: a defining characteristic of functional programming is > a lack of side-effects and mutation. In other words, if f(x,y) returns z > today, it will always return z. The functional programming community realized, oh, circa the Miranda->Haskell transition that this interpretation of function restricted functional programming in such a way as to make it essentially useless except as a theoretical tool. Then followed much debate over how to functionally model entities whose codomain varied with time and state: approaches included explicitly modeling time and history as domain context, etc... the most effective approach has been to encapsulate this variation into entities called "monads" and model the result type as monadic-dependent. Net result is the ability to again reason mathematically about such entities via a compositional style / algebra of programs ala Backus, FP & friends. Haskell, monads, check it out. jb
Paul already made the comment that comparing REST to programming language paradigms is like comparing apples to elephants. The Web is not a programming language. Why would you even want to make that comparison? Jason ----- Original Message ----- From: Sjoerd Visscher To: Paul Prescod Cc: rest-discuss@yahoogroups.com Sent: Wednesday, May 01, 2002 12:41 PM Subject: Re: [rest-discuss] Re: REST Paul Prescod wrote: > sjoerd_visscher wrote: >>--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: >>>What I meant was: a defining characteristic of functional programming is >>>a lack of side-effects and mutation. In other words, if f(x,y) returns z >>>today, it will always return z. This maps to the subset of "Web >>>Services" known as the "static Web". >> >>Which is exactly the subset that should use HTTP GET. >>It might be interesting to compare all REST features with the features >>of 'unpure' functional languages. > > But GET is also good for fetching information that changes over time: > like stock quotes. Yes, that's why languages like Haskell have some side-effect mechanisms. But they are designed very careful and maybe comparing those features with REST will add some interesting information to the discussion. Sjoerd Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
On Wed, 2002-05-01 at 15:03, Jason Diamond wrote: > > Paul already made the comment that comparing REST to programming > language paradigms is like comparing apples to elephants. The > Web is not a programming language. Why would you even want to make > that comparison? Yes, but just because Paul (or anyone else) makes such a comment doesn't mean that it's true or useful. (I.e.: it may be that this is an apples and elephants comparison, but there may be many conversational contexts in which it useful to compare, contrast, or consider similarities between apples and elephants.) I've found it particularly instructive to compare REST to programming language paradigms, and here's why: REST is an "architectural style" --- in some circles (e.g. component / frameworks researchers) also called a "compositional style." As it turns out, all programming languages inherently embody one or another (or maybe even many) architectural / compositional styles, so it's useful to abstract those styles away from particular programming language implementations and compare them. Functional programming is one such style; OOP is another, dataflow is another, etc. (NB: it's easy to argue that dataflow styles are a subset of functional styles). All of these things are mechanisms for decomposing functionality into discrete pieces and then building up programs by "plugging" these pieces together and letting them talk to each other. The abstract model of how you do this is what defines a given style, and whether that is embodied in a programming language or a distributed system design is, at some level, irrelevant. You can usefully talk about (some of) the characteristics of one model or the other independent of its specific instantiation. Anyway, I happen to have found the process of such consideration instructive in understanding REST. Your (or Paul's, etc.) mileage may vary, but before you jump the gun, consider the following sentence: "OOP is to CORBA as ??? is to the Web." jb
Jeff Bone wrote: > Yes, but just because Paul (or anyone else) makes such a comment doesn't > mean that it's true or useful. (I.e.: it may be that this is an apples > and elephants comparison, but there may be many conversational contexts > in which it useful to compare, contrast, or consider similarities > between apples and elephants.) I've found it particularly instructive > to compare REST to programming language paradigms, and here's why: I didn't mean to imply that (when it comes to REST) what Paul says, goes. That was just my way of saying that I thought that particular comment of his was both true and useful. Saying that REST is (or is not) OO and that makes it good (or bad) are the types of comments that I don't think could ever be universally true or useful. > All of these things are mechanisms for decomposing functionality into > discrete pieces and then building up programs by "plugging" these pieces > together and letting them talk to each other. The abstract model of how > you do this is what defines a given style, and whether that is embodied > in a programming language or a distributed system design is, at some > level, irrelevant. You can usefully talk about (some of) the > characteristics of one model or the other independent of its specific > instantiation. But what I think that you're missing is that REST can be abstracted away behind an OO API, a procedural one, a functional one (using monads), and probably even others. The REST architectural style is orthogonal to whatever programming paradigm you prefer to develop in. > Anyway, I happen to have found the process of such consideration > instructive in understanding REST. Your (or Paul's, etc.) mileage may > vary, but before you jump the gun, consider the following sentence: > > "OOP is to CORBA as ??? is to the Web." OOP and CORBA are not related exlusively to all other programming paradigms or architectural styles. It's just as possible to develop a monolithic procedural API using CORBA as it is an object oriented one. The same goes for REST. Jason
On Wed, 2002-05-01 at 15:53, Jason Diamond wrote: > Jeff Bone wrote: > > But what I think that you're missing is that REST can be abstracted away > behind an OO API, a procedural one, a functional one (using monads), and > probably even others. The REST architectural style is orthogonal to whatever > programming paradigm you prefer to develop in. I don't actually agree with this. While it's true that any computationally complete facility can be used to express any other similar facility --- this is all about universality, etc. --- that doesn't mean that they are all equivalent. I can model functions as objects; I can model objects as functions; etc. etc. etc. 'til the cows come home. However, that's not a particularly useful observation: similarly, that's like saying that OOP is orthogonal to whatever programming language you happen to be using. While it's true that you can do OOP even in e.g. assembly, it sure ain't easy. ;-) My point is that REST the architectural style may *be* or *imply* a particular programming paradigm; consideration of that issue has been particularly helpful to me in understanding and quantifying certain things about REST. > > "OOP is to CORBA as ??? is to the Web." > > OOP and CORBA are not related exlusively to all other programming paradigms > or architectural styles. It's just as possible to develop a monolithic > procedural API using CORBA as it is an object oriented one. The same goes > for REST. I think you're missing something important, but can't quite put my finger on how to explain it to you. jb
Jeff Bone wrote: > > But what I think that you're missing is that REST can be abstracted away > > behind an OO API, a procedural one, a functional one (using monads), and > > probably even others. The REST architectural style is orthogonal to whatever > > programming paradigm you prefer to develop in. > > I don't actually agree with this. While it's true that any > computationally complete facility can be used to express any other > similar facility --- this is all about universality, etc. --- that > doesn't mean that they are all equivalent. I can model functions as > objects; I can model objects as functions; etc. etc. etc. 'til the cows > come home. However, that's not a particularly useful observation: > similarly, that's like saying that OOP is orthogonal to whatever > programming language you happen to be using. While it's true that you > can do OOP even in e.g. assembly, it sure ain't easy. ;-) This is a very good point. > My point is that REST the architectural style may *be* or *imply* a > particular programming paradigm; consideration of that issue has been > particularly helpful to me in understanding and quantifying certain > things about REST. OK, this is certainly reasonable. But I like to think of using REST as being something similiar to the using the relational database model. Does accessing a relational database imply any one particular programming paradigm to you? From experience, I would certainly say that it doesn't imply OO but that doesn't prevent me from using it usefully from OO languages. REST is unique when compared to programming languages (simply because it isn't a programming language but rather an architectural style as you pointed out) and needs to be evaluated independently from them. Maybe it will be easier to use a RESTful architecture from certain types of languages but that doesn't necessarily mean that REST should be considered as being of that language's paradigm. > > > "OOP is to CORBA as ??? is to the Web." > > > > OOP and CORBA are not related exlusively to all other programming paradigms > > or architectural styles. It's just as possible to develop a monolithic > > procedural API using CORBA as it is an object oriented one. The same goes > > for REST. > > I think you're missing something important, but can't quite put my > finger on how to explain it to you. If I am missing something, then please don't stop trying to beat it into me until I finally get it. :-) Jason
> -----Original Message----- > From: Jason Diamond [mailto:jason@injektilo.org] > Sent: 01 May 2002 21:03 > Todiscuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: REST > > > Paul already made the comment that comparing REST to > programming language paradigms is like comparing apples to > elephants. The Web is not a programming language. Why would > you even want to make that comparison? Right, the Web is not a programming language; also the Web != REST. REST, specifics aside, is a computing paradigm (disclosure: I accept the notion of "REST Architectural Style", but not "REST Architecture"). May there not be value in comparing the REST paradigm with programming paradigms? Bill de hra
> -----Original Message----- > From: Lucas Gonze [mailto:lucas@...] > Sent: 01 May 2002 18:20 > To: Paul Prescod > > > How does SOAP-RPC handle "event models"???? > > By allowing SOAP-RPC to be transported over event protocols > such as JMS, and by having a more fleshed out model for > intermediaries. Are you saying the processing style depends on the underlying protocol SOAP is carried over/through? I thought SOAP was supposed to be a protocol. Bill de hra
> -----Original Message----- > From: Jeff Bone [mailto:jbone@...] > > "OOP is to CORBA as ??? is to the Web." Hypertext. Bill de hOra
I'm not Lucas. 8-) On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de h�ra wrote: > Are you saying the processing style depends on the underlying protocol > SOAP is carried over/through? I thought SOAP was supposed to be a > protocol. Those two things aren't inconsistent. WebDAV is both a protocol and an HTTP extension. SOAP can be used in the same way. Indeed, this is the only practical way in which SOAP can be used in a REST friendly manner (the other way being to recast REST semantics on top of SOAP - a horrible, horrible idea). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
> May > there not be value in comparing the REST paradigm with programming > paradigms? > > Bill de hra Rethinking problems in terms of resource modelling, I always think of the way that SQL forces you to collapse iterative algorithms into single statements. - Lucas
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > > I'm not Lucas. 8-) ? > On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de hra wrote: > > Are you saying the processing style depends on the > underlying protocol > > SOAP is carried over/through? I thought SOAP was supposed to be a > > protocol. > > Those two things aren't inconsistent. WebDAV is both a > protocol and an HTTP extension. SOAP can be used in the same > way. Indeed, this is the only practical way in which SOAP > can be used in a REST friendly manner (the other way being to > recast REST semantics on top of SOAP - a horrible, horrible idea). Maybe they're not exclusive, I'm not sure. A (network) protocol is interesting insofar as it's a useful abstraction (of the network). Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP, means I can't just think my application and SOAP, I may as well think about App and JMS or App and HTTP or App and BEEP, and eliminate superfluous noise. This is like C programming; machine power is traded for programmer dissonance. Bad trade. I expect that programmers will just think about the SOAP abstraction, bedamned the supporting protocol. Bill de hOra
Bill de h�ra wrote: > >... > > Are you saying the processing style depends on the underlying protocol > SOAP is carried over/through? Absolutely! > .... I thought SOAP was supposed to be a > protocol. Key word: "was". Seriously, SOAP may meet some technical definition for "protocol" but I'd say it is really some kind of meta-protocol or protocol framework or "XML vocabulary with processing expectations" or something. That's "SOAP in general" as opposed to "SOAP-RPC over HTTP" which is really a very concrete RPC protocol. Paul Prescod
Is there anything to accomplish via a BOF at ETCON? IE, a convincing agenda?
Mark Baker wrote: > > I'm not Lucas. 8-) > > On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de h�ra wrote: > > Are you saying the processing style depends on the underlying protocol > > SOAP is carried over/through? I thought SOAP was supposed to be a > > protocol. > > Those two things aren't inconsistent. WebDAV is both a protocol and > an HTTP extension. But WebDAV is only designed to run over HTTP or perhaps over protocols with very HTTP-like characteristics. If you use a WebDAV library you know what to expect in terms of synchronousness, message patterns, etc. SOAP does not predefine message patterns independent of the transport. One transport could be synchronous and the next asynchronous. One unidirectional and the next bidirectional. One transport could have an addressing model and another lack one. etc. Paul Prescod
One of the most striking advantages of SOAP over HTTP is the XML Headers
with clear intermediary targeting and requirements on understanding.
Some thoughts are here:
* http://www.prescod.net/xml/envelopes
Now, I'd like to know what stands between HTTP and full XML headers with
mustUnderstand and intermediary targeting etc. Now looking at the
following productions from the HTTP specification, it seems to me that
lightly encoded XML is in fact legal in an HTTP header:
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
So XML in a header could not use the " character. That seems a minor
loss to me, because XML treats ' and " interchangably in markup and " in
content can always be replaced with ".
Am I missing something major?
mustUnderstand would have to be handled using M-GET as described here:
* ftp://ftp.isi.edu/in-notes/rfc2774.txt
Paul Prescod
I submitted a description for an ETCON BOF called "Alternative Web Services Architectures". I don't think that in one or two hours we can make huge progress towards understanding each other but it may help to hash out a few issues. Paul Prescod
> Rather than argue over the details of what is and isn't available, lets > focus on building. > Maybe evangelizing is a part of the work. For example, make the point > that service description tools, specifically Visual .NET, apply equally to > REST development. So let's do it. but let's not fool ourselves into > thinking that once somone embraces the one true faith they'll find full > featured toolkits. Well put. What are the missing pieces? - discovery (wsdl-style declarative formats, intellisense-tool friendly stuff, etc.) - clients (do we need to write new 'resource modelling friendly' clients in all the languages or can we re-user protocol API libraries?) I don't think we need asynch stuff immediately, since there isn't an existing body of resource that support it to hook up to. What else?
On Wed, May 01, 2002 at 10:52:37PM +0100, Bill de h�ra wrote: > Maybe they're not exclusive, I'm not sure. A (network) protocol is > interesting insofar as it's a useful abstraction (of the network). > Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP, > means I can't just think my application and SOAP, But that's the rub. The Web *is* your application. Or more precisely, to use the Web, you have to form your application in the shape of the Web; hypertext. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
You may or may not find the following useful: http://www.hpl.hp.com/personal/John_Barton/HTTP-A/DIME/Comparison% 20of%20MIME%20and%20DIME.htm
I wanted to emphasize this "no query" point for anyone on rest-discuss new to REST. -------- Original Message -------- Subject: Re: [xml-dev] SOAP and the Web Date: Thu, 02 May 2002 04:27:10 -0700 From: Paul Prescod <paul@...> To: Francis Norton <francis@...> CC: xml-dev <xml-dev@...> References: <2C61CCE8A870D211A523080009B94E430752B3C9@HQ5> <3CD01C16.80606@...> <3CD06157.11DC0617@...> <3CD113B5.9060505@...> Francis Norton wrote: > >... > I know I have a bit of a blind-spot here. What is the canonical example > of a "resource" v. a "representation"? Say I wanted to look up trains > from London to North Berwick - is the URL of the query a representation > of the timetable resource? The timetable is a resource. A URL is never a representation: the representation is the stuff that gets sent across the wire: the XML or XHTML or whatever. It is what you GET and PUT. Here's the radical bit: ideally there would be *no* query in this system. Let's say the XML was organized like this: <routes> <route from="http://train.com/cities/London" to="http://trains.com/cities/NorthBerwick" href="http://trains.com/routes/LondonToNorthBerwick"/> </routes> Then you have the document: http://trains.com/routes/LondonToNorthBerwick It has: <times> <time>ISODATE1</time> <time>ISODATE2</time> <time>ISODATE3</time> <time>ISODATE4</time> <time>ISODATE5</time> </times> Now you get into this service through the "routes" document above, follow the hyperlink to the "ondonToNorthBerwick" document and find the information you need. You've never done a query and you've never had to send complex XML. When you do it this way: 1. the client's access to the data is not mediated by any API or messaging interface. This is very much in the XML spirit of "give me the data and I (the client) will figure out what to do with it. 2. you cannot generate a "bad query" by trying to get from London, Ontario to North Berwick, Scotland (nor North Berwick Maine to London, England!). If there is no link for that route then you can't get there. 3. the client can discover routes, rather than merely generate them and test whether they exist or not. For instance it could say: "hmmm. I notice a route from London to Glasgow and Glasgow to North Berwick. Maybe this is also interesting to my user." 4. the standardization of the "routes" format and the "times" format can actually be fairly disconnected. For instance we might use the same "times" format for airlines and trains but the "routes" format might be different. Or else we could use XML extensibility features to share both but have different details on both. 5. the server can easily serve these as either dynamic OR static documents. The performance advantages to the latter should be obvious. >... That seems simple enough, but what is the > representation that I send - one representation of the train route from > London to North Berwick, or a combination of representations for the > locations of London and North Berwick? It's like asking how you model objects in an OO systems. I guess I would tend towards breaking things apart rather than combining them but that's just a very rough rule of thumb. But note that the question is really how you break out the *resources*. Representations just represent resources on the wire. > I like the way that W3C specs come with "this version" and "latest > version" links at the top, and I find it frustrasting that I can't refer > to resources in Visual SourceSafe in the same way, so I think I'm making > progress... Yep, using hyperlinks like that is very resty. Visual SourceSafe probably has an "API" that allows you to access older versions through code. That's a very "SOAP-y" way to look at it. >.... > >XForms *does* have GET support. > > > Can XForms understand GET or POST Web Services described in WSDL? I > imagine WSDL is a bit short on form layout details, but does XForms have > helpful deaults? XForms does not know anything about WSDL. After all the former is a W3C specification and the latter has only just begun its standardization process. And anyhow, they are kind of parallel specifications. WSDL is used to map the interface to a web site into an interface suitable for programmers. XForms is used to map it into an interface suitable for humans. There wouldn't be that much in common between them other than the XML Schema. Paul Prescod ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
--- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote: > Is there anything to accomplish via a BOF at ETCON? IE, > a convincing agenda? I posted a few suggestions at http://www.oreillynet.com/cs/weblog/view/wlg/1360
> I submitted a description for an ETCON BOF called "Alternative Web > Services Architectures". I don't think that in one or two hours we can > make huge progress towards understanding each other but it may help to > hash out a few issues. > > Paul Prescod Care to run a BOF on any of the below? Not sure which one "Alternative Web Services Architectures" is... * "Standardization of Web Services" * "Implementing REST" (a tutorial) * "Choosing the Right Web Services Design for your Business." Question: what issues need to be covered in a tutorial? Strawmen suggestions: * gross overgeneralizations taken from The Thesis * something about URIs Is there anything to say about this? * semantic meaning of methods; PUT/POST/GET/DELETE * resource modeling define resource and representation content negotiation * using status codes aside from 200 * where XML fits in SOAP as payload format rather than RPC packager - Lucas
Lucas Gonze wrote: > > * using status codes aside from 200 FYI (not to imply that you are suggesting otherwise, but I have seen others comment on this) http://www.w3.org/TR/SOAP/#_Toc478383529 - Sam Ruby
I want to point out a couple of subtleties about queries.
I think that queries are a fallback position from hypertext. As I said
earlier, hypertext has advantages and the primary one is that it is more
discoverable and navigable than a query (or API or messaging interface
or...).
I do think that queries are an important optimization. Sometimes finding
out equivalent information through hypertext would take significant
effort. For instance in the Google case, they have so many word indexed
that for bandwidth reasons their hypertext "tree" would probably have to
be something like this:
p
pr
pre
pres
prescod
prescod+p
prescod+pa
prescod+paul
They could of course us balancing algorithms to minimize the size of it
but still it would take several back and forth messages to get to the
point where we have the information available from:
http://www.google.com/search?q=prescod+paul
This hypertext view may be too slow for much real-world use. But on the
other hand, the hypertext view gives the client access to all kinds of
interesting information. For instance by spidering "prescod" I can find
out all words associated with my name. I could pretty easily find
GoogleWhacks that use my name. ;) I could scan for first names to find
other Prescods. The information available in the hypertext version is a
strict superset of the information available in the query version, but
navigating it may be too inefficient. So I think that in many
circumstances, both views are warranted.
Google might also want to have the query view be a free service and the
navigable view be something that people pay to use for data mining.
Other opinions?
Paul Prescod
Sorry, but this is really late notice. Tomorrow is the last
day for comments on the FCC's proposal to call the Internet
an "information service" for the entrenched broadband
interests. Ostensibly, this decision is being made in
preference over classifying broadband internet as a
"communications medium," which would place it under
regulations like those phone companies are subject to. It
is therefore being characterized as a decision for
deregulation versus regulation.
Anybody who can, PLEASE send in a note saying this is not a
question of whether regulation or deregulation is better
policy (this is just a smokescreen) -- it's a question of
the nature of the online medium: Is it a "content" delivery
system, or a communications medium characterized by its
fundamental two-way protocols, one which brings profound new
capabilities to all citizens?
*Please* send even just a short note to the FCC at
ecfs@....
If you know any other constituencies that would want to put
a word in on this, please let them know.
From Dave Farber's Interesting People list,
farber@....
Seth Johnson
-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <dfarber@...>
-----Original Message-----
From: "David S. Isenberg" <isen@...>
Date: Thu, 02 May 2002 16:13:48
To: dave@...
Subject: Comment on NPRM 02-33
Dave,
This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write. NPRM
02-33 threatens to turn back the network architecture clock
to pre-Internet days. Please distribute it via IP as soon
as you can -- the deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.
IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc
FCC comments should follow the form below. Email them to
the FCC's Electronic Comment Filing System: ecfs@....
ECFS - E-mail Filing
<PROCEEDING> 02-33
<DATE> 5/2/02
<NAME> David S. Isenberg
<ADDRESS1> 112 Orchard Street
<ADDRESS2>
<CITY> Cos Cob
<STATE> CT
<ZIP> 06807
<LAW-FIRM> none
<ATTORNEY> none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER> 203-661-4798
<DESCRIPTION> Email Comment
<CONTACT-EMAIL>isen@...
<TEXT>
I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.
Let me introduce myself. I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech. I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff.
Today, I make my living as an independent commentator on
telecommunications. While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests. I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.
In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet. "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it. Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy). That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods. So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.
It was not always so. The telephone network was developed
to deliver one kind of information -- the human voice. It
was engineered for voice, and it gave access to voice.
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony.
The wire that came into the house could not be distinguished
from the service it provided. It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.
The great advance of the Internet was that its fundamental
architecture separated "access" from "information". Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information. Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access. As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.
Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network. No, access is a fundamentally different business
from "information service". To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.
Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s. TV-on-speed is not "the
Internet" -- and vice versa.
David I
-------
************ WE HAVE MOVED! ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------*
David S. Isenberg isen@...
isen.com, inc. 888-isen-com (inside US)
http://isen.com/ 203-661-4798 (direct line)
*--------------------isen.com----------------------*
-- The brains behind The Stupid Network --
*--------------------isen.com----------------------*
For archives see:
http://www.interesting-people.org/archives/interesting-people/
[mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7174] I think talking about whether REST applies to long lived conversations would be a great topic. There has been discussion about this on the REST forums, but it would be good to go over it again. As for HTTP, there is a response code of '202 Accepted' which is used to indicate that the request is being processed asynchronously - which leads to the 'five days for a response' situation. What hasn't happened is for a large number of people to implement a standard approach for sending that final response message to the sender - but there are lots of ways to do that (take a look at the REST discussion groups). Mike ----- Original Message ----- From: "sa3ruby" <rubys@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, May 02, 2002 6:00 AM Subject: [rest-discuss] Re: etcon BOF? > --- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote: > > Is there anything to accomplish via a BOF at ETCON? IE, > > a convincing agenda? > > I posted a few suggestions at > http://www.oreillynet.com/cs/weblog/view/wlg/1360 > >
I'll try to keep this REST-focused. On Wed, May 01, 2002 at 10:20:27AM -0700, Paul Prescod wrote: > > Also, I think the XML syntax for the RDF model is a horrible, nasty, > > unnecessary thing. It should be killed. > > You mean that RDF should not be XML-expressible at all? Use > s-expressions? Or do you mean you dislike all of the weird > minimizations? I dislike that the triple structure of the RDF model is being shoehorned into a tree based syntax. It's unnatural, and it shows. > > I've heard talk of adorning schemas with the information necessary to > > construct RDF. I like this in theory, though I fear for the practical > > implications; primarily, additional network round-trips. > > The relationship between documents and schemas will typically be many to > one so you can do a lot of caching of schemas. Sophisticated RDF use is > already dependent on schemas (RDF schemas) to get subclassing and > inferencing information, isn't it? Yes, but RDF Schema is so general that it will likely be a built-in for all processors. The same can't be said of vCard-in-XML, or Docbook, etc.. That's the issue, I believe. Schemas can indeed be cached, but that you'd need to get them in the first place is what hurts. > > For now, that's clearly true. As more RDF features are integrated into > > tools, the cost of doing this will come down. > > I don't see it as a tools cost but as a readability cost. Sprinkling all > of that RDF junk through my document is, imo, as unacceptable as > sprinkling SOAP voodoo into my messages. I guess it boils down to: I > think you optimize the XML for readability and processability *as XML* > and then figure out how to get the benefits of protocols and metadata > engines etc. You think that RDF is primary and that XML is just a > container for it. > > But if that's true then RDF should use an optimized-for-RDF syntax, not > XML at all. Mostly, yes. Sometimes you need the additional value that XML adds; Unicode, xml:lang, xml:space, xml:base, etc.. From a purely REST POV, I want to use content negotiation to retrieve RDF (N3, but XML if that's required) representations of resources. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
(Forwarded from DIME Discussion list, DIME@...) -------- Original Message -------- Date: Thu, 2 May 2002 22:45:12 -0700 From: Simon Fell <soap@...> I'm surprised this didn't get announced here, but here's the doc. http://gotdotnet.com/team/xml_wsspecs/dime/WSDL-Extension-for-DIME.htm BTW, you may want to fix the links in the ToC. Cheers Simon www.pocketsoap.com
Mark Baker wrote: > >... > > Yes, but RDF Schema is so general that it will likely be a built-in > for all processors. The same can't be said of vCard-in-XML, or > Docbook, etc.. > > That's the issue, I believe. Schemas can indeed be cached, but that > you'd need to get them in the first place is what hurts. Aren't you comparing apples and oranges? RDF Schema is a schema language, like RELAX NG or XML Schema. AFAIK, individual RDF vocabularies have individual schemas expressing their type relationships and inferencing rules, just as individual XML vocabularies have individual schemas. As I've heard you describe your idealized RDF bootstrapping process it involves recognizing that you don't understand an assertion and then looking up the definition and if you don't understand that you look up the definition of that and if you don't, etc. etc. So whereas the XML schema process is typically "flat" (barring a lot of inheritance or a very modularized schema), the evaluation of an RDF expression could require very deep recursion. >... >From a purely REST POV, I want to use content negotiation to retrieve > RDF (N3, but XML if that's required) representations of resources. Maybe in the long term. In the medium term I think it is more practical to do the "generic XML"->RDF transformation on the client side so I am on the lookout for technologies that will allow that. Paul Prescod
Here is my rough counter-part to this document: http://www.extremeprogramming.org/rules.html I notice that Microsoft co-opted the term "extreme web services" in a talk in February ... oh well. 1. Loose coupling of implementations: Clients should not need to know anything about the object models of services and vice versa. It is therefore almost never appropriate to generate an interface definition for an extreme service from existing implementation code. The interface should be chosen to maximize interoperability and extensibility, not to simplify implementation. 2. No Implicit Resources: If the server has some information that it is willing to make available to the client then that information should be exposed as part of a URI-named resource. The client should not need to submit XML-encoded "parameters" or a "query" to get the information. The means for getting the URI is discussed in other points. 3. No Implicit State: If the client and server depend on a shared piece of information in order to communicate effectively then that piece of information should be given an address (usually by the server) and exposed as a web resource. Clients should be considered entirely stateless. The only thing they remember from one message to another are things defined by the protocol, like authentication tickets -- not things defined by the application, like purchase order numbers. 4. No abuse of protocols or formats: Knowingly violating either the letter or the spirit of specifications degrades the value of those specifications ot you and others. Most often if you read the specifications you will learn that the creators anticipated your problem and made a provision for it. If not, the chances are strong that your problem is out of scope for the protocol or format and maybe you should choose another one or invent your own. 5. Use standards where possible: HTTP is the standard Web protocol for the manipulation of information. XML is the standard Web representation for information. RDF is the standard representation for metadata. By default, you should use these. Use something else only when you have researched these closely and have a clear sense of a limitation of one of these. Using something non-standard will be expensive for those building client applications that will use your service. You should explicitly justify that cost. 7. Use URIs (typically URLs) to name things: URIs are better names than numbers, UUIDs or other non-standard naming conventions. The first virtue of URIs is that they are derived from a managed namespace so name clashes can be avoided merely by choosing only to use names that we each own. For instance if two companies merge their purchase orders will be uniquely named because the two companies would have formerly had unique domain names. Whereas this is not necessarily true of integer-named purchase orders. Second, URIs provide an easy way to associate metadata (or "plain data") with the named entity. Even if you do not need that today you may need it later. 8. Use hyperlinks (URIs embedded in XML or HTTP headers) to guide the client through the service: Do not require it to build up state on the client side. The state should be encapsulated into resources that the client creates. As long as it keeps track of one URI, it should be possible for it to re-discover all of the relevant state merely by following hyperlinks. A query is only better than hyperlinks as an optimization and when the client is likely to have a priori knowledge that must be plugged into the service (e.g. a dress size). 9. Given the choice between a generic interface and a specific one, use the generic one if your goal is to maximize interoperability: It may take more effort to re-organize your information into the generic interface but that effort will usually pay off for your clients. For example, XML is a generic data representation and is sometimes not quite as efficient as application-specific notations. Nevertheless it is usually the right choice because the client can implement one XML parser instead of hundreds of parsers for application-specific notations. The same sort of argument can be made for HTTP. 10. Disclaimer meta-rule: the real world is complicated and there are many broken software products and business environments out there. Break rules when you need to do so -- but understand the costs of breaking them and document your reasons.
[snip] minor nitpick: the UUID vs URI characterisation is a bit bogus, since there is (or could be -- forget the status) an easy way of writing UUID identifiers in URI syntax. You might say that URIs are good, but some kinds of URI are more good than others... ;-) Dan -- mailto:danbri@... http://www.w3.org/People/DanBri/
On Sat, May 04, 2002 at 03:19:20PM -0400, Dan Brickley wrote: > > minor nitpick: the UUID vs URI characterisation is a bit bogus, since > there is (or could be -- forget the status) an easy way of writing UUID > identifiers in URI syntax. IIRC it is urn:uuid:rqio502u82qy8ervthkgnxiyw349$&*%()&*%$&*$^((%^&(*asdjoaw -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Dan Brickley wrote: > > minor nitpick: the UUID vs URI characterisation is a bit bogus, since > there is (or could be -- forget the status) an easy way of writing UUID > identifiers in URI syntax. http://www.globecom.net/ietf/draft/draft-kindel-uuid-uri-00.html - Sam Ruby
Yes, excellent point! I really mean "resolvable URIs" which at one time were termed "URLs". I gues you could establish a hierarchy of goodness: names -> universal names -> universally resolvable names. Dan Brickley wrote: > > [snip] > > minor nitpick: the UUID vs URI characterisation is a bit bogus, since > there is (or could be -- forget the status) an easy way of writing UUID > identifiers in URI syntax. You might say that URIs are good, but some > kinds of URI are more good than others... ;-) > > Dan > > -- > mailto:danbri@... > http://www.w3.org/People/DanBri/
On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote: > Yes, excellent point! I really mean "resolvable URIs" which at one time > were termed "URLs". I gues you could establish a hierarchy of goodness: > names -> universal names -> universally resolvable names. Wait a minute! DDDS will make URNs resolvable. Should we call them URLs now too. 8-) <ducks/> MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
We call them URIs. :)
Tony
Mark Baker
<distobj@acm.o To: Paul Prescod <paul@...>
rg> cc: Dan Brickley <danbri@...>, "rest-discuss@yahoogroups.com"
<rest-discuss@yahoogroups.com>
06/05/2002 Subject: Re: [rest-discuss] "Extreme Web Services"
21:41
On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote:
> Yes, excellent point! I really mean "resolvable URIs" which at one time
> were termed "URLs". I gues you could establish a hierarchy of goodness:
> names -> universal names -> universally resolvable names.
Wait a minute! DDDS will make URNs resolvable. Should we call them
URLs now too. 8-)
<ducks/>
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@...
http://www.markbaker.ca http://www.planetfred.com
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I'm having a hard time trying to make this functionality RESTful, for some reason I can't stop visualizing the solution as an RPC style one. Here is an outline of what I am trying to do. I have a list of package names (approx 100), and I would like to allow users to search through these packages by providing a regular expression. Of course the package names that match the regex will be returned back to the client. So let me try and walk through how my mind is thinking about the REST way of doing this. I am looking for a resource name that the client is interested in, so I think possibley something like this. GET http://somehost.org/package/names The above would be fine (wouldn't it?) if I just wanted to get all the packages back that where in the entire database, however I want to filter them so I'm thinking that I need to add some sort of parameter(s) to it. This is where my thinking breaks down because now I think it starts to look RPC style. Here is what I come up with GET http://somehost.org/package/names?like=regex The reason I think that looks RPC'ish is because to me it looks like I am asking for some sort of operation as opposed to a resource. Any thoughts/suggestions/opinions are all welcome. Many thanks in advance. - -- Signed, Holden Glova -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE81699+mF116Lw2cQRAmrqAJ94aE9+LSaEE1BNuiEJlCRG4XQEoQCdF8bf OkbQ571fD3kb2Jx29z7cZek= =u3Bc -----END PGP SIGNATURE-----
Holden Glova wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello all, > > I'm having a hard time trying to make this functionality RESTful, for some > reason I can't stop visualizing the solution as an RPC style one. Here is an > outline of what I am trying to do. I have a list of package names (approx > 100), and I would like to allow users to search through these packages by > providing a regular expression. Of course the package names that match the > regex will be returned back to the client. So let me try and walk through how > my mind is thinking about the REST way of doing this. As I've said a few times recently, in my personal opinion there is nothing wrong with a query as an optimization. I think that your solution is absolutely fine as long as: 1. the list of 100 package names *is* exposed somewhere as a URI-addressable list for a client that would rather do iterative discovery rather than query-based discovery. You've already said that you'll do this. 2. each package has its own URI for hyperlinking both in the list described in 1. and in the query results that you are already working on. For client-simplicity, you should probably use the same XML vocabulary for the query results as for the "full list". 3. if packages can be mutated or deleted, you use the appropriate HTTP method and not queries. So overall my opinion is that you are on the right track! Paul Prescod
----- Original Message ----- From: "Holden Glova" <dsafari@...> > > I am looking for a resource name that the client is interested in, so I think > possibley something like this. > > GET http://somehost.org/package/names > > > GET http://somehost.org/package/names?like=regex > > The reason I think that looks RPC'ish is because to me it looks like I am > asking for some sort of operation as opposed to a resource. > These both are fine for what you are doing. A problem I always have remembering that the two URI are two completely separate resources (from the point of view of clients 'outside the interface') even though they look similar. The full list could just as easily have been GET http://somehost.org/package/names?all or GET http://somehost.org/package/allnames or whatever. Something to remember is that even though http://somehost.org/package/names is part of both URI, that doesn't make it 'the one resource'. The second URI (with the query terms) is not 'the one resource' plus parameters - it is a separate resource. You may have a singular data source within your implementation (like a database) but outside your interface you expose things as separate resources. Kind of like creating a view in a database - which makes a query look like a table. So a more illustrative example (not that you should change your URIs) to show that they are separate resources might be GET http://somehost.org/package/allnames GET http://somehost.org/package/names?like=regex
On Tue, May 07, 2002 at 10:42:05PM +1200, Holden Glova wrote: > GET http://somehost.org/package/names Without knowing any more than what you've described, I would personally use; http://somehost.org/packages/ and http://somehost.org/packages/?namelike=regex permitting individual packages to be identified by; http://somehost.org/packages/2342343/ I don't see the need to bring "name" out as a separate sub-resource. I see it more as an attribute of the package, not a resource. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
"Roger L. Costello" wrote: > > I am just ramping up on REST. Please forgive me if my > questions/comments are naive. Roger, detailed discussion should be redirected to the rest-discuss list because people on xml-dev are tired of the repitition that arises from teaching REST to new people as they become interested in it. >... > Now consider the case where web sites serve up XML not HTML (I shall > refer to this as XML-REST). Suppose that the XML is programmatically > processed. The HTTP methods (GET, POST, PUT, etc) provide a nice set of > **access methods** for getting and putting the XML data. Thus, > **accessibility** is scalable as it is on the order of linear. However, > **processing** the XML data still needs customized code (just like > machine processing of HTML requires custom code). I therefore conclude > that XML-REST is no more scalable than SOAP. Yes, this is an important insight. But the linear factor is also important. I believe that it is much easier to standardize XML vocabularies within and between industries than it is to share APIs or messaging interfaces or whatever you want to call them. HTML is merely an extreme example of this. The widespread success of RSS is a second example. (might be interesting to try to understand why RSS is so much more popular on the "public Internet" than is XMLNews...) Obviously "chemical ML" is going to be much less widespread than HTML but I have much more hope that Bayer and 3M would share "chemical ML" than that they would agree on a wire-protocol for describing chemicals. There are a variety of reasons but one reason is that agreeing on a wire-protocol is much closer to agreeing on a *business model* than is agreeing on an XML vocabulary. >... > > How can we make XML-REST scalable? One solution would be to require > every web site to serve up the same type of XML documents, i.e., have a > universal Schema that all XML documents conform to. Obviously this is > not a very attractive solution. The other solution is to have web sites > serve up documents whose meaning can be dynamically "discovered". I > believe that RDF is the only XML technology that enables dynamic > understanding of content. Thus, the cornerstone for a scalable, > machine-processable web services architecture is: > > 1. The HTTP access methods - GET, POST, PUT, etc > 2. A dynamically understandable vocabulary, such as RDF. Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF "believer" I see it more as a spectrum: as we understand problem domains more and more, we migrate more and more stuff from "the code" into declarative formats that describe the data. RDF fans think that RDF is the declarative "uber-format". We'll see. Maybe. If they are wrong, I still expect dozens of declarative languages like XML Query, XSLT etc. to mature into powerful tools for bootstrapping understanding of a vocabulary. (consider for example an XSLT associated with one industry standard purchase order vocabulary that translates it into another PO vocabulary on demand -- easy to model in an industry-neutral way with URIs and XML). One reason I argue against the "standard web services" model because it moves the very first bit of the problem from the domain of declarations into the domain of code. I.e. to even get the data you need to write code. That's a serious impediment to further exploration down the declarative path. If XML Query turns out to be extremely wonderful and powerful, this fork in the road should come into even greater focus. Paul Prescod
Thanks Paul. I will subscribe to the REST list group. BTW, in your Second Generation Web Services article you mentioned that you would write another article: "In an upcoming article, I will - describe in more detail how any web service can be transformed into a URI-centric one; - show an example of a successful, public, widely used web service that uses this model today; - discuss the role of SOAP in these sorts of web services; - discuss reliability, coordination, transactions, asynchronicity, firewalls etc. " Have you completed this article? I really liked the first article, and have been eagerly awaiting the second one. /Roger Paul Prescod wrote: > "Roger L. Costello" wrote: > > > > I am just ramping up on REST. Please forgive me if my > > questions/comments are naive. > > Roger, detailed discussion should be redirected to the rest-discuss list > because people on xml-dev are tired of the repitition that arises from > teaching REST to new people as they become interested in it. > > >... > > Now consider the case where web sites serve up XML not HTML (I shall > > refer to this as XML-REST). Suppose that the XML is programmatically > > processed. The HTTP methods (GET, POST, PUT, etc) provide a nice set of > > **access methods** for getting and putting the XML data. Thus, > > **accessibility** is scalable as it is on the order of linear. However, > > **processing** the XML data still needs customized code (just like > > machine processing of HTML requires custom code). I therefore conclude > > that XML-REST is no more scalable than SOAP. > > Yes, this is an important insight. But the linear factor is also > important. I believe that it is much easier to standardize XML > vocabularies within and between industries than it is to share APIs or > messaging interfaces or whatever you want to call them. HTML is merely > an extreme example of this. The widespread success of RSS is a second > example. (might be interesting to try to understand why RSS is so much > more popular on the "public Internet" than is XMLNews...) Obviously > "chemical ML" is going to be much less widespread than HTML but I have > much more hope that Bayer and 3M would share "chemical ML" than that > they would agree on a wire-protocol for describing chemicals. There are > a variety of reasons but one reason is that agreeing on a wire-protocol > is much closer to agreeing on a *business model* than is agreeing on an > XML vocabulary. > > >... > > > > How can we make XML-REST scalable? One solution would be to require > > every web site to serve up the same type of XML documents, i.e., have a > > universal Schema that all XML documents conform to. Obviously this is > > not a very attractive solution. The other solution is to have web sites > > serve up documents whose meaning can be dynamically "discovered". I > > believe that RDF is the only XML technology that enables dynamic > > understanding of content. Thus, the cornerstone for a scalable, > > machine-processable web services architecture is: > > > > 1. The HTTP access methods - GET, POST, PUT, etc > > 2. A dynamically understandable vocabulary, such as RDF. > > Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF > "believer" I see it more as a spectrum: as we understand problem domains > more and more, we migrate more and more stuff from "the code" into > declarative formats that describe the data. RDF fans think that RDF is > the declarative "uber-format". We'll see. Maybe. > > If they are wrong, I still expect dozens of declarative languages like > XML Query, XSLT etc. to mature into powerful tools for bootstrapping > understanding of a vocabulary. (consider for example an XSLT associated > with one industry standard purchase order vocabulary that translates it > into another PO vocabulary on demand -- easy to model in an > industry-neutral way with URIs and XML). > > One reason I argue against the "standard web services" model because it > moves the very first bit of the problem from the domain of declarations > into the domain of code. I.e. to even get the data you need to write > code. That's a serious impediment to further exploration down the > declarative path. If XML Query turns out to be extremely wonderful and > powerful, this fork in the road should come into even greater focus. > > Paul Prescod
Mark Baker wrote in http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0127.html >> Could you possibly clarify this by giving an example of a stateful >> interaction which you think should not be allowed? > Sure. > In FTP, the command "RETR foo.zip" (retrieve the file foo.zip) > means different things depending upon what your current directory > is. The current directory is set with previous FTP commands. > So the interpretation of a message depends on previous messages. > That's stateful. Would you have any objection to a resource representing a state? Or having a state as a property? Lots of interactions are inherently stateful. As in conversations or sessions. Business exchanges are usually that way. The interpretation of a message will depend on previous messages. But I think the state of a business exchange is actually the state of a particular business entity, e.g. an Order. So it can be represented as the state of an Order resource. For example, maybe you can't change an Order that is in the "fulfilled" state. Or for another example, if you want to change an airline ticket that is in the "booked" state, it will cost you $75. This also refers back to previous messages in this forum about resource state maybe being the key to a cleaner "session state" model. http://groups.yahoo.com/group/rest-discuss/message/1037
Sorry, but this is really late notice. Tomorrow is the last
day for comments on the FCC's proposal to call the Internet
an "information service" for the entrenched broadband
interests. Ostensibly, this decision is being made in
preference over classifying broadband internet as a
"communications medium," which would place it under
regulations like those phone companies are subject to. It
is therefore being characterized as a decision for
deregulation versus regulation.
Anybody who can, PLEASE send in a note saying this is not a
question of whether regulation or deregulation is better
policy (this is just a smokescreen) -- it's a question of
the nature of the online medium: Is it a "content" delivery
system, or a communications medium characterized by its
fundamental two-way protocols, one which brings profound new
capabilities to all citizens?
*Please* send even just a short note to the FCC at
ecfs@....
If you know any other constituencies that would want to put
a word in on this, please let them know.
From Dave Farber's Interesting People list,
farber@....
Seth Johnson
-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <dfarber@...>
-----Original Message-----
From: "David S. Isenberg" <isen@...>
Date: Thu, 02 May 2002 16:13:48
To: dave@...
Subject: Comment on NPRM 02-33
Dave,
This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write. NPRM
02-33 threatens to turn back the network architecture clock
to pre-Internet days. Please distribute it via IP as soon
as you can -- the deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.
IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc
FCC comments should follow the form below. Email them to
the FCC's Electronic Comment Filing System: ecfs@....
ECFS - E-mail Filing
<PROCEEDING> 02-33
<DATE> 5/2/02
<NAME> David S. Isenberg
<ADDRESS1> 112 Orchard Street
<ADDRESS2>
<CITY> Cos Cob
<STATE> CT
<ZIP> 06807
<LAW-FIRM> none
<ATTORNEY> none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER> 203-661-4798
<DESCRIPTION> Email Comment
<CONTACT-EMAIL>isen@...
<TEXT>
I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.
Let me introduce myself. I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech. I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff.
Today, I make my living as an independent commentator on
telecommunications. While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests. I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.
In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet. "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it. Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy). That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods. So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.
It was not always so. The telephone network was developed
to deliver one kind of information -- the human voice. It
was engineered for voice, and it gave access to voice.
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony.
The wire that came into the house could not be distinguished
from the service it provided. It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.
The great advance of the Internet was that its fundamental
architecture separated "access" from "information". Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information. Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access. As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.
Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network. No, access is a fundamentally different business
from "information service". To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.
Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s. TV-on-speed is not "the
Internet" -- and vice versa.
David I
-------
************ WE HAVE MOVED! ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------*
David S. Isenberg isen@...
isen.com, inc. 888-isen-com (inside US)
http://isen.com/ 203-661-4798 (direct line)
*--------------------isen.com----------------------*
-- The brains behind The Stupid Network --
*--------------------isen.com----------------------*
For archives see:
http://www.interesting-people.org/archives/interesting-people/
--
See <http://www.cs.umbc.edu/agentslist> for list info & archives.
My profuse apologies for this -- it appears that someone is spoofing my original email, which had been prompted by the press of circumstances. Incidentally, by the close of the comments period, the FCC had received about 630 public comments, vastly opposed to declaring broadband Internet an "information service." Seth Johnson -- [CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html
bhaugen32 wrote: > >... > > Would you have any objection to a resource representing a state? That's what resources are for. ;) 3. No Implicit State: If the client and server depend on a shared piece of information in order to communicate effectively then that piece of information should be given an address (usually by the server) and exposed as a web resource. Clients should be considered entirely stateless. The only thing they remember from one message to another are things defined by the protocol, like authentication tickets -- not things defined by the application, like purchase order numbers. Paul Prescod
Paul Prescod wrote: > > That's what resources are for. ;) > > 3. No Implicit State: If the client and server depend on a shared piece > of information in order to communicate effectively then that piece of > information should be given an address (usually by the server) and > exposed as a web resource. Clients should be considered entirely > stateless. The only thing they remember from one message to another are > things defined by the protocol, like authentication tickets -- not > things defined by the application, like purchase order numbers. This is rest-discuss right? My read of Roy's thesis (in particular 5.1.3) is that it encourages stateless servers, with clients providing all the necessary state on every request. - Sam Ruby
Sam Ruby wrote: > >... > > This is rest-discuss right? > > My read of Roy's thesis (in particular 5.1.3) is that it encourages > stateless servers, with clients providing all the necessary state on every > request. That's true at the protocol level. An HTTP server is not required to "remember" previous HTTP messages. It is not necessarily true at the application level. The Web would be useless if it were not possible to store state on web servers. How would you implement a discussion group in a completely stateless environment? Three out of the four main HTTP methods manipulate state so clearly this was always intended! Consider the three stated reasons for the requirement: "This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures [133]." These two features are preserved by the rule I stated about "No Implicit State". "Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests." This feature is also preserved *to the extent possible*. Obviously if the client is allowed to manipulate server state then you introduce the possibility of scalability problems. But there is no distributed system that can get around the fact that storing lots of data takes lots of disk space. The important thing is that the state is managed at the application, not protocol layer. HTTP just transmits the request to PUT but nothing in the HTTP specification says that an HTTP server must remember that it just handled a PUT. Only the application remembers this, if it chooses to do so. Paul Prescod
Paul Prescod wrote: > Clients should be considered entirely > stateless. The only thing they remember from one message to another are > things defined by the protocol, like authentication tickets -- not > things defined by the application, like purchase order numbers. However, if a PO number were encased in a URI, it would be ok, right? http://vendor.com/customerA/PurchaseOrders/1001/ I recognize that I am asking glaringly obvious questions. But as you saw from Sam Ruby's response, the answers are not always quite as obvious. Next step: Paul, I seem to remember you suggesting the idea of resources to represent states of sessions. I think the example you used was a travel site where your itinerary and ticket were resources with URIs so you could return to them and take subsequent actions. How far do you think this idea could be pushed? What are the drawbacks? Could it eliminate cookies and other session-management kludges? I'm also thinking of "conversation ID" and other tags in message- oriented SOAP that are addressed to hidden resources.
Paul Prescod wrote: > > Three out of the four main HTTP > methods manipulate state so clearly this was always intended! Luckily, three out of the four main HTTP methods don't account for 75% of the usage of the internet, or else we will would likely have seen a meltdown quite a ways back. ;-) > Consider the three stated reasons for the requirement: > > "This constraint induces the properties of visibility, reliability, and > scalability. Visibility is improved because a monitoring system does not > have to look beyond a single request datum in order to determine the > full nature of the request. Reliability is improved because it eases the > task of recovering from partial failures [133]." > > These two features are preserved by the rule I stated about "No Implicit > State". > > "Scalability is improved because not having to store state between > requests allows the server component to quickly free resources, and > further simplifies implementation because the server doesn't have to > manage resource usage across requests." I believe those three constraints can be satisfied by requiring that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. In short, I agree with the "No Implicit State", but I still don't see how these assersions support the conclusion that "Clients should be considered entirely stateless." - Sam Ruby
Sam Ruby wrote: > >... > > I believe those three constraints can be satisfied by requiring that each > request from client to server must contain all of the information necessary > to understand the request, and cannot take advantage of any stored context > on the server. I think you're right that they cannot take advantage of *implicitly* stored context on the server. But if the service is a discussion list it would be ridiculous if it were impossible to POST a reply to an existing message. It would be equally ridiculous for the client to try to send the *entire conversation* before it could add a single message. If the server has exposed some state as a resource then the client can rely on it. > In short, I agree with the "No Implicit State", but I still don't see how > these assersions support the conclusion that "Clients should be considered > entirely stateless." My point is that the server should make no assumptions about how much state the client is maintaining and vice versa. That is an extra implementation dependency that degrades interoperability. It should all be in the message or in resources referenced by the message. Cookies are a violation of this principle (which is probably why they aren't a W3C specification). Paul Prescod
bhaugen32 wrote: > > Paul Prescod wrote: > > Clients should be considered entirely > > stateless. The only thing they remember from one message to another > are > > things defined by the protocol, like authentication tickets -- not > > things defined by the application, like purchase order numbers. > > However, if a PO number were encased in a URI, it would be ok, right? > http://vendor.com/customerA/PurchaseOrders/1001/ Well the client wouldn't think of it as a PO number but rather as an opaque bit of a URI...if it is helpful implementation technique for the server then sure, embed a PO numbers. >... > Next step: Paul, I seem to remember you suggesting the idea of > resources to represent states of sessions. I think the example you > used was a travel site where your itinerary and ticket were resources > with URIs so you could return to them and take subsequent actions. As you know (but others may not) I said that you probably don't really need a concept of "session" at all. > How far do you think this idea could be pushed? Hard to say. I think that the whole web services world needs to figure out what is going to happen with transactions (or should clients just unroll actions?). If real transactions end up being necessary for web services then I guess a transaction is a kind of session... > What are the drawbacks? If you can't use a session ID to refer to a large body of shared context then you may end up sending more information in each message to establish context. Also resource cleanup typically will not happen automatically when a "session ends" as it might in a stateful protocol. No matter what model you use, resource cleanup is a nasty issue. > Could it eliminate cookies and other session-management kludges? IMO, cookies arise because web clients are not web servers and are not guaranteed to have any "writable" resource space. Cookies are not very good if you don't trust the servers you talk to (as you should not). Obviously there are privacy problems but also it seems clear that they could be used for a nasty denial of service -- except that they are restricted from being very large or numerous. So the standard way to prevent the DOS is to apply arbitrary limitations that restrict their utility. So I don't see the cookie solution as really scaling up to the web services world. What should happen, from a privacy and security point of view, (if not from a usability point of view) is that "client-side" state should be stored in files with URIs. Access should be granted or not explicitly. The contents should be transparent. I am amazed how many sites force cookies on me and when I turn them off the site's performance does not degrade at all. The cookie seems not to provide any advantage to me, the user, only to the marketers trying to track my progress through the site. In some ways Hailstorm was on the right track. You don't want to store state on a particular client device -- especially implicitly! I do not believe that browsers even give me an option of "exporting my cookies" so obviously no important state can be stored in them. > I'm also thinking of "conversation ID" and other tags in message- > oriented SOAP that are addressed to hidden resources. I personally don't see the value in the reifying the "conversation". It's just a short-cut that allows one message to rely on some state implicitly sent through a previous message. Just like cookies, it ties the whole conversation to a single device which may prevent modularization. Perhaps I'm missing some hidden advantage... Paul Prescod
Paul Prescod wrote: > > http://vendor.com/customerA/PurchaseOrders/1001/ > > Well the client wouldn't think of it as a PO number but rather as an > opaque bit of a URI...if it is helpful implementation technique for the > server then sure, embed a PO numbers. I don't think of it as a PO number, but that the resource is a Purchase Order...which is what I suppose you meant, too. (Continuing to be glaringly obvious so as to get explicit agreements.) > As you know (but others may not) I said that you probably don't really > need a concept of "session" at all. I had never really thought about it before until something clicked when I read one of your previous messages. I'm still trying to follow the implications, thus the next question... > > How far do you think this idea could be pushed? > > Hard to say. I think that the whole web services world needs to figure > out what is going to happen with transactions (or should clients just > unroll actions?). If real transactions end up being necessary for web > services then I guess a transaction is a kind of session... For business purposes, some kind of transactions are necessary. They are not database transactions, but for business state alignment. They wrap common business protocols: good example, offer-acceptance is the business protocol for contract (order) formation. Both trading partners must agree on whether the offer was accepted or not. Acceptance should be explicit: i.e. non-repudiable messages from each party that irrevocably connect acceptance to offer. The acceptance message may take some time, but not forever. Time constraints must apply. So I'm thinking, could this kind of business-state-alignment transaction be made into a resource itself - maybe a sub-resource of the Order? > > What are the drawbacks? > > If you can't use a session ID to refer to a large body of shared context > then you may end up sending more information in each message to > establish context. If the transaction is a resource, you will send messages to the transaction. (Does that make sense?) > Also resource cleanup typically will not happen > automatically when a "session ends" as it might in a stateful protocol. If a business transaction is made into a Web resource, what needs to be cleaned up? The transaction resources should be persistent, in some cases for years. If the transaction times out before a response, it fails (i.e. its state is "failed"). (I must be missing something here. Making this stuff all into Web resources seems so much simpler to me that somebody must have already tried and rejected it before they adopted cookies et al. Mustn't they?)
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > (I must be missing something here. Making this stuff all into Web > resources seems so much simpler to me that somebody must have already > tried and rejected it before they adopted cookies et al. Mustn't > they?) > Nope. Most system are browser based & it's 'low lying fruit' for programmers in a hurry. Thinking beyond a demo system doesn't always happen. Cookies are useful for browser based apps - but when you write your own client, you have more freedom to innovate (as it were...).
Folks. I thought folks here may find the draft Conceptual Objects spec interesting as it has RESTful qualities. http://groups.yahoo.com/group/conceptobjects/ (For now, you'll need to join the group to view the draft spec.) Robb Beal
"S. Mike Dierken" wrote: > > (I must be missing something here. Making this stuff all into Web > > resources seems so much simpler to me that somebody must have already > > tried and rejected it before they adopted cookies et al. Mustn't > > they?) > > > Nope. Most system are browser based & it's 'low lying fruit' for programmers > in a hurry. Thinking beyond a demo system doesn't always happen. How many of the Web application server environments use the concept of a session in one disguise or another? (Whether based on cookies or not.) Which ones don't? I just took a look at Seaside, a Web app server for Squeak. The designers seem to be trying to rethink a lot of stuff. Including a continuation-passing idea. But still - they plan to have sessions. http://beta4.com/seaside
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, No offence meant, but could you at least put an abstract up somewhere, before requiring people to subscribe to a list? Bill de hra > -----Original Message----- > From: macdug_dc [mailto:macdug_dc@...] > Sent: 09 May 2002 19:00 > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Conceptual Objects Spec > > > Folks. > > I thought folks here may find the draft Conceptual Objects spec > interesting as it has RESTful qualities. > > http://groups.yahoo.com/group/conceptobjects/ > > (For now, you'll need to join the group to view the draft spec.) > > Robb Beal > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> Tied to your PC? Cut Loose and Stay > connected with Yahoo! Mobile > http://us.click.yahoo.com/QBCcSD/o1CEAA/sXBHAA/W6uqlB> /TM > > > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPNq/u+aWiFwg2CH4EQId9ACdEWO82Ob5tOu8/NOZ4mRl1tGtBxMAoNQL Y4gkHPMkjl9kDXtfuiIlNOm6 =HTVj -----END PGP SIGNATURE-----
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > > How many of the Web application server environments use the concept > of a session in one disguise or another? > (Whether based on cookies or not.) Most do. "Give the People What They Want". It messes up scalability (adding nodes to a cluster) and starts to require 'sticky routing' (getting a request to go to the same physical place as previous requests, in order to have a high 'cache hit ratio') and other tricky designs. Many app servers also have 'session replication' which copies transient session data across the cluster - kind of like writing it to a central database, but not really. I don't know the driving need for server session data, other than it being one approach for performance optimization. There may be a real need there - especially for UI based apps - but I'm not very familiar with it. > Which ones don't?
> No offence meant, but could you at least put an abstract up > somewhere, before requiring people to subscribe to a list? Yah, really. FWIW, I joined and looked at it. It's basically the HTML LINK element in XML. I'll be "unjoining" soon. 8-) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Sessions and statelessness aren't mutually exclusive, so long as the session in which the message exists is part of the message. That makes the *interaction* stateless, which is the important thing. MB
Mark Baker wrote: > Sessions and statelessness aren't mutually exclusive, so long as the > session in which the message exists is part of the message. That makes > the *interaction* stateless, which is the important thing. Thanks. I understand your position vs statelessness. But do you think sessions are *necessary*? Or can they (always or usually) be replaced by Web resources? And is that transformation (always or usually) better? We discussed this once before, in the context of EDI-mailbox-style SOAP, where messages have "conversation" and "transaction" tags. In that discussion, (I think) we agreed that these tags could be replaced by making the subjects of the conversation into Web resources with URIs. And that there were advantages to the transformation: from one centralized mailbox with a dispatcher, to individual addresses for each conversational subject. I'm trying to explore whether REST yields a better/simpler architecture for the problems that sessions and conversation tags were supposed to solve.
Mark Baker wrote: > > Sessions and statelessness aren't mutually exclusive, so long as the > session in which the message exists is part of the message. That makes > the *interaction* stateless, which is the important thing. Well put. One thing I haven't seen mentioned in this thread - there are two popular ways to have session support. One is cookies, the other is URL munging. In the latter, all interactions can be done via HTTP GET, and there is little or no assumptions made about the capabilities of the client. Some would - based on this description alone - declare such a solution RESTful. The reality is that such an approach uses URL to identify not just resources, but also comingles in the concept of context. - Sam Ruby
On Thu, May 09, 2002 at 07:03:34PM -0000, bhaugen32 wrote: > But do you think sessions are *necessary*? For some things, yes. > Or can they (always or usually) be replaced by Web resources? > And is that transformation (always or usually) better? I don't see why you can't do both. e.g. POST http://foo.org/foo Content-Type: application/foo+xml Transaction: http://foo.org/txn/24234234324 [body] You'd only interact with the transaction resource if you wanted to checkpoint (GET) or rollback (PUT). Otherwise it's just an opaque transaction identifier. > We discussed this once before, in the context of EDI-mailbox-style > SOAP, where messages have "conversation" and "transaction" tags. > In that discussion, (I think) we agreed that these tags could be > replaced by making the subjects of the conversation into Web > resources with URIs. > > And that there were advantages to the transformation: from one > centralized mailbox with a dispatcher, to individual addresses for > each conversational subject. I don't remember that conversation exactly. But I recall mentioning possible "CHECKPOINT" and "ROLLBACK" methods, though I decided that GET and PUT could be used instead. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > But do you think sessions are *necessary*? > > For some things, yes. For example? (I'm not arguing, just thinking about it.) > > We discussed this once before, in the context of EDI-mailbox- style > > SOAP, where messages have "conversation" and "transaction" tags. > > In that discussion, (I think) we agreed that these tags could be > > replaced by making the subjects of the conversation into Web > > resources with URIs. > > > > And that there were advantages to the transformation: from one > > centralized mailbox with a dispatcher, to individual addresses for > > each conversational subject. > > I don't remember that conversation exactly. But I recall mentioning > possible "CHECKPOINT" and "ROLLBACK" methods, though I decided that GET > and PUT could be used instead. http://groups.yahoo.com/group/rest-discuss/message/1094 http://groups.yahoo.com/group/rest-discuss/message/1095 BH: >> So if I make the Order into a Web resource, created by >> the initial POST, then all subsequent POSTs or GETs are >> addressed either to that Order resource or one of its >> sub-resources (LineItems, Deliveries, Invoices, Payments, etc.) >> I consider Transactions to be business entities, >> so they could be sub-resources. >> So I no longer have one gateway URI with a dispatcher behind it, >> I am directly addressing the relevant business resource. >> Does this make sense to anybody else? MB: > Yep, that's exactly my thinking too. > Plus, because you're identifying the mailbox at a more > granular level than just a catch-all mailbox, GET, PUT, > and DELETE makes sense. By the way, when I use the word "transaction" here, I mean "business state alignment" not database. So there is no rollback. The resources just fail to advance to the next state.
Incident Information:- Originator: jsalzman <jsalzman@....> Recipients: rest-discuss@yahoogroups.com Subject: [rest-discuss] Hello,questionnaire Message from jsalzman <jsalzman@....> was quarantined because it contained a banned type of file attachment which could carry a potential virus.
Okay, the subject is a somewhat misleading, but I like to tease Paul once in a while. I've been thinking about what the ultimate HTTP web would be like and what kind of tools would be nice for developers to have to work with it - especially in relation to the cool tools that SOAP developers find valueable. The cool tool for me is the intellisense/popup thingee in editors. With pure hypertext, this can be done fairly easily - in fact MS Windows does this for file system browsers - you type something in the address bar of File Explorer or a common file dialog and it pops up choices. (of course Unix command line file completion has been doing this for several years.) It doesn't take a rocket scientist to hack a web browser to do this for HTTP - fetch the page and show the list of anchors with href's that match (which will fail miserably on the 'real web' because everybody uses javascript... whatever). The drawback to hypertext discovery is that it is instance based. The resources identifiers have to already exist in order to discover them. You can't talk about things outside their lifetime - before they exist or after they are removed. To program the 'idealized web' from the kind of development environements that many people like it seems that a blending of instance based and 'pattern based' discovery (the generative naming JeffB talked about) would be ideal for the programmer. The popup thingee would be really useful when its too hard or you're too lazy to build a decent discovery system. I'm not too conversant with WSDL, so maybe it can do a large part of this - or maybe a mix of pure URI discovery and WSDL may be useful. What do you think Paul?
"S. Mike Dierken" wrote:
>
> Okay, the subject is a somewhat misleading, but I like to tease Paul once in
> a while.
"Why is everybody always picking on me?"
>...
>
> The drawback to hypertext discovery is that it is instance based.
This is where I disagree. The hypertext instance is an instance of a
document type defined by a schema. It is demonstrably possible to drive
popups from schemas -- Visual Studio.NET does this already. The primary
reason that WRDL has stalled is because I haven't figured out a way to
preserve the extensive processing that these environments already
provide and add the tiny extra bit you need to view URI-bearing elements
as hyperlinks rather than end-nodes. But even without the extra juice of
WRDL one can do hyperlink-following processing using WSDL.
class PurchaseOrder extends WebServiceProxy{
// this class was generated from the WSDL
...
AnyURI rec;
}
class CustomerRecord extends WebServiceProxy{
// this class was generated from the WSDL
...
}
po = new PurchaseOrder("http://....some...url")
customer = new CustomerRecord(po.rec);
Now you'll get all of the popups on the customer object.
The only inconvenient thing here is that I've had to *tell the system*
that the AnyURI is really a CustomerRecord as opposed to having it
figure out from the schema. Arguably this degrades type safety (but then
the type safety was always an illusion because you can't control the
type of data returned by the other system).
I'm not 100% sure if this addresses the gist of your concern because I
don't see how pattern-based identifiers would help. The question is
whether you have the information you need available at design time or
not. With pattern-based systems you presumably have some regular
expression language or something. With XML you have schemas.
Paul Prescod
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the rest-discuss group. File : / Click Here! Uploaded by : randyphillipsar <randyphillipsar@...> Description : No matter what your credit is like ,there is a card here for you! You can access this file at the URL http://groups.yahoo.com/group/rest-discuss/files/%20Click%20Here%21 To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, randyphillipsar <randyphillipsar@...>
On Thu, May 09, 2002 at 08:35:28PM -0000, bhaugen32 wrote: > Mark Baker wrote: > > > But do you think sessions are *necessary*? > > > > For some things, yes. > > For example? (I'm not arguing, just thinking about it.) Anything transactional. > By the way, when I use the word "transaction" here, I mean "business > state alignment" not database. So there is no rollback. The > resources just fail to advance to the next state. Rollback could still be attempted. It doesn't mean it has to successful, but just knowing that it isn't may be useful information to signal that that some compensatory type action needs to be taken. But if it does work, then that's even better! MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@... http://www.markbaker.ca http://www.planetfred.com
Mark Baker wrote: > > > > But do you think sessions are *necessary*? > > > > > > For some things, yes. > > > > For example? (I'm not arguing, just thinking about it.) > > Anything transactional. Question for you: what do you mean by "transactional"? I tried to explain what I mean below. I don't think anything like the database concept of a transaction is appropriate across trust boundaries. (I thought from earlier comments that you agreed.) Clarification of my earlier question: I don't deny that sessions may be the best way to go sometimes. The question was if they are actually necessary, that is, if you can't get the same results from making the interaction into a resource some way. Possibly dumb way: make the transaction itself into a resource. (Or maybe not so dumb...) > > By the way, when I use the word "transaction" here, I mean "business > > state alignment" not database. So there is no rollback. The > > resources just fail to advance to the next state. > > Rollback could still be attempted. It doesn't mean it has to > successful, but just knowing that it isn't may be useful > information to signal that that some compensatory type action > needs to be taken. But if it does work, then that's even better! But what would you roll back? (Or maybe, what situations do you have in mind where rollback would be an appropriate concept?) Example: in an offer-acceptance transaction, let's say the offer starts out in a "pending" state. If the transaction ends normally, the offer advances to the "accepted" state or the "rejected" state depending on the response. If the transaction does not end normally (times out, etc.) the offer is still "pending". No rollback, it just doesn't change to either "accepted" or "rejected" - although the practical equivalent of "rejected" might be inferred. In RosettaNet (and ebXML copying RNet) there is a "Notification of Failure" that is sent via a different channel in cases where the end of the transaction might not be clear to both parties. It's a compensatory action. Might be considered rollback if one party had thought the transaction succeeded. I know RNet and ebXML are EDI-mailbox-style, but they also pretty closely adhere to commercial law and customs, so there are some real business requirements behind their ways of doing things. So I'm trying to see if I can get the same adherance to commercial law and customs from a purely REST configuration, and in this case, with no sessions or conversation or transaction dispatch tags. There are reasons for wanting to do this that I could try to explain if they are not obvious. I'm still not sure how far it is necessary or wise to push the idea, thus these questions on this forum where people seem to know how to think about it.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > The drawback to hypertext discovery is that it is instance based. > > This is where I disagree. The hypertext instance is an instance of a > document type defined by a schema. By 'instance based' I meant 'instance of a resource'. You can't get the URI to a resource before the resource exists. Actually, you can, if the server decides the URI. In the case of PUT, the client decides the URI - but that might be problematic in general. The client could use POST to request that a new resource be created and the server can report what that server-generated URI is - I suppose that would solve that problem. > > I'm not 100% sure if this addresses the gist of your concern because I > don't see how pattern-based identifiers would help. The question is > whether you have the information you need available at design time or > not. With pattern-based systems you presumably have some regular > expression language or something. With XML you have schemas. The pattern could be XML or something. Doesn't have to a 'grep' like language.
Hi everyone,
I am new to the list so please excuse me if I am repeating questions.
Background - At work we need to implement a way of reading and
writing data to our existing Java trading application. We are in
close collaboration with the external parties who will be using this
functionality. Others are proposing that we use SOAP. I feel the REST
approach will offer more flexibility in the future, allowing the data
to be accessed, linked and manipulated in ways not yet though of,
whereas SOAP would constrain the use of data to the API exposed.
My questions are:
1) Are there any open-source tools that can help with implementing a
Java RESTful interface? Does anyone have any Java implementation
experience to share?
2) The SOAP proponents at work are proposing the use of Apache Axis
as a SOAP server implementation. Does anyone have experience with
Axis?
3) The SOAP proponents think the extensible SOAP header adds
flexibility, a place to put transaction metadata or security related
information. Does REST have an answer to these requirements?
4) We need a way for an external application to store or modify a
trade in our application. I would be interested in any feedback on
the following resource modeling ideas:
4a) To store a new trade, either a two step communication:
-> HTTP GET request
to //host/trades/newtradeuri
or //host/trades?newtradeuri
<- HTTP response would contain server-generated URI:
//host/trades/123
or //host/trades?id=123
-> HTTP PUT request containing trade XML
to //host/trades/123
<- HTTP response indicating success
Or perhaps do it in one step:
-> HTTP POST request containing trade XML
to //host/trades/newtrade
or //host/trades
<- HTTP response would contain server-generated URI:
//host/trades/123
4b) To modify an existing trade:
-> HTTP PUT request containing trade XML
to //host/trades/122
<- HTTP response indicating success
4c) To read an existing trade:
-> HTTP GET request
to //host/trades/122
<- HTTP response containing trade XML
4d) Within a trade XML instance some information would be represented
as a link to the resource containing the complete information. For
example:
<trade>
<counterparty href="https//host/counterparties/12"/>
<broker href="https//host/brokers/34"/>
...
</trade>
5) Given the requirements outlined in (4), which would you recommend:
the REST approach above, or the use of SOAP with an API containing
methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade
().
Look forward to any feedback.
Regards,
Robert McKinnon
On Tue, May 14, 2002 at 08:11:44PM -0000, xemplify wrote: > 1) Are there any open-source tools that can help with implementing a > Java RESTful interface? Does anyone have any Java implementation > experience to share? In my experience, the Servlet APIs, now part of Jakarta, provide an excellent framework for RESTful app development. > 2) The SOAP proponents at work are proposing the use of Apache Axis > as a SOAP server implementation. Does anyone have experience with > Axis? I've looked at the APIs, but haven't used it. From what I can see, it's pretty much the same as any other SOAP API out there; difficult to use in a REST based environment where you're using other HTTP methods and features at the same time. > 3) The SOAP proponents think the extensible SOAP header adds > flexibility, a place to put transaction metadata or security related > information. Does REST have an answer to these requirements? Headers. HTTP headers, in the case of HTTP. > 4) We need a way for an external application to store or modify a > trade in our application. I would be interested in any feedback on > the following resource modeling ideas: [snip] > Or perhaps do it in one step: > -> HTTP POST request containing trade XML [snip] > or //host/trades > > <- HTTP response would contain server-generated URI: > //host/trades/123 I like that one. > 4b) To modify an existing trade: > -> HTTP PUT request containing trade XML > to //host/trades/122 > > <- HTTP response indicating success Right. > 4c) To read an existing trade: > -> HTTP GET request > to //host/trades/122 > > <- HTTP response containing trade XML Right again. > 4d) Within a trade XML instance some information would be represented > as a link to the resource containing the complete information. For > example: > > <trade> > <counterparty href="https//host/counterparties/12"/> > <broker href="https//host/brokers/34"/> > ... > </trade> Exactly. You don't have to use "href" though; you can use your own linking system, or XLink, or RDF. > 5) Given the requirements outlined in (4), which would you recommend: > the REST approach above, or the use of SOAP with an API containing > methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade > (). You have to ask? 8-) MB -- Mark Baker, CTO Idokorro Mobile Inc. Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> > 4b) To modify an existing trade: > > -> HTTP PUT request containing trade XML > > to //host/trades/122 > > > > <- HTTP response indicating success > > Right. Would POST be more appropriate here since you're modifying an existing resource? Doesn't PUT imply that you're giving the whole representation of a resource to the server? Jason
On Tue, May 14, 2002 at 06:23:35PM -0700, Jason Diamond wrote: > > > 4b) To modify an existing trade: > > > -> HTTP PUT request containing trade XML > > > to //host/trades/122 > > > > > > <- HTTP response indicating success > > > > Right. > > Would POST be more appropriate here since you're modifying an existing > resource? That depends *how* it's being modified. If the client knows the desired state of the trade, then PUT is the correct method. > Doesn't PUT imply that you're giving the whole representation of a > resource to the server? Depends what you mean by "whole". But in this case, it sounded to me like the client had a complete representation, presumably because it previously did a GET on it. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote: > > > > 4b) To modify an existing trade: > > > > -> HTTP PUT request containing trade XML > > > > to //host/trades/122 > > > > > > > > <- HTTP response indicating success > > > > > > Right. > > > > Would POST be more appropriate here since you're modifying an > > existing resource? > > That depends *how* it's being modified. If the client knows the > desired state of the trade, then PUT is the correct method. The client is receiving confirmations of trades from an exchange, and needs to programmatically enter them in our system. The trade may need modification because of a mistake; effectively the client wants to store a complete new version of the trade, hence the use of PUT (though old versions are retained, so perhaps POST more relevant?). This brings up an interesting point: probably clients would like to be able to access old versions of a trade. What would be a good way of doing this? Ideas: 1) To get the latest version: -> HTTP GET //host/trades/122 returns latest version of the trade XML e.g. <trade id="122" version="5"> ... Maybe links to the older versions could also be provided in the latest version? 2) To get an older version -> HTTP GET //host/trades/122?version=2 or -> HTTP GET //host/trades/122/2 returns the trade XML for the second version. Versions are a history of the resource's state. Which is preferred, using a query based off the existing URI or a new URI? Thanks, Robert McKinnon
"S. Mike Dierken" wrote: > > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > > > > The drawback to hypertext discovery is that it is instance based. > > > > This is where I disagree. The hypertext instance is an instance of a > > document type defined by a schema. > By 'instance based' I meant 'instance of a resource'. You can't get the URI > to a resource before the resource exists. It's like saying you can't get a pointer to an object before it exists. So what? You know the object's class and you know the document's schema. Or you would, if you use a service description language that allows you to strongly type URI references...or you could use RDF Schema. > ... Actually, you can, if the server > decides the URI. In the case of PUT, the client decides the URI - but that > might be problematic in general. Except in a content management environment, the client should PUT to a URI provided by the server. In "web services", the server owns the namespace. > ... The client could use POST to request that a > new resource be created and the server can report what that server-generated > URI is - I suppose that would solve that problem. Yes, that's how I think it should work. Otherwise how would the client choose the URI?? > > > > I'm not 100% sure if this addresses the gist of your concern because I > > don't see how pattern-based identifiers would help. The question is > > whether you have the information you need available at design time or > > not. With pattern-based systems you presumably have some regular > > expression language or something. With XML you have schemas. > The pattern could be XML or something. Doesn't have to a 'grep' like > language. Nevertheless, it is a curently non-existent language versus a small extension to XML Schema for strongly typed URIs. Paul Prescod
xemplify wrote: > >... > > 1) Are there any open-source tools that can help with implementing a > Java RESTful interface? Does anyone have any Java implementation > experience to share? Make the point that EVERY web application development tool (Servlets, Zope, WebLogic) has a strong RESTful component. > 2) The SOAP proponents at work are proposing the use of Apache Axis > as a SOAP server implementation. Does anyone have experience with > Axis? Not really. I know Google used it. They reported success but at the same time said they had to hack it to support all of their potential client libraries. > 3) The SOAP proponents think the extensible SOAP header adds > flexibility, a place to put transaction metadata or security related > information. Does REST have an answer to these requirements? As Mark said: HTTP headers. But also XML itself is extensible whether you use SOAP or not. > 4) We need a way for an external application to store or modify a > trade in our application. I would be interested in any feedback on > the following resource modeling ideas: > > 4a) To store a new trade, either a two step communication: > -> HTTP GET request > to //host/trades/newtradeuri > or //host/trades?newtradeuri Bad, because non-idempotent GET. >.. > Or perhaps do it in one step: > -> HTTP POST request containing trade XML > to //host/trades/newtrade > or //host/trades > > <- HTTP response would contain server-generated URI: > //host/trades/123 Great! >.... > 5) Given the requirements outlined in (4), which would you recommend: > the REST approach above, or the use of SOAP with an API containing > methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade > (). Sounds like a perfect REST application to me! If you need consulting to help convince them I'll halve my normal rate. ;) Paul Prescod
On 5/15/02 11:00 AM, "Paul Prescod" <paul@...> wrote: > >> By 'instance based' I meant 'instance of a resource'. You can't get the URI >> to a resource before the resource exists. Mike, you might as well give up on this one, it's precisely the same issue as the generative naming stuff we were "discussing" earlier and Paul seems ideologically incapable of giving on this point. ;-) > > It's like saying you can't get a pointer to an object before it exists. Yes, but you *can* **name** things that don't exist, or don't exist yet. And if you know how to build such names, your domain of possible discourse in your application is much larger. Jb
----- Original Message ----- From: "xemplify" <xemplify@...> > The trade may need modification because of a mistake; effectively the > client wants to store a complete new version of the trade, hence the > use of PUT (though old versions are retained, so perhaps POST more > relevant?). This gets into 'collections' of resources. Both PUT and POST can create new resources - but you have to be careful with using PUT to do this. With POST, you are sending the new resource, with PUT, the old resource is moved out to the new resource. POST typically responds with the location of the new resource, PUT doesn't have to because it only visibly replaces the old resource (and the client already knows that URI). The problem with rolling off versions when a PUT happens is idempotency - what happens if you PUT twice? do you get two backup versions? You can use E-Tag stuff to tell if this incoming data is the same as the current resource, but that requires more coordination between client and server. So... neither method fits very well. I'd suggest you use PUT and consider the duplicate message case carefully. > 2) To get an older version > -> HTTP GET //host/trades/122?version=2 > or > -> HTTP GET //host/trades/122/2 > returns the trade XML for the second version. > Versions are a history of the resource's state. Which is preferred, > using a query based off the existing URI or a new URI? <yoda>There is no query. There is only URI.</yoda> Both are full URI - the portion before the '?' character is the 'path'. The question mark is used when you have to generate URIs on the client & you have a declarative form to do that - like <form> for html. Creating the URI works in a pinch, but the more complete solution is to have the server report the versions available (in xml or something) and then the specific URI format becomes unimportant. Rather than knowing the syntax with slashes and question marks, you need to know the names (or paths) of elements within XML (or whatever infoset/grove you use). A more practical answer to your question is "depends on your server technology". I have found path-based URI to be treated as second-class citizens in many server environments (clients that generate URI based on user input also typically don't do path based stuff very well), so I'd suggest query terms (even though I personally like paths better). If you have a flexible server-side environment (like servlets) then path based is fine. A few years ago I wrote a java servlet-based framework that was very path based and dispatched methods into java objects identified by the path - the query terms became parameters. It's at http://xml.apache.org/xang/ if you are interested in digging into old code (it works fine, its just not used by anybody - look into the packages around org.apache.xang.net.http.object.HTTPObjectServer )
Paul Prescod wrote: > >> 2) The SOAP proponents at work are proposing the use of Apache Axis >> as a SOAP server implementation. Does anyone have experience with >> Axis? > > Not really. I know Google used it. They reported success but at the same > time said they had to hack it to support all of their potential client > libraries. Google used Apache SOAP 2.2. They applied a patch from what will be included in Apache SOAP 2.3 to support the diversity of values people use to represent boolean. They also disabled remote administration. - Sam Ruby
A resource can be identified before it exists. For example, at the recent AC meeting, the IRC logs of the minutes were given HTTP URIs before the meeting took place. This is a very useful side effect of permitting 404s. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, May 15, 2002 at 02:24:30PM -0000, xemplify wrote: > > That depends *how* it's being modified. If the client knows the > > desired state of the trade, then PUT is the correct method. > > The client is receiving confirmations of trades from an exchange, and > needs to programmatically enter them in our system. > > The trade may need modification because of a mistake; effectively the > client wants to store a complete new version of the trade, hence the > use of PUT (though old versions are retained, so perhaps POST more > relevant?). Versioning can be done with PUT. See the recent WebDAV versioning work; http://www.ietf.org/rfc/rfc3253.txt MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Jeff Bone wrote: > > On 5/15/02 11:00 AM, "Paul Prescod" <paul@...> wrote: > > > > >> By 'instance based' I meant 'instance of a resource'. You can't get the URI > >> to a resource before the resource exists. > > Mike, you might as well give up on this one, it's precisely the same issue > as the generative naming stuff we were "discussing" earlier and Paul seems > ideologically incapable of giving on this point. ;-) It isn't the same issue at all. Mike says that you CANNOT statically type a URI-described resource before the URI. Do you agree that this is impossible? > > > > It's like saying you can't get a pointer to an object before it exists. > > Yes, but you *can* **name** things that don't exist, or don't exist yet. You aren't listening. Of course you can't get a pointer to an object before it exists. But you CAN statically declare the object before you have a pointer to it. And it is the static declaration that drives "popups" in editor tools. The same goes for URI references and XML. > And if you know how to build such names, your domain of possible discourse > in your application is much larger. I'll believe that when I see an application that demonstrates it. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > It isn't the same issue at all. Mike says that you CANNOT statically > type a URI-described resource before the URI. Do you agree that this is > impossible? That's not what I was saying. I don't have a problem with discovering the data definition of a resource before any instances exist. I'm only concerned with discovering what the URI for the future resource is. To clarify, I was saying that you can't get a list of resources from a server and expect that list to contain the URI for the resource you are about to create. I want to PUT a comment to a discussion group - what URI should I use? How do I use hyperlinking to discover the URI of the resource that I want to create? Doing discovery on the resource representing the discussion group will not provide the URI desired. Doing some other process is needed - GET on a 'gimme the next uri please' resource followed by PUT, using POST and having the server respond with the URI, etc. It seems that PUT should only be used for update and not create - you still have to have the server determine the URI and use a multi-step operation or a different method. A client & server that have priviliged knowledge can coordinate on the URI structure - and I'm fine with that - but I don't think the broadest scope, most general solution would take that approach. > You aren't listening. Of course you can't get a pointer to an object > before it exists. But you CAN statically declare the object before you > have a pointer to it. Is this static declaration describing the structure of the state of a resource? I know that getting the definition of the structure of a resource is easy - but once I fill in the blanks, where do I PUT the data?
Can someone who was at the ETCon session on REST and SOAP give a summary? Wes Felter said it was "entertaining" but there was very little logged in IRC. -- Ken
Hi, I'm in the process of prototyping a REST version of an existing RPC based system, a large chunk of this system revolves around efficiently managing updates to content at the client system. I'm looking at using the HTTP/1.1 caching support (Etag, If-Modified- Since, If-None-Match and If-Range). I have some questions about how this works when deployed on a cluster of servers with a load balancer, is this a good place to ask, or can someone recommend a good list to discuss HTTP caching. Tx Simon
On 17 May 2002, Ken MacLeod wrote: > Can someone who was at the ETCon session on REST and SOAP give a > summary? Wes Felter said it was "entertaining" but there was very > little logged in IRC. > > -- Ken Not very productive. In general the horse-race story about REST vs. SOAP is overshadowing meaty stuff. EG, there seemed to be a grudge match setup about Paul's Google article on xml.com.
...the most useful point from the con WRT REST is emerging consensus that web services has nothing to do with the web. It's fine for what it is, which is more or less EDI.
Have you tried www-talk@... ? ----- Original Message ----- From: "simonfell99" <sf@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, May 17, 2002 10:00 AM Subject: [rest-discuss] HTTP caching questions ? > Hi, > > I'm in the process of prototyping a REST version of an existing RPC > based system, a large chunk of this system revolves around > efficiently managing updates to content at the client system. I'm > looking at using the HTTP/1.1 caching support (Etag, If-Modified- > Since, If-None-Match and If-Range). I have some questions about how > this works when deployed on a cluster of servers with a load > balancer, is this a good place to ask, or can someone recommend a > good list to discuss HTTP caching. > > Tx > Simon > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Lucas Gonze wrote: > > Not very productive. In general the horse-race story about REST vs. SOAP > is overshadowing meaty stuff. EG, there seemed to be a grudge match setup > about Paul's Google article on xml.com. IMHO, the discussion about meatier stuff is hampered by the types of rhetoric we saw at the panel - remember when I took notes and then cited a stream of terms like "democratrization", "no virtues", "binary would have been just as good", etc? It would be much more productive (again, IMHO) if we could talk in terms of specifics suggestions. I also believe that most of the asserted virtues of either an all-GET (or even a more-GET) approach seem to be stated in ways that go over the head of most of the intended audience - even when we had a VERY technical audience like we enjoyed at the ETCON. The one point that I'm most proud of is when I contrasted SOAP vs REST vs GET approaches in what I thought was a more digestible form. I was pleasantly surprised that I got no pushback from those sitting to my right, in fact after the panel you seemed to indicate that I had not misrepresented REST. If others who had attended feel that this part was comprehendable beyond the scope of the people sitting on the panel, I will try to write it up. - Sam Ruby
I think it would be great if you asked the questions here. I am not "deep" in HTTP cacheing but I know that Mark Nottingham is and I suspect Mark Baker knows quite a bit also. This list seems to be the last refuge of people who don't think of HTTP as a dinosaur ;). simonfell99 wrote: > > Hi, > > I'm in the process of prototyping a REST version of an existing RPC > based system, a large chunk of this system revolves around > efficiently managing updates to content at the client system. I'm > looking at using the HTTP/1.1 caching support (Etag, If-Modified- > Since, If-None-Match and If-Range). I have some questions about how > this works when deployed on a cluster of servers with a load > balancer, is this a good place to ask, or can someone recommend a > good list to discuss HTTP caching. > > Tx > Simon > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"S. Mike Dierken" wrote: > >... > That's not what I was saying. I don't have a problem with discovering the > data definition of a resource before any instances exist. I got confused because you were asking about popups in an IDE and the relevance of WSDL. To be blunt, I think your question has evolved over the course of the messages. ;) > ... To clarify, I was saying that you can't get a list of resources from a > server and expect that list to contain the URI for the resource you are > about to create. I want to PUT a comment to a discussion group - what URI > should I use? You want to POST a message to a discussion group? Use POST! It can return a URI. Is there a hitch I don't see? > It seems that PUT should only be used for update and not create - you still > have to have the server determine the URI and use a multi-step operation or > a different method. In general I would agree with that, but there is a subtlety. In some situations (particularly content management) the client owns the namespace and the server just puts things where the client asks. Paul Prescod
> Can someone who was at the ETCon session on REST and SOAP give a > summary? Wes Felter said it was "entertaining" but there was very > little logged in IRC. From a "getting stuff done" point of view, the thing was doomed from the start. I had always had a sense that that was the case but I figured that it was better than nothing. Many of the other talks presumed a SOAP future so I thought it important that there be a session that at least questioned that theory. But consider that the same day of the session, Rohit Khare gave a talk on an alternate model for web services (not REST (despite the fact that he claims it is a superset of REST), not RPC and not traditional messaging). He had 45 mins. He hardly had time in that period to explain the idea and he didn't have a single slide showing an angle bracket or network transmission. He didn't even describe, really, how SOAP supports his model. (i.e. from a technical point of view it was mostly hand waving) Now contrast that with five guys trying to educate an audience and debate a model *at the same time* in 45 mins, with no slides, while constantly interrupting each other, with differing agenda. All you could hope for is to get across the idea that there is a debate and that the audience should look on the web for more information. That much was accomplished. Insofar as the burden of proof was on the REST guys (as we were suggesting something different from the mainstream) I would expect that a neutral observer would say that the REST case was NOT made. In the last five minutes I hinted at the foundations of the REST case but only an extremely charitable audience member would catch the whiff of that and follow up through more research on the Web. ==== I also found it frustrating that Rohit quoted a definition of REST that was not complete. I did not have opportunity to correct him but he used his definition as a basis for the statement that he was the only one who knew what REST is. In particular, his more generic definition allowed him to say that SOAP (and particularly, SOAP Routing, his hobby horse) was an extension of REST. Whereas when I compare his talk (and the SOAP spec) against the definition I use, I see almost no points of intersection: "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." Neither SOAP nor SOAP Routing have first-class concepts of resources, resource identifiers, representations of resources, or hypermedia. And I would argue that the following typical SOAP message is not self-descriptive but rather self-contradictory: POST /foo/bar <SOAP-crap> <getStockQuote>IBM</getStockQuote> </SOAP-crap> Is it posting information or getting information? The points the other four speakers made were relatively predictable if you've followed our arguments across the various fora. Paul Prescod
Paul Prescod wrote: > > I also found it frustrating that ... [snip] > > <SOAP-crap> > <getStockQuote>IBM</getStockQuote> > </SOAP-crap> What I find frustrating is the consistent, continued, and entirely unnecessary use of such derogatory terms. Quite frankly, it makes a rational discourse on the subject impossible. - Sam Ruby
[sorry, this is a little long because it summarizes a variety of conversations we've had recently] Sam Ruby wrote: > >... > > IMHO, the discussion about meatier stuff is hampered by the types of > rhetoric we saw at the panel - remember when I took notes and then cited a > stream of terms like "democratrization", "no virtues", "binary would have > been just as good", etc? It would be much more productive (again, IMHO) if > we could talk in terms of specifics suggestions. I can itemize my complaints: * Shouldn't run at "level 8" but rather level 6 (on top of TCP, below app protocols) * Shouldn't use port 80 (in fact shouldn't have a predefined port at all) * Shouldn't use an envelope format that is hostile to binary data * Encoding should be separated out into a differently named spec and rethought from scratch. * RPC should probably be just removed. * Should have as a design requirement that it is a solid basis for application protocols like a next generation HTTP or SMTP (i.e. the HTTP binding for SOAP should be HTTP *over SOAP* not SOAP over HTTP) * Should use IP addresses rather than URIs for addressing (resource addressing is an application layer issue) I may have forgotten some but you get the gist. Generally, when you have so many complaints about a technology the easier way to say it is: "It's all wrong." That offends people but it also saves their time. >... > I also believe that most of the asserted virtues of either an all-GET (or I don't think anybody on this list would promote an all-GET approach unless the service was read-only. > even a more-GET) approach seem to be stated in ways that go over the head > of most of the intended audience - even when we had a VERY technical > audience like we enjoyed at the ETCON. I agree that that is the case. If you do not have a background of thinking about information systems as addressable information spaces (many XML people do, most others don't) then it requires a mental change like the shift from procedural programming to event-driven programming. Some (probably not Sam) feel that this demonstrates that the information-space model is doomed. My sense is that people make mental leaps when they need to, to solve a problem. Over the next few years it will become clear whether this mental leap is really necessary or just convenient for some problems. Object orientation took about twenty-five years to overcome industry inertia and filter out to a point where ordinary people understand it. > The one point that I'm most proud of is when I contrasted SOAP vs REST vs > GET approaches in what I thought was a more digestible form. I was > pleasantly surprised that I got no pushback from those sitting to my right, > in fact after the panel you seemed to indicate that I had not > misrepresented REST. Well Dave Winer spoke after you so I didn't really have a chance to jump in. Different people have different definitions, just as they do about OO. Jeff Bone focuses on consistency of interfaces. I focus on addressability. IIRC, you focused on using the HTTP methods properly. I don't think any of the definitions are right or wrong, they just address different but related aspects. I focus on addressability because of my information-space background and because I feel that it is a particularly obvious weak point of the standard web services stack. Even COM and CORBA have much more interoperable addressing models than SOAP. You said that there was a third camp that said to "use GET for everything." That's a misunderstanding of REST but I don't know that it is any more pervasive than other misunderstandings, like "use POST for everything" (after all, as long as you use HTTP without SOAP you are doing REST, right?). Some people also think that REST means "asynchronous messaging". i.e. people think that whatever they like that is not SOAP must be REST. ;) BTW, you mentioned the Amazon associates API. From what I could see on Simon's page it *was* relatively REST-y. I am not an Amazon associate so I can't see the details of their API. Simon's summary is here: * http://www.xmlhack.com/read.php?item=1615 I feel bad that I had to disclaim responsibility for it because I didn't mean to leave the Amazon people looking silly (I know they were in the audience). If there are parts of the API that use GET to mean PUT, POST or DELETE then I would agree that those parts aren't REST-y. The parts I can see look like a good start towards full REST-yness. > If others who had attended feel that this part was comprehendable beyond > the scope of the people sitting on the panel, I will try to write it up. My sense is that just as with OO, there are a variety of correct ways to summarize the REST model. Your approach would probably be a valuable addition. Paul Prescod
I have posted my first release of a tutorial on REST[1]. I would appreciate it if you would notify me if you notice any mistakes, or have suggestions on things to add, or suggestions on how to improve it. Thanks! /Roger [1] http://www.xfront.com/REST.ppt
Paul Prescod wrote: > > I can itemize my complaints: I could try to do a point by point rebuttal, but for now, the following will suffice: > * Shouldn't use port 80 (in fact shouldn't have a predefined port at > all) It doesn't. - Sam Ruby
Looks like an excellent summary! I'll just go through some nits.
Here are some points to consider.
Slide 5:
"http://www.parts-depot.com/parts-list?flavor=xml"
A hard-core HTTP-head would suggest you use content negotiation instead.
* http://www.prescod.net/http/content_negotiation.html
Slide 8:
I don't think I'd make PartQuantity into a resource type. I'd make
*Part* into a resource type. Quantity would be just an element in there.
This could collapse your part list into a simple list of URIs and
prevent the slightly weird linking from the PartQuantity back into the
Part.
Slide 9:
SOAP is not an application protocol so it doesn't prescribe much of a
data model (roughly the same data model as UDP -- there are things you
can send messages to) This makes it hard to assess the "SOAP Way" of
doing any particular thing. Really it is SOAP toolkits and WSDL that
most clearly say what you can and cannot do easily with SOAP. In
particular, the SOAP specification does not say that an entire service
must be served off of a particular URI (even if it is strongly implied).
I doubt that the most popular SOAP toolkits are well set-up to allow
dynamically created SOAP endpoints so practically speaking the "SOAP
way" is accurate but you should know the difference between what SOAP
requires and what it "strongly suggests".
Slide 11:
You say: "Note the absence of
links. Why is this?
Links use HTTP GET,
but SOAP only supports
HTTP POST."
I don't think that's quite the way to put it.
Given an HTTP URI, it is possible to treat it as either an HTTP resource
or a SOAP endpoint. If you decide to treat it as an HTTP resource then
that part of your service is REST-ful. If you decide to treat it as a
SOAP endpoint then you have a problem: what method do you use to resolve
it to some actual information? You can't look in the WSDL because WSDL's
describes one and only one endpoint, not the relationship between
endpoints. Even if you had the WSDL available, how would you know which
of the methods to use? Unless there were some "GET-ter" annotation in
WSDL, you don't know.
Slide 16:
"As a result of REST having a common interface any client can use any
service without prior coordination."
There is a little bit of subtlety here. Any HTTP client can talk to any
HTTP server. This is mostly true also of SOAP, except for the fact that
SOAP runs on a bunch of transports so you also have to get the transport
right.
But in either case the more important question is whether you can do
anything useful without prior coordination. Here's a document I've
written about that:
* http://www.prescod.net/rest/standardization.html
Slide 19:
"SOAP is simply an XML version of CORBA/DCOM/RMI"
That's the case for SOAP RPC but for SOAP in general, I predict SOAP
advocates would say:
1. The "big problem" with CORBA was that Microsoft didn't support
it. The "big problem" with DCOM was that it doesn't work on Unix. The
problem with Java RMI is that it doesn't work with non-Java programming
languages. Everyone agrees on SOAP so the network effects can kick in.
(not the level of network effects we get from HTTP, but better than the
network effects from proprietary RPC protocols)
2. SOAP inherits the extensibility of XML and this allows "loose
coupling". It also allows non-RPC message exchange patterns --
particularly asynchronous ones.
Slide 21:
There should probably be a Meerkat WSDL. I'll look into that one day.
Meerkat could be even better if it had a way to do discovery by
hyperlink navigation rather than just queries.
Paul Prescod
Thanks a lot Paul! I have incorporated all of your suggestions, as well as added new material. I think that my Parts Depot example is now in line with your suggestion. If you (or anyone else) has comments on it I would very much appreciate hearing them. All suggestions, criticisms are welcome. /Roger http://www.xfront.com/REST.ppt Paul Prescod wrote: > > Looks like an excellent summary! I'll just go through some nits. > > Here are some points to consider. > > Slide 5: > > "http://www.parts-depot.com/parts-list?flavor=xml" > > A hard-core HTTP-head would suggest you use content negotiation instead. > > * http://www.prescod.net/http/content_negotiation.html > > Slide 8: > > I don't think I'd make PartQuantity into a resource type. I'd make > *Part* into a resource type. Quantity would be just an element in there. > This could collapse your part list into a simple list of URIs and > prevent the slightly weird linking from the PartQuantity back into the > Part. > > Slide 9: > > SOAP is not an application protocol so it doesn't prescribe much of a > data model (roughly the same data model as UDP -- there are things you > can send messages to) This makes it hard to assess the "SOAP Way" of > doing any particular thing. Really it is SOAP toolkits and WSDL that > most clearly say what you can and cannot do easily with SOAP. In > particular, the SOAP specification does not say that an entire service > must be served off of a particular URI (even if it is strongly implied). > I doubt that the most popular SOAP toolkits are well set-up to allow > dynamically created SOAP endpoints so practically speaking the "SOAP > way" is accurate but you should know the difference between what SOAP > requires and what it "strongly suggests". > > Slide 11: > > You say: "Note the absence of > links. Why is this? > Links use HTTP GET, > but SOAP only supports > HTTP POST." > > I don't think that's quite the way to put it. > > Given an HTTP URI, it is possible to treat it as either an HTTP resource > or a SOAP endpoint. If you decide to treat it as an HTTP resource then > that part of your service is REST-ful. If you decide to treat it as a > SOAP endpoint then you have a problem: what method do you use to resolve > it to some actual information? You can't look in the WSDL because WSDL's > describes one and only one endpoint, not the relationship between > endpoints. Even if you had the WSDL available, how would you know which > of the methods to use? Unless there were some "GET-ter" annotation in > WSDL, you don't know. > > Slide 16: > > "As a result of REST having a common interface any client can use any > service without prior coordination." > > There is a little bit of subtlety here. Any HTTP client can talk to any > HTTP server. This is mostly true also of SOAP, except for the fact that > SOAP runs on a bunch of transports so you also have to get the transport > right. > > But in either case the more important question is whether you can do > anything useful without prior coordination. Here's a document I've > written about that: > > * http://www.prescod.net/rest/standardization.html > > Slide 19: > > "SOAP is simply an XML version of CORBA/DCOM/RMI" > > That's the case for SOAP RPC but for SOAP in general, I predict SOAP > advocates would say: > > 1. The "big problem" with CORBA was that Microsoft didn't support > it. The "big problem" with DCOM was that it doesn't work on Unix. The > problem with Java RMI is that it doesn't work with non-Java programming > languages. Everyone agrees on SOAP so the network effects can kick in. > (not the level of network effects we get from HTTP, but better than the > network effects from proprietary RPC protocols) > > 2. SOAP inherits the extensibility of XML and this allows "loose > coupling". It also allows non-RPC message exchange patterns -- > particularly asynchronous ones. > > Slide 21: > > There should probably be a Meerkat WSDL. I'll look into that one day. > Meerkat could be even better if it had a way to do discovery by > hyperlink navigation rather than just queries. > > Paul Prescod
--- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote: > I have posted my first release of a tutorial on REST[1]. I would > appreciate it if you would notify me if you notice any mistakes, > or have > suggestions on things to add, or suggestions on how to improve it. > Thanks! /Roger > > [1] http://www.xfront.com/REST.ppt I'm very interested in reading your tutorial. Unfortunately I haven't worked out how to view ppt files in Linux yet, nor do I think I should have to. So reading your tutorial will have to wait until I next boot an operating system that has an application that can view that proprietary format. Perhaps your REST tutorial resource URI should follow REST principles? ;) Then I could: GET /rest/tutorial?flavor=html HTTP/1.1 Host: www.xfront.com or following Paul's content negotiation suggestion: GET /rest/tutorial HTTP/1.1 Host: www.xfront.com Accept: text/plain, text/html and hopefully get a version of the tutorial that my browser can render. Regards, Robert
xemplify wrote: > > ... > > Perhaps your REST tutorial resource URI should follow REST > principles? ;) Or Google could expose a REST interface to their PPT->HTML rendering engine. ;) Paul Prescod
On Sun, May 19, 2002 at 05:09:15PM -0000, xemplify wrote: > > I have posted my first release of a tutorial on REST[1]. I would > > I'm very interested in reading your tutorial. Unfortunately I haven't > worked out how to view ppt files in Linux yet, nor do I think I should > have to. I agree you shouldn't have to, but if you want to, StarOffice/OpenOffice and KPresenter have PowerPoint import filters. I haven't used them a whole lot, but to the extent I have the results are usually imperfect but readable. Though KPresenter seems to be choking on this particular file. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Sam Ruby wrote: > > Paul Prescod wrote: > > > > I also found it frustrating that ... [snip] > > > > <SOAP-crap> > > <getStockQuote>IBM</getStockQuote> > > </SOAP-crap> > > What I find frustrating is the consistent, continued, and entirely > unnecessary use of such derogatory terms. Quite frankly, it makes a > rational discourse on the subject impossible. I won't apologize, because I think that that's pretty par for the course on technical mailing lists on the Internet. After all, you aren't SOAP and SOAP isn't you. Therefore I haven't insulted you. Nevertheless, since it bothers you I'll try to be more ecumenical in posts that I expect you to see. Still, there have been occasions where you have taken my statements of fact as rhetoric. For instance, when I say that a Java client generated from a WSDL+HTTP client can be byte-for-byte the same as one generated from a WSDL+SOAP client, that's just a statement of fact. When I say that Google's service would have become very popular (as long as they documented it and provided Java client libraries) even if it had been based upon S-expressions or binary or totally proprietary XML, that's a statement of opinion, but not, in my mind, empty rhetoric. Paul Prescod
Sam Ruby wrote: > >... > > I could try to do a point by point rebuttal, but for now, the following > will suffice: > > > * Shouldn't use port 80 (in fact shouldn't have a predefined port at > > all) > > It doesn't. If you use the SOAP HTTP binding and you do not choose a port explicitly, it uses port 80 by default. It shouldn't. It should run underneath the application protocol and let the application protocol pick the port. Paul Prescod
First the nits:
* a more "RESTful" version of the xlink:href would expose the part as a
part of the path and not merely as a query expression. In other words,
I'd suggest replacing:
xlink:href="http://www.parts-depot.com/part?id=00345
with
xlink:href="http://www.parts-depot.com/part/00345
* Soap encoding tends to favor usage of the element content over
attributes. I'd suggest changing your example for getPartsListResponse
from:
<part id="00345">
to
<part-id>00345</part-id>
= = = =
The next point is a bit more subtle. I've tried to express it in a number
of different forums in a number of different ways, each time with little
success. I'm not going to try a bit of humor to see if it helps.
It is a bit ironic that a set of architectural practices under the title of
"Representation State Transfer" defines virtually nothing about the way in
which state is to be represented, and instead focuses on how Objects (or
more precisely, resources) are to be accessed.
Similarly, I find it a bit ironic that a protocol originally created as an
acronym for Simple Object Access Protocol specifies nothing about how an
object is to be accessed, but instead focuses pretty much exclusively on
how messages are to be represented. For more details on this subject, see
http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html
It is very easy to come up with an example where one schema includes links
and other does not, associate the first with a URL and place the second in
an envelope and then portray this as a fundamental difference between SOAP
and REST. The truth is that HTTP nor SOAP require nor preclude "proper"
links.
Similarly, one can come up with an example where a resource is identified
based on query parameters in a URL and another in which a resource is
identified inside the body and portray this too as a fundamental
difference. This too is false as there are a number of SOAP toolkits which
will happily dispatch requests based on the URL. Furthermore, REST is an
architectural style - it does not dictate syntax. See
http://www.xent.com/pipermail/fork/2001-August/002941.html for more on this
topic, including the views of Roy Fielding on XML itself.
I will go a step further and indicate that it is possible to architect a
system in accordance to the principles of REST and then implement it using
SOAP. In other words, these two are compatible. I would argue that the
deeper issue is that SOAP does little to require such an architectural
style, in fact, most of the examples to date seem to espouse a different
architectural style. I discuss this further in
http://www.oreillynet.com/cs/weblog/view/wlg/1351#Analogy
= = = =
The reason I joined this mailing list, and have persisted, is that it is
my hope that some day a paper can be jointly authored which shows both SOAP
and REST in a positive light, shows the strengths of both, and how they can
be used in concert.
- Sam Ruby
Hi On Sun 19-May-2002 at 11:49:13 -0600, Matt Gushee wrote: > > I agree you shouldn't have to, but if you want to, > StarOffice/OpenOffice and KPresenter have PowerPoint import filters. I > haven't used them a whole lot, but to the extent I have the results > are usually imperfect but readable. Though KPresenter seems to be > choking on this particular file. I didn't have any luck with it either using OpenOffice (got the lines and boxes but no text). Generally I find that the free office viewers from MS running in wine are often the best way to view .ppt and .doc files. Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
Sam Ruby wrote:
>
>...
>
> It is a bit ironic that a set of architectural practices under the title of
> "Representation State Transfer" defines virtually nothing about the way in
> which state is to be represented, and instead focuses on how Objects (or
> more precisely, resources) are to be accessed.
>
> Similarly, I find it a bit ironic that a protocol originally created as an
> acronym for Simple Object Access Protocol specifies nothing about how an
> object is to be accessed, but instead focuses pretty much exclusively on
> how messages are to be represented. For more details on this subject, see
> http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html
Interesting point.
> It is very easy to come up with an example where one schema includes links
> and other does not, associate the first with a URL and place the second in
> an envelope and then portray this as a fundamental difference between SOAP
> and REST. The truth is that HTTP nor SOAP require nor preclude "proper"
> links.
True. But HTTP defines a way to transform a URI into bit stream (GET
$URI). SOAP does not.
> Similarly, one can come up with an example where a resource is identified
> based on query parameters in a URL and another in which a resource is
> identified inside the body and portray this too as a fundamental
> difference. This too is false as there are a number of SOAP toolkits which
> will happily dispatch requests based on the URL.
That is certainly true for URLs known at "deploy time". But I do not
believe that it is true for URLs invented at runtime. For instance if I
do a createStockTicker("RUBY") message, can any existing SOAP toolkit
return:
<NewTickerURI>http://www...../RUBY</NewTickerURI>
And then have the client do method calls against the newly created
endpoint. WSDL certainly does not support strongly and statically type
declaring this interaction. That's its biggest flaw when it comes to
REST.
> .... Furthermore, REST is an
> architectural style - it does not dictate syntax.
That's absolutely true. I've thought about the idea of a REST-on-SOAP
and found a few problems:
1. in order for us to achieve economies of scale, we must agree on
syntax. If half of the world uses REST-HTTP and half uses REST-SOAP then
we will have problems talking to each other.
2. Who is going to go to the effort of creating REST-SOAP? If it isn't
people who were involved with HTTP, are they likely to get it right?
3. REST-on-SOAP would not combine the best virtues of HTTP and SOAP.
One of HTTP's virtues as an envelope is that it is data type agnostic.
It is as happy to carry binary as text. XML wasn't engineered for that.
Therefore I don't see XML is a good choice for an envelope format.
* http://www.prescod.net/xml/envelopes/
4. I don't personally like the SOAP encoding much (IMO, confusing and
complicated) and there are a variety of choices for XML-based object
encoding out there. So I don't see SOAPENC as much of a "win".
5. If the default transport for SOAP will be HTTP then we'll have SOAP
running on HTTP and something HTTP-like running on SOAP. We'll be up to
"layer 9" in the protocol stack and layer 7 will be totally useless --
just a firewall-evasion technique.
> I will go a step further and indicate that it is possible to architect a
> system in accordance to the principles of REST and then implement it using
> SOAP. In other words, these two are compatible. I would argue that the
> deeper issue is that SOAP does little to require such an architectural
> style, in fact, most of the examples to date seem to espouse a different
> architectural style. I discuss this further in
> http://www.oreillynet.com/cs/weblog/view/wlg/1351#Analogy
I think that my point 1 is crucial. If Sam Ruby architects a system
according to REST principles using a SOAP syntax that Sam Ruby invents,
and Paul Prescod architects a system according to REST principles
according to a SOAP syntax that Paul Prescod invents, etc., then we have
no economies of scale and all of the virtues of REST are lost. We only
win if we agree. One way to agree is to say: "Use HTTP". Another way to
agree is to invent HTTP-on-SOAP-on-HTTP and then say "use that". If
three years from now we decide that we really can't convince people to
use HTTP then probably we will have to reinvent it two levels up ("Web
Services Resource Manipulation Language") and then we could launch a
buzzword offensive around it, rewrite all of the existing software two
levels up and become IPO millionaires. Wait a second, why didn't I like
that idea again?
Nevertheless, you are right that syntax is just syntax. HTTP could be
reinvented in SOAP syntax and if we all adopted it we would get all of
the advantages of REST. You would lose some aspects of the HTTP syntax
(e.g. straightforward binary handling) but that wouldn't be major.
> = = = =
>
> The reason I joined this mailing list, and have persisted, is that it is
> my hope that some day a paper can be jointly authored which shows both SOAP
> and REST in a positive light, shows the strengths of both, and how they can
> be used in concert.
Actually, I am interested in this also, but I have a feeling that we
would disagree on the virtues of SOAP. Nevertheless, it would be
illuminating for me to hear your list of what SOAP has to offer REST.
Paul Prescod
I have created an HTML version of my REST tutorial: http://www.xfront.com/REST.html All suggestions, criticisms are welcome. /Roger
ok, here goes. Basically i need to support efficient checks that content is upto date, and to also support resumable downloads [some of the content is large binary files accessed via a potentially un-reliable low bandwidth connection]. This content is potentially served by a set of web servers running behind a HTTP load balancer. For a single server scenario, this seems pretty straightforward, At the client cache I track expected size [from the content-length header], Etag and last-modified. for subsequent requests I populate a If-None-Match header from the etag, a Range & Range-If header if the expected size is not the same as the cached file size, and i send a If-Modified-Since header if i don't have a Range header [my reading of the use of Range & Range-If lead me to believe to not use If-Modified-Since if i'm using ranges]. My concern is when i have 2 or more web servers, all running behind a load balancer [local director etc], that each server will be assigning different etags to the same content (i don't see anything in the spec that lets me assume different server instances will generate the same etag for the same content, even for the same versions of HTTP server software). This is leading me to think about not using etags, and to just use the modified date, but then it doesn't look like you can do ranges with modified dates. Its also crossed my mind to use content-md5, but this doesn't seem very widely support [if at all]. Any suggestions ? Thanks Simon Saturday, May 18, 2002, 1:50:51 PM, you wrote: > I think it would be great if you asked the questions here. I am not > "deep" in HTTP cacheing but I know that Mark Nottingham is and I suspect > Mark Baker knows quite a bit also. This list seems to be the last refuge > of people who don't think of HTTP as a dinosaur ;). > simonfell99 wrote: >> >> Hi, >> >> I'm in the process of prototyping a REST version of an existing RPC >> based system, a large chunk of this system revolves around >> efficiently managing updates to content at the client system. I'm >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- >> Since, If-None-Match and If-Range). I have some questions about how >> this works when deployed on a cluster of servers with a load >> balancer, is this a good place to ask, or can someone recommend a >> good list to discuss HTTP caching. >> >> Tx >> Simon >> >> >> To unsubscribe from this group, send an email to: >> rest-discuss-unsubscribe@yahoogroups.com >> >> >> >> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Paul Prescod wrote:
>
> Interesting point.
Whoah!
Are the lines of communication cracking open, if even a tiny bit?
;-)
> For instance if I
> do a createStockTicker("RUBY") message, can any existing SOAP toolkit
> return:
>
> <NewTickerURI>http://www...../RUBY</NewTickerURI>
>
> And then have the client do method calls against the newly created
> endpoint.
Would Axis count? When Axis is deployed as a servlet, one can map a
url-pattern to the AxisServlet. One can then deploy a transport specific
handler which obtains the relative path and does something appropriate with
that information.
> WSDL certainly does not support strongly and statically type
> declaring this interaction. That's its biggest flaw when it comes to
> REST.
Several points. First, WSDL need not be strongly typed. I provide a
complete and working example of this in
http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html.
Second, it is possible that a WSDL could be generated dynamically for such
URLs. And finally, WSDL is not required.
> I've thought about the idea of a REST-on-SOAP
> and found a few problems
I won't go point by point through these at this time. I feel that you do
have a legitimate beef about SOAP over HTTP, but continue to make
distracting and somewhat irrelevant points, and I would like to focus first
on the core issues. For example, a position that SOAP over HTTP should
never be used is one that I see as internally self consistent, but not one
that says that HTTP should have a default port, but SOAP over HTTP should
not.
The next step is to discuss the relationship between HTTP and REST. There
are not synonymous. In particular, there are quite a number of uses of
HTTP that are inconsistent with REST, including most CGI based
applications, and by implication most servlets, ASPs, ColdFusion
applications, PHP applications and the like. And don't even begin to
mention cookies...
Yet none of these seem to inspire the vitriol that SOAP has received.
> Actually, I am interested in this also, but I have a feeling that we
> would disagree on the virtues of SOAP. Nevertheless, it would be
> illuminating for me to hear your list of what SOAP has to offer REST.
Again, I think we need to separate REST and HTTP first. And establish that
HTTP is not the one answer to every question.
A good place to start that discussion is with Don Box's observations:
http://zdnet.com.com/2100-1105-845220.html
- Sam Ruby
Very nice, Roger. Some comments; - slide 9, I'd avoid using fragment identifiers. Better to just use /part/23234 or /part?id=23234 - slide 18, REST allows for extension methods beyond GET/PUT/POST/DELETE, so long as the method is applicable to all resources - slide 19, you might also want to mention that security is also better with REST because it is well known what the methods mean - slide 21, I think you mean "Web", not "Internet" MB
On Sun, May 19, 2002 at 08:41:04PM -0400, Sam Ruby wrote: > The next step is to discuss the relationship between HTTP and REST. There > are not synonymous. So far, so good, but ... > In particular, there are quite a number of uses of > HTTP that are inconsistent with REST, including most CGI based > applications, and by implication most servlets, ASPs, ColdFusion > applications, PHP applications and the like. Where do you get that idea? I don't claim to be a REST wizard, but I've been following this discussion for 3 months, and I haven't known anyone to suggest such a thing. In fact, one of the core principles of REST as I understand it is that the implementation of a REST resource is opaque to the client, which implies that it would be quite appropriate to generate a representation using any of the above technologies. Or are you referring to the fact that CGI apps and such tend to use a lot of query strings? But that's really a matter of common usage, not an intrinsic feature of any of those technologies. And it seems to me that the consensus--to the extent there is one--is that query strings are discouraged because they obscure the relationships between resources, but are by no means forbidden. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Matt Gushee wrote: > > So far, so good, but ... > >> In particular, there are quite a number of uses of >> HTTP that are inconsistent with REST, including most CGI based >> applications, and by implication most servlets, ASPs, ColdFusion >> applications, PHP applications and the like. > > Where do you get that idea? I don't claim to be a REST wizard, but I've > been following this discussion for 3 months, and I haven't known anyone > to suggest such a thing. In fact, one of the core principles of REST as > I understand it is that the implementation of a REST resource is opaque > to the client, which implies that it would be quite appropriate to > generate a representation using any of the above technologies. > > Or are you referring to the fact that CGI apps and such tend to use a > lot of query strings? But that's really a matter of common usage, not > an intrinsic feature of any of those technologies. And it seems to me > that the consensus--to the extent there is one--is that query strings > are discouraged because they obscure the relationships between resources, > but are by no means forbidden. http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html This was written by the same Roy T. Fielding that wrote: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Sam Ruby
Sam Ruby wrote:
>
>...
> > For instance if I
> > do a createStockTicker("RUBY") message, can any existing SOAP toolkit
> > return:
> >
> > <NewTickerURI>http://www...../RUBY</NewTickerURI>
> >
> > And then have the client do method calls against the newly created
> > endpoint.
>
> Would Axis count? When Axis is deployed as a servlet, one can map a
> url-pattern to the AxisServlet. One can then deploy a transport specific
> handler which obtains the relative path and does something appropriate with
> that information.
Is this simple or rocket science? Maybe you could write a tutorial one
day.
> > WSDL certainly does not support strongly and statically type
> > declaring this interaction. That's its biggest flaw when it comes to
> > REST.
>
> Several points. First, WSDL need not be strongly typed. I provide a
> complete and working example of this in
> http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html.
>
> Second, it is possible that a WSDL could be generated dynamically for such
> URLs. And finally, WSDL is not required.
WSDL is not required in a theoretical sense but it is in a practical
sense. Deploying WSDL-less web services will become increasingly
difficult over the next few months. Already XMethods does not support
WSDL-less services. Java and .NET programmers will start screaming
bloody murder if you don't give them WSDLs compatible with "wsdl.exe"
and "wsdl2java". They will not be happy with WSDLs that are not strongly
typed. IMO, WSDL is for strong, static type declarations. Generating it
dynamically, or declaring things anyType remove its value.
> > I've thought about the idea of a REST-on-SOAP
> > and found a few problems
>
> I won't go point by point through these at this time. I feel that you do
> have a legitimate beef about SOAP over HTTP, but continue to make
> distracting and somewhat irrelevant points, and I would like to focus first
> on the core issues. For example, a position that SOAP over HTTP should
> never be used is one that I see as internally self consistent, but not one
> that says that HTTP should have a default port, but SOAP over HTTP should
> not.
"Applications communicate with the transport protocols through the use
of 'ports' which are unique I/O identifiers used by the ransport
protocols and hte specific instance of the application protocol."
"Just as every device on an IP network has a unique IP address, every
instance of every application protocol also has a unique port number
that is used to identify it to the transport protocols on the local
system."
* "Internet Core Protocols"
It is my belief that a protocol should have a port number if and only if
it is an application protocol. I define application protocol as a
protocol that has a concept of:
a) addressable data objects
b) standardized methods on those data objects
c) standardized semantics for those methods
This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for
SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP,
DCOM, and RMI should have ports. For instance if you use SOAP and WSDL
to define the Astronomical Data Interchange Protocol then it should have
a port. If you use them to define the Supermodel Scheduling Protocol,
that should have a port too. The fact that they have different ports
would allow system administrators to do different different kinds of
filtering on different ports.
For instance, virus checking on HTTP is relatively easy because there
are only a couple of different ways to *directly* represent a binary
attachment in HTTP. But then XML-RPC adds another. And SOAP adds two or
three more (base64, SwA, DIME). The "multiplexing" of the multiple
protocols on the same port makes system administration more difficult.
"Party at port 80."
> The next step is to discuss the relationship between HTTP and REST. There
> are not synonymous. In particular, there are quite a number of uses of
> HTTP that are inconsistent with REST, including most CGI based
> applications, and by implication most servlets, ASPs, ColdFusion
> applications, PHP applications and the like. And don't even begin to
> mention cookies...
There are varying degrees of compatibility with REST. I don't know how
to count "most" CGIs etc. There are a ton out there that are mostly
RESTful, like Google, Mapquest, Expedia, Slashdot, Wiki. All over the
Web I see URIs of the form
http://..../foo.php?some_other_stuff
They are obeying the REST principle of "identification of resources" and
"hypermedia as the engine of application state." They adhere to the
other REST constraints basically for free by using HTTP.
> Yet none of these seem to inspire the vitriol that SOAP has received.
It is not possible to prevent all people everywhere from abusing a
protocol. I'm not that much of a windmill tilter. But it should be
possible to prevent the standards body tasked with the advancement of
the Web from canonizing a specification that abuses the Web protocol.
There are also sociological reasons to dislike a specification handed
down from a smoke-filled room to be rubber stamped by the masses,
whether it makes technical sense or not. But note that the sociological
problems only started to bother me when I came to recognize the
technical shortcomings. WSDL will stay in my good graces if it fixes its
technical problems although it also came from a smoke-filled room.
> > Actually, I am interested in this also, but I have a feeling that we
> > would disagree on the virtues of SOAP. Nevertheless, it would be
> > illuminating for me to hear your list of what SOAP has to offer REST.
>
> Again, I think we need to separate REST and HTTP first. And establish that
> HTTP is not the one answer to every question.
I am willing to grant that HTTP is not the answer to every question.
Then we can move on to the next part of the conversation. ;)
> A good place to start that discussion is with Don Box's observations:
> http://zdnet.com.com/2100-1105-845220.html
We discussed that before you came to rest-discuss. If you can stand to
go through Yahoo's increasingly intrusive interfaces:
* http://groups.yahoo.com/group/rest-discuss/message/799
Summary: You can build synchrony on top of asynchrony or vice versa. You
can build reliable-but-inefficient on top of unreliable-but-efficient
(though not vice versa!).You can build bidirectional on top of
unidirectional or vice versa. Anyhow, if you want to go out and define a
REST-friendly protocol that selects a different set of defaults than
HTTP, by all means do that. I think it will lose out on some network
effects but it still might be a tecnically interesting protocol.
SOAP does not, in my mind, represent forward progress in that direction.
SOAP "handles" asynchrony by delegating it down to the underlying
transport protocol. SOAP handles REST (and addressing, and method
standardization) by delegating it up to the application level. In
increasingly mainstream usage, SOAP "handles" type declarations by
delegating them XML Schema and WSDL. So if I want to build an
asynchronous system why don't I directly use WSDL-described-XML-on-SMTP
or something like that? You're the best person on the list to tell me
what value I get out of SOAP.
Paul Prescod
Paul Prescod wrote: > >> Would Axis count? When Axis is deployed as a servlet, one can map a >> url-pattern to the AxisServlet. One can then deploy a transport specific >> handler which obtains the relative path and does something appropriate with >> that information. > > Is this simple or rocket science? Maybe you could write a tutorial one > day. My current feeling is that whatever I write - even if it directly addresses a question or concern you have expressed - you will pick it apart and call it names, so forgive me if I continue to seek to confirm to my satisfaction that there is the possibility of finding common ground before proceeding on this suggestion. Meanwhile, here are two pointers if you would like to pursue it further. http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/webapps/axis/WEB-INF/web.xml http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/src/org/apache/axis/handlers/http/URLMapper.java > "Applications communicate with the transport protocols through the use > of 'ports' which are unique I/O identifiers used by the ransport > protocols and hte specific instance of the application protocol." > > "Just as every device on an IP network has a unique IP address, every > instance of every application protocol also has a unique port number > that is used to identify it to the transport protocols on the local > system." > > * "Internet Core Protocols" > > It is my belief that a protocol should have a port number if and only if > it is an application protocol. I define application protocol as a > protocol that has a concept of: > > a) addressable data objects > b) standardized methods on those data objects > c) standardized semantics for those methods > > This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for > SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP, > DCOM, and RMI should have ports. My perception is that amazon.com's shopping basket is an application built upon HTTP. Care to comment? > Summary: You can build synchrony on top of asynchrony or vice versa. I view that statement as akin to the statement that all computers are Turing complete. A true statement, but one that misses a number of important subtleties. - Sam Ruby
----- Original Message -----
From: "Sam Ruby" <rubys@...>
>
> It is a bit ironic that a set of architectural practices under the title
of
> "Representation State Transfer" defines virtually nothing about the way in
> which state is to be represented, and instead focuses on how Objects (or
> more precisely, resources) are to be accessed.
I don't think that many architectures define representations. You know -
'architecture' 'design' 'implementation' - there is a reason that there are
three different words... I don't think it is a pedantic/semantic argument
either. Other architectures ('event based integration', 'remote procedure
call') do not define the details - a particular design or implementation of
the architecture does (there are several RPC systems that have different
representations - yet they are all recognizably 'rpc').
As an implementation of a large-scale system that exhibits the
characteristics enumerated by REST - HTTP does define the way in which state
is represented by the protocol: content-type, content-length, accept, etc..
The architecture does not constrain which representations to use, only that
you must use some and be clear about what representation you are using.
--- In rest-discuss@y..., Matt Gushee <mgushee@h...> wrote: > > In particular, there are quite a number of uses of > > HTTP that are inconsistent with REST, including most CGI based > > applications, and by implication most servlets, ASPs, ColdFusion > > applications, PHP applications and the like. > > Where do you get that idea? I don't claim to be a REST wizard, but > I've been following this discussion for 3 months, and I haven't > known anyone to suggest such a thing. In fact, one of the core > principles of REST as I understand it is that the implementation > of a REST resource is opaque to the client, which implies that > it would be quite appropriate to generate a representation > using any of the above technologies. ASP.NET webforms for one always use POST regardless of whether its apropriate. Cheers Simon
S. Mike Dierken wrote:
>
>> It is a bit ironic that a set of architectural practices under the title of
>> "Representation State Transfer" defines virtually nothing about the way in
>> which state is to be represented, and instead focuses on how Objects (or
>> more precisely, resources) are to be accessed.
>>
> I don't think that many architectures define representations. You know -
> 'architecture' 'design' 'implementation' - there is a reason that there are
> three different words... I don't think it is a pedantic/semantic argument
> either. Other architectures ('event based integration', 'remote procedure
> call') do not define the details - a particular design or implementation of
> the architecture does (there are several RPC systems that have different
> representations - yet they are all recognizably 'rpc').
Agreed.
I am actually trying to tease out the distinction between REST and HTTP. I
see people outraged when SOAP uses POST when it could have equally validly
used GET. Few of these people seem outraged when GET is used in a
non-idempotent manner. In many cases, this makes me wonder if the thing
most people find appealing is actually the concept of a URI and not of the
underlying architecture or even the validity of the usage of HTTP.
In contrast, I find the statement in the Rest Wiki
(http://conveyor.com/RESTwiki/moin.cgi/RestArchitecturalStyle) that Rest
most closely resembles tuplspaces - an architecture in which there is no
identifiable resources, and one in which all routing is based on content.
A vision which is not terribly dissimilar from the one that Adam Bosworth
exposes at
http://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/default.asp
- Sam Ruby
----- Original Message ----- From: "Sam Ruby" <rubys@...> > > I am actually trying to tease out the distinction between REST and HTTP. I would like to see these two in counterpoint also. Comparisons of other systems to the facets of REST can help illuminate - for example a comparison of RDBMS systems with aspects of REST and the reasons they differ. I'd also like to see a 'how to use REST with JMS' - I belived that would foster discussion of the architectural issues separate from HTTP. > I see people outraged when SOAP uses POST when it could have equally validly > used GET. Few of these people seem outraged when GET is used in a > non-idempotent manner. Probably because 99% of the time it is used correctly, and all architectural and design discussions talk about using GET correctly - the 1% (or so) of abusers aren't considered restless heathens mainly because people do it out of ignorance or desparation and most understand the issues once they are explained and fix it themselves. The protocol isn't broken, the servers aren't broken - people are just used in a non-conformant way. Promoting at the design, implementation and cultural level a non-conformant use is more of a catastrophe. Kind of like if I suggested a shortened end-tag syntax for soap to cut down on size - like </> instead of </end-tag>. I wouldn't have to get it in the spec, I'd just check the code into Apache code base and let people choose use it when they wanted better performance. Nothing wrong with that is there? The programmers would like it... faster parsing, less memory... > In many cases, this makes me wonder if the thing > most people find appealing is actually the concept of a URI and not of the > underlying architecture or even the validity of the usage of HTTP. The URI basis is probably the single greatest strength of the Web. All else could be trimmed and there would be value there - without the other aspects of REST it won't be as strong or as complete, but if you are constrained for time or resources in coming up with an architecture it may be a viable approach. Or if you are implementing an isolated system, at least using the URI aspect of REST (and the Web) provides a lot of value. For example, if you use JMS to implement an event notification system you can easily pick a JMS property for the 'resource id' that the message is 'about'. Subscriptions can match against this header and do things. Distributed session caches can start listening and start purging their data - a nice add-on benefit. But then you have to start saying more about the message, like did the resource change or not. Then you get into op-codes, and how do you tell the cache which operations imply a read vs write vs delete from the point of view of the cache... and so on. You end up working toward the features identified by REST - the underlying architecture of the Web, regardless of the validity of using HTTP.
S. Mike Dierken wrote: > >> I see people outraged when SOAP uses POST when it could have equally validly >> used GET. Few of these people seem outraged when GET is used in a >> non-idempotent manner. > > Probably because 99% of the time it is used correctly, and all architectural > and design discussions talk about using GET correctly - the 1% (or so) of > abusers aren't considered restless heathens mainly because people do it out > of ignorance or desparation and most understand the issues once they are > explained and fix it themselves. The protocol isn't broken, the servers > aren't broken - people are just used in a non-conformant way. Care to comment on frames and cookies? - Sam Ruby
Sam Ruby wrote: > >... > > My current feeling is that whatever I write - even if it directly addresses > a question or concern you have expressed - you will pick it apart and call > it names, so forgive me if I continue to seek to confirm to my satisfaction > that there is the possibility of finding common ground before proceeding on > this suggestion. I was only trying to get a more accurate sense of whether it was feasible to use SOAP in a URI-sensible manner in the real world. Everything I've heard so far says that it is quite difficult with existing toolkits. If you want to provide a counter-example, so be it. If not, that's fine too. >... > > > > This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for > > SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP, > > DCOM, and RMI should have ports. > > My perception is that amazon.com's shopping basket is an application built > upon HTTP. Care to comment? Amazon.com's shopping basket is a software application built on top of the HTTP application protocol. The addressing model and methods for the application come from the HTTP application protocol. HTTP does not address the payload syntax but neither do (nor can!) NNTP, POP, IMAP or the other application protocols. > > Summary: You can build synchrony on top of asynchrony or vice versa. > > I view that statement as akin to the statement that all computers are > Turing complete. A true statement, but one that misses a number of > important subtleties. Which subtleties in particular do you feel are relevant? Paul Prescod
----- Original Message ----- From: "Sam Ruby" <rubys@...> > > Care to comment on frames and cookies? Frames are an issue with a particular representation language (html) and the client(s) built to handle it. I don't know of any aspect of the protocol that explicitly deals with frames. Frames are a way to deal with the gap between the idealized 'resource model' approach supportable by HTTP and the 'user-interaction model' approach supported by browser client apps and familiar with many developers - coupled with server-side technology that didn't always support dynamically creating representations easily. A server-side-include/template mechanism pretty much removes the need for client-side frames. Frames as 'client-side-includes' (paul - correct me on the terminology) were used when you didn't have server-side-includes. Other representation languages and clients do not need to follow the html/frameset approach. Cookies - in my opinion - are a valid approach to provide stateful applications without making the protocol stateful (which would be a Bad Thing). Their use grew outside this problem space and started to take on things better provided by the protocol - like user identification (cookies with sessionId) and resource identification (I've seen redirect locations, 'next page', etc in cookies). I think a lot of stuff has built up to support browser-client access for the 'visual web' application. I believe there is a need to step back and take a look at the HTTP with an eye toward machine-to-machine communication. We should not just re-apply every aspect of existing HTTP tools (servers, etc) to this new application - we should apply the protocol basics where they fit, regardless of 'common use' by the visual web.
I took a stab at extracting REST features from HTTP a while ago, on the RESTwiki; http://conveyor.com/RESTwiki/moin.cgi/WhereRestStopsAndHttpStarts MB
Sam, I've been perhaps the biggest supporter of using SOAP in a manner consistent with REST, both inside and out of the XML Protocol WG for the past couple of years. But at some point, I have to ask "ok, where is it?" Where is the spec that I can look to, to show me and others how to use SOAP in this way? Are you going to write it? If not, who will? I haven't heard anybody else volunteer, nor even identify the need for it. Frankly, I've now given up on SOAP ever being used in this way because it's become synonymous (in developers' minds, and in deployed code) with non-REST style interactions. If, at some point in the future this changes, then I'll be very happy. But until that point, I'm going to use the only protocol that lets me do REST out of the box; HTTP. Thanks. MB = = = = The reason I joined this mailing list, and have persisted, is that it is my hope that some day a paper can be jointly authored which shows both SOAP and REST in a positive light, shows the strengths of both, and how they can be used in concert. - Sam Ruby ------------------------ Yahoo! Groups Sponsor ---------------------~--> Take the Yahoo! Groups survey for a chance to win $1,000. Your opinion is very important to us! http://us.click.yahoo.com/NOFBfD/uAJEAA/Ey.GAA/W6uqlB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
(very rough)
== Roots of the REST/SOAP debate ==
There is one thing we can all agree upon: the REST vs. SOAP debate is
complicated. Debates about architecture are invariably complicated
because they inevitably revolve around abstract models as opposed
to syntactic details. In many cases different people's mental models
have developed differently through their years of experience.
This paper is intended to help readers to understand the point of
view of a REST advocate at a high level.
REST stands for REpresentational State Transfer, which is Roy
Fielding's name for the architecture of the current Web. If the Web
had had a design document in advance, it would have outlined the
principles of REST. But The Web did not have a design document and
so many people think it merely accumulated. Nevertheless, the design
of the Web can be determined by analyzing the major documents that
describe its protocols and formats: URIs (RFC XXXX), HTTP (RFC XXXX),
HTML (RFC XXXX) and XML (RFC XXXX).
The term REST has evolved (for better or worse) from what Roy
Fielding used it to mean. He was mostly focused on discussing the
virtues and vices of HTTP. What most people mean when they say that
they support REST is that they want Web services to integrate deeply
into the architecture of the Web and use Web technologies to their
fullest. REST only became a rallying cry when it became clear that
an alternative model was arising and that this alternative was in
some senses competitive with the Web.
== In the Beginning ==
There are four main concepts that serve as the characters in this
story. You are probably familiar with them but I need very precise
definitions so bear with me. Our protagonists are documents, data,
programs and protocols. Historically a document was a bag of bits
intended for viewing by a human being. Documents were written by
people for people. Because people are creative, documents vary
radically in size and shape. Data is more often "collected" rather
than "created". For easy maintenance it is often collected in very
constrained ways and stored in highly organized containers: databases.
Programs are sets of instructions written in some language, usually a
programming language. Protocols are ways for programs to communicate
with each other across computer networks.
Without programs there would be no computing so in that sense programs
are wonderful. But in another sense they are a necessary evil.
In particular, programs are extremely hard to analyze. That is why
there are so many bugs in them! Computers can do only very rough
validity checks on them. Programs are also quite hard to use in new
contexts that they were not prepared for. A Macintosh program cannot
(in general) run on a PC. This is because it is hard to analyze the
program and understand what parts of it depend on what quirks of
the Macintosh platform. If programmers need to write code that runs
on both Macintoshes and PCs, they tend to code in a very particular
way from the beginning (choosing their tools carefully and testing as
they go). In essence they do the required analysis a little bit at a
time as they go rather than expecting to be able to automate it later.
To put it another way: if somebody drops 100MB of data into your lap
and asks you to do something useful with it, there are a variety of
analysis tools and techniques you can use to determine its nature and
figure out how to re-use it. If they drop the same 100MB of program
code into your lap you will find that the analysis is in general much
more difficult because analyszing code is intrinsically difficult.
Around the late 1960s, some IBM researchers noticed that existing
technologies did not make a clear boundary between programs
and documents. Some forms of documents were really just simple
programs. Some were actually very complex programs! One virtue
of modern computers is that they can treat code as data and data
as code but usually it makes more sense to treat them as separate
entities. The researchers noticed that if you treat documents as data,
rather than programs, you can much more easily repurpose them for
new environments. They sought to clearly delineate the line between
document data and the code that processed it.
Let me give a concrete example. Suppose you work in a highly secure
environment. Someone sends you a Word document and a Docbook/XML
version. Word mixes code and data. Docbook/XML does not. You load the
one up into Word and the other up into an XML editor. There is a chance
that the first one will cause Word to say something along the lines
of: "I'm sorry. There seems to be a macro in this program. Macros are
program code. Analyzing program code is extremely difficult. Therefore
I can't tell you whether this document is safe or unsafe. Open it at
your own risk." The Docbook version will never give such a warning
because Docbook separates document data from code so that there is
no need for such a security audit. Similarly, Word macros tend not
to work properly in Word-like programs that claim to work with Word
documents. Docbook documents are entirely platform independent.
== SGML Philosophy ==
Docbook was orginally based upon SGML. SGML was the language that came
out of that research at IBM. Docbook's easy environment-independence
comes from using the two markup languages and keeping in mind the
philosophies that surround them.
People who grew up with SGML and XML came to internalize certain
philosophies. One was that separation of data and processing is
sometimes inconvenient in the short term but generally pays dividends
in the long term. Once you've separated the data from its processing
you can often find new uses for the data that you did not originally
expect. Because it is easy to analyze and reuse data, not programs,
SGML people tend to strongly prefer systems that encode as much of
the logic as possible in data rather than programs.
Average programmers, not surprisingly, feel uncomfortable with this.
If programming is what you get paid for, why would you want to
decrease the importance of programs? Moving logic from program code
to data is also a hard sell for the same reason that jogging is a
hard sell. It often (but not always) involves short-term pain for
long-term gain. Furthermore, the nature of the long-term gain is
typically unforseeable. Any well-defined, present requirement can be
coded into a program. It is the ill-defined, future requirement that
the program will probably have problems with. Because data is easier
to analyze, it is easier to repurpose it to solve new problems easier.
Most people do not understand that the Web was designed precisely
in opposition to the idea that data should be accessed through
programmatic methods rather than being treated as intrinsically
inert.
http://www.w3.org/DesignIssues/Principles.html#PLP
The most advanced techniques for moving logic from code to data are
called "knowledge technologies." RDF is the knowledge technology from
the W3C. Topic maps are from ISO. These knowledge technologies allow
the classification of information items, the association of metadata
with the items and allow relationships betwen items to be expressed
explicitly in some cases and inferenced (inferred) in other cases.
Inferencing is a way of uniting partially understood information
sources to create new knowledge.
People vary in their level of skepticism about the applicability
of these knowledge technologies. In my mind, that debate is
marginal. Sophisticated developers separate data from processing as
much as possible, whether or not the data conforms to some particular
standard. The knowledge technology standards are just points far
along a spectrum of declarative technologies. Every hyperlink in the
world is a declarative assertion of a relationship between two data
objects. If you understand the benefit of hyperlinks then you
understand what declarative techniques can do for you.
== The SGML Tribe ==
Members of the SGML tribe also came to deeply revere the related
concepts of linking and addressing. Once again, this comes back to
the idea of reusing information in ways that it was not originally
intended for. If you can get some kind of handle or reference to
an information item, you can reuse it in new forms of information
packaging. For instance, it is possible to link a range of Excel cells
into a Word document. As you change the cells in Excel, the changes
are reflected in Word. You don't have to create the original Excel
spreadsheet with some special flag that says: "I want to reuse this
information." You just tell Word (through drag and drop) that you
are interested in cells A3-D5 in "myfile.xls".
SGML people took this technique to new heights and created extremely
sophisticated systems built upon it. The most sophisticated of these
systems is the World Wide Web, built in part by people who were
part of the SGML tribe (like Dave Raggett), in part by people who
had discovered or reinvented its core ideas without joining the tribe
(like Tim Berners-Lee) and also by people who simply did not understand
it at all (like Marc Andreesen and is cronies, who I will probably
never forgive for lamentably poor extensions to HTML and the Web).
== The Google Example ==
Let us consider a particular example. One way to do hyperlinking is
with declarative statements about what pages are linked to other
pages. Another way is to put little programs in each element that
invoke the hyperlinking behaviour.
A programmatic approach to hyperlinking would encourage you to
represent the relationships between pages as little snippets of code
that load and display the next page. At first glance this would seem
to be a more sophisticated system because it would be possible to write
sophisticated hyperlinks that do complicated computations and then
choose the appropriate page to load based on those computations. The
code could also do interesting things with the placement and styling
of the pages.
http://www.w3.org/DesignIssues/Evolution.html#Least
Unfortunately, code is difficult to analyze. This means that once
code is deployed the user typically has only a boolean choice:
"run it" or "don't run it."
On the other hand, consider one result of our declarative approach
to hyperlinking: Google. Google is built upon the analysis of Web
hyperlinks. If hyperlinks were code rather than data, Google could
not come along ten years after the invention of the Web and figure
out a completely new way for analyzing and reusing the deata embedded
in it. Nobody foresaw Google's ranking algorithm when the Web was
invented. In fact the idea of a central search engine would probably
have seemed insane. But years later, the people at Google noticed
all of the Web data sitting around and they found a new way to make
it valuable. Yahoo has a similar story.
Another interesting thing about Google is that it works despite the
fact that it does not always know exactly what it is doing. Google
does not know when it sees a link of whether it is a link from a
child document to a parent document or vice versal. It does not
know whether the two documents are created by the same person. Google
does not know why the documents are linked. Google sees a link and it
records it. It works from partial understanding rather than waiting
around for complete information.
If Google could only get information out of a service by understanding
every detail about the service's interface, it would not be able to work
with partial understanding and will be consequently crippled (later
on I present an analogy with the phone system that makes this clearer).
http://www.w3.org/DesignIssues/Evolution.html#PartialUnderstanding
Web-based services such as Google, Yahoo, Blogger and Meerkat add value
to existing information by making links to that information. They
show what you can do by using XML and hyperlinks to create services
that work with partial information based on analysis of data.
== SOAP's Role ==
The programming world spent years trying to avoid using a data-centric
model for networking. They used protocols such as DCOM and CORBA which
hid the data behind programmatic interfaces (APIs) and delivered the
data across the network in unreadable binary packets. These are called
Remote Procedure Call (RPC) protocols. One camp of people thought
that there were only two things wrong with this strategy. First,
they disliked that there were BOTH DCOM and CORBA. They logically
felt that there should really be a single standard for RPC over the
Internet. Also, they thought that the binary packets were turning
off Internet programmers, who are more comfortable with text-based
formats. This group invented what we will call "SOAP-RPC", which was
an XML-based remote procedure call protocol for use over the Web.
Another camp thought that this was not enough to allow messages to flow
freely between businesses. They thought that an important requirement
was "loose coupling". In other words they wanted to make it possible
for clients and servers to evolve independently. XML allows this but
does not require it. It takes extra effort to create systems that are
loosely coupled. Over the last several years, people espousing this
view have taken over the job of directing the SOAP specification. Most
of the more clued-in architects at vendor companies agree. They see
the RPC model as backwards.
http://www.prescod.net/soap/views
Neither camp incorporated lessons from the SGML and XML tradition. In
particular they did not design SOAP such that individual data objects
would be addressable. For instance, if you were designing a banking
web service using standard SOAP tools, you would almost certainly
make the bank the only explicitly addressable object. In other words
the only URI would be for the bank. To send a message to a particular
account you would do something like this:
bank = new SOAPProxy("http://.....") bank.addMoneyToAccount(account
23423532, 50 dollars)
To get information about a particular user, you would do something
like this:
bank = new SOAPProxy("http://.....")
bank.getUserNameFromAccount(account 23212343)
Note that the account itself is not addressable. It has no URI. In the
Web-centric version of the service the accounts would be addressable.
Let me offer an analogy. Suppose you were living temporarily in
a hotel. The hotel might not have direct dial connections from the
outside. In order to call a room you have to contact the operator first
(this is like contacting the "SOAP endpoint") and then ask them to
connect you to your room. Now imagine that there is an outside service
that you would like to buy. It is a onc-a-day automated wake-up call
and horoscope service. You try to sign up for the service but when
you are asked to enter the phone number to call back you realize that
there is no single number. The service must contact the operator first
and then the operator must patch them through to you. Obviously the
computer on the other end is not going to be smart enough to know to
go through the operator and the operator will not know to patch the
call through to your room.
If everybody lived in a hotel like that, the operator service would
be practically impossible. A particular application of the phone
sysstem would simply cease to exist. Telemarketers would find their
job a little harder too but I think that they would adapt!
Note that the problem is not obvious in the design of either system. It
is when you try to unite the two systems that you wish that the hotel
had used the international standard phone addressing "syntax" rather
than having an extra level of misdirection through the operator. SOAP
services are the operator. The objects they work with (purchase orders,
bank accounts, personelle records) are the hotel rooms. The data is at
the mercy of the soap endpoint. If the interfaces of the client and
server do not exactly align, the two cannot communicate. And yet,
participants are often happy to work with partial knowledge and
loosely coupled interfaces. For instance, the automated horoscope
system was not interested in the fact that you happened to be in a
hotel room. Similarly, a system for tabulating monthly pay checks would
not care what precise human resources management system the enterprise
was using. As long as the employee records are available in EmployeeML,
it doesn't matter what workflow was used to get them there.
Bear in mind that SOAP's weakness around addressing does not stem
merely from ignoring the lessons of XML and SGML. In fact, older
standards like CORBA and DCOM did much better in this area. Every
object had an address and although the address syntaxes were not
URIs, they were at least standardized within the domain of each RPC
protocol. SOAP lacks any equivalent addressing model. Although it
is the new, new thing, it is actually less sophisticated in this way
than its predecessors.
== SOAP and the Web ==
There is a reason for SOAP's weakness around addressing. If SOAP
unambiguously stated that the addressing syntax for SOAP is URIs then
that would be equivalent to saying that SOAP is designed for use on
the Web and only on the Web. But SOAP advocates are quite clear about
the fact that Web protocols and Web addressing models serve only as
"transports" for SOAP. That is like saying that the Web is a taxi
driver and its only job is to get SOAP from place to place. The SOAP
message can get out of the taxi and into another vehicle for the next
leg of its trip. In technical terms, SOAP "tunnels" through the Web.
This is a core area of digression between the REST viewpoint and
that of the SOAP specificatoin. The REST viewpoint is that the
Web architecture is incredibly scalable and well-designed. The Web
was explicitly designed
to integrate disparate information systems. But the Web did it on its
terms, by binding them all into a single namespace and encouraging them
to use a single protocol. The central virtue of the Web is that you
don't glue system X and system Y together using the Web as transport
middleware. Rather you make a web interface to system X and a web
interface to system Y and the two systems can link to each other and
exchange information with each other just by virtue of the fact that
they are using the same namespaces, protocols and formats.
Yes, the Web is middleware. But like any middleware you would buy from
a high priced vendor, the middleware encourages you to map your data
into a common model. This model is REST, the Web Architecture. Any
middleware vendor will tell you that you want to do this kind
of mapping rather than create N*M connections between individual
services. Even so, some people really want to take the short-cut of
tunnelling through the Web. In some cases that might be useful but it
is highly debatable whether it is the W3C's job to make that easier
rather than concentrating on improving the Web so that tunnelling
is not necessary. I, for one, am in favour of treating the Web as a
translator rather than a taxi driver.
== Interoperability is Key ==
Many of the usage scenarios for SOAP seem to be inddirect
point-to-point integrations of system X and system Y, using the
Web as transport middleware. Considering how many systems there are
out there, this model cannot scale. It quickly becomes obvious that
there will need to be standardized interfaces with many interoperable
implementations, just as there are many interoperable implementations
of HTTP and SMTP. SOAP itself does not guarantee interoperability. It
is protocols built on top of SOAP (probably specified in WSDL) that
will guarantee interoperability.
These standardized interfaces will be the basis of the Web Services
revolution. Some vendors promote SOAP as a way that any half-decent
programmer can generate a new protocol by running a tool over their
Java or C# program. Even the vendors are coming to agree that this
is a naive point of view. First, it is naive because the services so
generated are extremely poor from a distributed computing point of
view. They are as brittle as communion wafers. They are as tightly
coupled as salsa dancers. Try adding an extra parameter on the
Google service!
Second, it is naive because a blossoming of thousands of protocols
does not get us any closer to interoperability. What we need for
interoperability are a few well-engineered, well-designed, scalable,
secure protocols. The success of the existing web and of email shows
that a few protocols can get a ton of work done. When you book a
plane trip through an online travel agent, that agent isn't using the
"Travel Agent Protocol." It uses the generic HTTP protocol.
HTTP is a special protocol in that it explicitly embodies the Web's
principles. In particular HTTP revolves around URIs and uses very
self-describing messages. A radical viewpoint is that HTTP is the
only web services protocol we will need!
Whether or not this is true, there is a sense that the whole SOAP
exercise has been a distraction from the main event. The main event
is determining the data models and data flows necessary to allow
ebusiness to begin to flow. ebXML (whether it turns out to be a
success or failure) is nevertheless attempting to solve the right
problems. The SOAP prject is not.
But SOAP is not just a distraction. It actually works against the
process of getting ebusiness correct by training application developers
to avoid using one of their most powerful tools, the hyperlink. This
is analogous to teaching database designers not to use foreign keys,
C programmers not to use pointers or Java programmers not to use
references.
== Separation of Processing from Data ==
Remember that one of the lessons from the SGML days was that it is
good to separate data and program code? The HTTP protocol is brilliant
at ensuring that data is not dependent on code. For instance imagine
that the department of motor vehicles had a web service that could
deliver information on who owns a particular license plate. I could
integrate the information into an XML document using one line of code:
<xi:include href="http://..../license_handler?V6A4G5">
This will execute an HTTP GET. The important thing is that HTTP defines
a protocol for turning URIs into bit streams that can be incorporated
into other documents.
The web infrastructure guarantees that a client may execute this as
often as they like with no repurcsions because GET operations are
guaranteed to be safe.
On the other hand, SOAP would require me to somehow embed a method
call in my XML document. There is no syntax for doing this and there
cannot be one. One of the Web's principle axioms is that users are not
responsible for any damage that is done by following a hyperlink. SOAP
methods have no way to communicate whether the method does or does
not do anything that could be considered damaging. This shifts the
responsibility to the client software in a manner that is not scalable.
== REST From a Protocols Point of View ==
There is another way to come to the REST position without any interest
in Web architecture. One can look at SOAP purely as a protocol without
even considering the problems it is supposed to solve. It bends or
breaks all of the rules common among Internet protocols. For instance,
if one reads a book on the roles of networking protocols, it is clear
that SOAP is a layer 6 (presentation layer) protocol but SOAP actually
runs on top of HTTP and SMTP, which are both layer 7 protocols. That
makes SOAP a layer 8 protocol. Unfortunately the standard network stack
diagrams max out at 7! By definition the 7th layer, the application
layer, is the top layer. SOAP treats layer 7 protocols as "transport"
protocols. It pretends that they are layer 4 protocols. This causes
various sorts of discomfort for system administrators, security
analysts and protocol purists.
There is a sense that there will be one or two widely publicized SOAP
security breaches and firewall administrators will shut SOAP traffic
down. Although any protocol can be used as the basis for a security
hole, SOAP arguably encourages security holes by encouraging every
business analyst to become a protocol designer. Also, the industry
has not been clear from a marketing perspective that SOAP is just a
basis for application protocols, not a top-level protocol itself. That
means that SOAP could get tarred with the security flaws that appear
in protocols based upon it.
But REST's biggest hole when it comes to protocols is the issue
I discussed of many protocols versus a few. No "many protocols"
framework has ever taken hold on the Internet. Security concerns
are one reason. It is easier to analyze and understand the security
implications of a few standarized protocols rather than hundreds of
unstandardized ones. Another reason is administration. Administrating
a firewall that supports many protocols is harder than maintaining
few. Finally there is the big one, interoperability. Getting all of
these independently created protocols to talk to each other will be
a nightmare.
== HTTP Does More than you Think ==
HTTP is wonderful in that it natively separates data from
processing. But it is also more general than just a document
fetching protocol. Most people do not know that HTTP is 100%
CRUD-compliant. That means that it has methods that map to "create",
"retrieve", "update", "delete" and "replace", just as SQL does. The
power of URIs and of the HTTP methods combine to make HTTP an extremely
general protocol for manipulating information sources. The SQL
analogy should be suggestive of the sort of flexibility available!
== Limits of The Web-As-We-Know-It ==
HTTP is not perfect. The Web is not perfect. We are not at the end
of history. We need new and better stuff. The REST argument is that
we need to understand what we have and make certain we do not lose
features we have today. SOAP makes it extremely difficult to use
hyperlinks because SOAP is fundamentally a technology for tunnelling
through the Web.
Mark Baker wrote: > > Sam, I've been perhaps the biggest supporter of using SOAP in a manner > consistent with REST, both inside and out of the XML Protocol WG for the > past couple of years. But at some point, I have to ask "ok, where is > it?" Where is the spec that I can look to, to show me and others how to > use SOAP in this way? Are you going to write it? If not, who will? I > haven't heard anybody else volunteer, nor even identify the need for it. > > Frankly, I've now given up on SOAP ever being used in this way because > it's become synonymous (in developers' minds, and in deployed code) with > non-REST style interactions. If, at some point in the future this > changes, then I'll be very happy. But until that point, I'm going to > use the only protocol that lets me do REST out of the box; HTTP. Probably the best way to describe where my head is at is that I feel that there ultimately will be a unification of the various approaches, and I do plan on playing an active role in documenting that unification. The unification, IMHO, will not be precisely REST as documented and practiced today, but will share a number of important characteristics with that architectural aproach. It most definately will NOT be RPC as practiced today. A fairly approachable overview of where I think things are headed can be found at: http://radio.weblogs.com/0101679/stories/2002/04/05/neurotransmitters.html Feedback welcome. - Sam Ruby
Excellent. - Sam Ruby
Nice piece. I liked the RPC/virus analogy. 8-) I suppose that we'll just have to agree to disagree on the value of XML over existing, working protocols. That doesn't mean I don't think that new work is required or useful (like ALIN, as a refinement of one part of REST; focusing on decoupling request from response and providing a more rigorous intermediary model), just that a new syntax isn't going to buy much. As I see it, there are two ways in which SOAP can leverage REST. One is to bind to HTTP (or other REST-based protocols, as they arrive), and reuse the application semantics of those protocols. The other is to build REST semantics on top. IMO, if SOAP is to be successful in the short/medium term, it will be because of the former use. And if that works, then we can progress to the latter use. But I can't see going straight to the latter use because without the former, SOAP will already have fallen out of favour with developers and the press. So IMHO, if you want to do something to help SOAP developers (and therefore SOAP), show them how to use HTTP. MB
Hi Folks, Someone was telling me that yellowbrix[1] has a REST-ful web service, similar to Meerkat. I have been unsuccessful at finding its API. Does anyone have its API? /Roger [1] http://www.yellowbrix.com/pages/www/index.nsp
Hi- Excuse me if this is a simple question, but I'm trying to fully understand how to best use URIs. If I have a URI that is labeling a resource to which I can POST data to be processed, it is not good practice to include a file extension in that URI, correct? In other words, if I implement that resource using ASP, JSP, ASP.NET, ..., I wouldn't want to betray that implementation detail, right? It seems that http://www.mycompany.com/purchaseOrders would be better in than http://www.mycompany.com/purchaseOrders.aspx How would this translate to all file extensions? Its seems to me there is an awful lot of .html, .asp, etc. labeling all sorts of web resources, and yet this seems to go against "Cool URIs do not change," etc. To me this seems like a basic principle that is violated everywhere. Thanks, Casey
hilbert_casey wrote: > > Hi- > Excuse me if this is a simple question, but I'm trying to fully > understand how to best use URIs. If I have a URI that is labeling a > resource to which I can POST data to be processed, it is not good > practice to include a file extension in that URI, correct? In other > words, if I implement that resource using ASP, JSP, ASP.NET, ..., I > wouldn't want to betray that implementation detail, right? As a matter of style, I agree. But the effort to hide it often outweighs the stylistic concern. The root of the problem is that the Windows and Unix file systems determine file type by extension. So it takes extra effort to keep both the operating system and the web happy. I say it is "only" a matter of style because if push came to shove you could swap your .aspx for a .jsp and with the right configuration everything should still work okay. You might have to do some web server tweaking, but your "cool URI" would "not change". The thing that is uncool about it is that you betrayed your implementation technology in your URI, which is a little bit like leaving wires hanging out of a computer case. Also, it could be a hint to hackers who want to exploit known security holes in your implementation technology. Finally, I wouldn't be surprised if IE uses file extension as one of its hints about file type even when the server has labelled the content-type. Paul Prescod
REST argument page on WikiWikiWeb: http://c2.com/cgi/wiki?RestArchitecturalStyle In the middle, someone writes plaintively "We need Mark Baker."
> In other > words, if I implement that resource using ASP, JSP, ASP.NET, ..., I > wouldn't want to betray that implementation detail, right? For security and resume reasons, sure. > It seems that > > http://www.mycompany.com/purchaseOrders > > would be better in than > > http://www.mycompany.com/purchaseOrders.aspx > > How would this translate to all file extensions? Its seems to me > there is an awful lot of .html, .asp, etc. labeling all sorts of web > resources, and yet this seems to go against "Cool URIs do not > change," etc. The 'do not change' depends on how widespread the value of that URI is goes. If that URI is retrieved quite often and never cached, then it doesn't matter as much. If it is cached (in Google, on drives, in code, etc.) then being generic is better. > To me this seems like a basic principle that is violated everywhere. Yep.
Mark Baker wrote: >I suppose that we'll just have to agree to disagree on the value of XML >over existing, working protocols. Would you care to elaborate on what existing protocols you are referring to? One issue I see with REST and why SOAP is attractive to many developers is that of the comfort zone - the vast majority of developers are far more comfortable with program logic in code than in data. After all, it is what we've been doing for years, there is a huge body of information out there on ways and means of doing it effectively and as several people have highlighted recently, REST is more about resource (information/knowledge) modelling which by comparison is less widely known and less 'supported' in the how-to sense - it is out of most developers' comfort zones. The issue of getting a handle on resource modelling, designing effective representations for REST-ified systems to deal in, is one with which I am currently struggling. A good starting point may be adding appropriate links to the resources page on the REST wiki. I'm happy to do the maintenance if people would care to contribute appropriate links (either directly to me or to this list). Robert
Hi Folks, I have 2 questions: 1. Doing an HTTP POST the REST way From comments on my REST tutorial I have realized that to successfully argue the case for REST I need to include an example of doing an HTTP POST. To my embarrassment, I am not sure that I understand the REST position on HTTP POST... In my REST tutorial I have an example of a fictitious company, Parts Depot, Inc. The company wishes to make available on the Web the following services: (a) A service to enable a client to get a list of parts. (b) A service to enable a client to get detailed information about a particular part. (c) A service to enable a client to submit a Purchase Order (PO). Clearly, an HTTP GET is the way to implement services (a) and (b). For service (c) a client will want to do an HTTP POST. (Correct?) I would like to consider further how service (c) would be implemented in a REST-ful manner. My understanding is that an XML Schema (or DTD) would be created by Parts Depot, Inc which defines the format that the PO must take. A client then will create a PO instance document which conforms to the XML Schema, and submit that XML document as the payload of an HTTP POST. Correct? With a SOAP implementation of this service the only difference would be that the XML document would be wrapped within a SOAP envelope (and there may be a SOAP header). Is this a correct assessment of the differences between REST and SOAP for this service? Is the ability to add headers in SOAP going to be an advantage over REST in this scenario? 2. Distinguishing characteristics of REST? I am not clear on what characterizes a REST architecture. For example, consider this HTTP GET for getting information about the part whose id is 00345: http://www.parts-depot.com?part=00345 It is my understanding that this is not REST-ful. The REST approach would be to use this URL: http://www.parts-depot.com/part/00345 Why is the later REST-ful but the former is not? May I conclude that in a REST-ful system you would not use URLs with query strings? Can someone enumerate the distinguishing characteristics of a REST system? In other words, how will I recognize a REST service when I see one? Thanks! /Roger
--- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote: > (c) A service to enable a client to submit a Purchase Order (PO). > I would like to consider further how service (c) would be > implemented in a REST-ful manner. Yes I am interested in how this could be done too. > My understanding is that an XML Schema (or DTD) would be created by > Parts Depot, Inc which defines the format that the PO must take. A > client then will create a PO instance document which conforms to > the XML Schema, and submit that XML document as the payload of an > HTTP POST. > Correct? Walter Perry, leader of the NY XML SIG, has a different view when it comes to interacting with processes. I will do my best try to express my understanding of his views. In Walter's eyes the most important thing for a user to determine is what is a process's output. If the output is not of use, then the process is not of use. Walter is a little bit vaguer about how to identify a processes input format, he always says something like 'the best way to determine a process's input is to look at its output' (paraphrased). Perhaps in this example of a PO, a more interesting approach is for the user to do a GET on a blank PO URI. This could return a PO XML instance with the parts and amounts left blank, but the whole XML structure present. Then the user could fill in the amounts and parts required and do a POST to the orders URI. This way if the service provider needs to change the PO format in a minor way, the chance of affecting the users is less because for each transaction the user begins by doing a GET on the blank PO URI. And if the user is clever they will add their details to the blank order in a way that won't be affected by such minor changes (for example if an extra element is added). (This is my personal interpretation of Walter's mysterious "start with the output"). What does everyone think? As for validation, Walter says it is up for the process to instantiate an instance of the data from the input it is given. And the user can determine if their input to the process was adequate if they get meaningful output. So schemata and DTDs are not required. Regards, Robert McKinnon
Roger L. Costello wrote: >. Doing an HTTP POST the REST way.... >My understanding is that an XML Schema (or DTD) would be created by >Parts Depot, Inc which defines the format that the PO must take. A >client then will create a PO instance document which conforms to the XML >Schema, and submit that XML document as the payload of an HTTP POST. >Correct? With a SOAP implementation of this service the only difference >would be that the XML document would be wrapped within a SOAP envelope >(and there may be a SOAP header). Is this a correct assessment of the >differences between REST and SOAP for this service? My (newly acquired) understanding agrees with this assessment :-/ >Is the ability to >add headers in SOAP going to be an advantage over REST in this >scenario? There has been some discussion on this topic on the list with the consensus being that Http headers are the equivalent. >Distinguishing characteristics of REST?... >May I conclude that in >a REST-ful system you would not use URLs with query strings? It is my understanding that a query string is valid if used as an optimization to a query-less URI mechanism, i.e. if in your scenario http://www.parts-depot.com/part/00345 is traversable/find-able via http://www.parts-depot.com/part/ which returns an XML list of all the available parts that includes links to the individual parts as in your tutorial (incidentally I think http://www.parts-depot.com/parts/00345 and http://www.parts-depot.com/parts/ are regarded as a slightly better naming approach because the name more closely matches the resource). >Can someone enumerate the distinguishing characteristics of a REST >system? You might take a look at Extreme Web Services at http://groups.yahoo.com/group/rest-discuss/message/1204 Robert
"Roger L. Costello" wrote: > >... > > My understanding is that an XML Schema (or DTD) would be created by > Parts Depot, Inc which defines the format that the PO must take. A > client then will create a PO instance document which conforms to the XML > Schema, and submit that XML document as the payload of an HTTP POST. > Correct? With a SOAP implementation of this service the only difference > would be that the XML document would be wrapped within a SOAP envelope > (and there may be a SOAP header). Is this a correct assessment of the > differences between REST and SOAP for this service? Well, don't forget that the REST version returns you a URI that can be used to address that purchase order for ever after. The SOAP version would typically not. Also, Mark Baker would probably use RDF instead of generic XML. (I would not...but I may change my mind as I learn more about RDF). An important subtlety: *if* the SOAP version accepts an arbitrary "purchase order vocabulary" document, *then* the SOAP version probably does not use the SOAP encoding, which negates many of the "ease of use" advantages of SOAP. We are in a confusing time right now where half of the world thinks SOAP is much easier to use than "regular" XML because they don't have to parse it or map it and the other half says that the right thing to do is parse it or map it. That means that SOAP advocates can say that SOAP is really easy (no parsing required!) and really extensible (pure XML!). But the truth is that you can't have them both at the same time. > ... Is the ability to > add headers in SOAP going to be an advantage over REST in this > scenario? Doubtful but possible. You can add headers in HTTP also. You can also add arbitrary XML to the body message if the schema is well designed. Maybe in some circumstances you want the information to be logically a header AND you need the header to have deep structure (i.e. XML). That's why I've said that one of the few things I would like to steal from SOAP is headers: http://www.prescod.net/xml/envelopes/ > 2. Distinguishing characteristics of REST? > > I am not clear on what characterizes a REST architecture. For example, > consider this HTTP GET for getting information about the part whose id > is 00345: > > http://www.parts-depot.com?part=00345 > > It is my understanding that this is not REST-ful. The REST approach > would be to use this URL: > > http://www.parts-depot.com/part/00345 > > Why is the later REST-ful but the former is not? May I conclude that in > a REST-ful system you would not use URLs with query strings? I wouldn't go that far. First, they are both better than the traditional web services way because they are addressable. Second, the actual syntax of your URIs is a server-side issue and really the details of the syntax are not the client's business. (i.e. you could use indecipherable UUID strings and still be RESTful, if not stylistic ideal, just as you could use meaningless method names in a Java program but still be "OO"). That said, it is my opinion that the primary mode of navigation through a service should not be a query. Hyperlinks are more discoverable and require less client/server pre-negotiation. Queries are good as an option. But that doesn't really answer the question because you could have hyperlinks to either one. So a minor advantage of the latter is that it is more like a canonical URI for a thing whereas queries can have multiple parameters and sometimes parameters are optional so it is hard for a caching system or indexing engine to figure out whether they are canonical. Also some indexing engines may be leery of following question mark links for various historical reasons. Also, the latter helps you to organize your system into more of a hierarchy which makes the meaning of POST more predictable to clients. i.e. given the bottom URI I would expect that a POST to "part" (actually I would call it "parts") would add a part. But given the former URI I wouldn't be sure exactly where to POST. Just like on a web site I can guess that if I see /a/b, I might be able to take off the /b and get something useful at /a. Also, there is some debate whether this: * http://www.parts-depot.com?part=00345 is actually identifying a resource or sending a query to a resource or both. The latter is 100% clearly identifying a resource. That said, all of these are pretty abstract concerns. > Can someone enumerate the distinguishing characteristics of a REST > system? In other words, how will I recognize a REST service when I see > one? IMO, the bad news is that it would be a book, just like the distinguishing characteristics of an OO system. Maybe there will never be 100% agreement, just as there isn't 100% agreement about the right way to be OO. Nobody is ready to write the book (whether canonical or controversial) yet. But here are some ideas: * Use URIs and hyperlinks... * obey web architecture: * http://www.w3.org/DesignIssues/ * anything else written by Tim B-L * understand the design of REST itself (versus REST services) * http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm * as we will typically use HTTP and always use URIs, we need to understand them: * http://www.ietf.org/rfc/rfc2616.txt * http://www.ietf.org/rfc/rfc2396.txt * nobody has yet argued with these rules (nor hardly commented on them) * http://groups.yahoo.com/group/rest-discuss/message/1204 * RDF technologies are probably going to be important tools for the REST programmer to understand in the future but I'm not convinced they are fully baked enough (or at least palatable enough) to recommend everyone learn them. Let's be honest. There is too much for your average programmer to learn here without a good book. Heck, there is too much for me to feel like I've internalized it all. But that is as true of the standard web services stack. Show me someone who understands SOAP, WSDL, UDDI, SAML, GSXA, WS-Routing, WS-Referral, DIME, WS-Security, XLang ... It is a fulltime job just keeping up with the acronyms, much less evaluating each proposal. The industry is moving way too fast for people to understand what we are actually doing. ;) :( On the one hand REST people should probably resist the urge to rush because IMO the standard stack's mistakes arise from their rush and their closed development model (what standards body worked on SOAP for the first two or three years of its development?). Following them into mistakes could be a bad mistake. On the other hand, it is not a good situation if customers have to choose REST with one checklist of features versus the standard stack with a different checklist. "They have transactions. You don't. You have addressing. They don't. How do I pick?" Bosworth says he wants to move from within-company services to B2B by the end of the year! Obviously he means point-to-point B2B rather than standards-based because we are nowhere near standards-based. But still. Too much coffee. End of rant. Paul Prescod
----- Original Message ----- From: "Roger L. Costello" <costello@...> > > (a) A service to enable a client to get a list of parts. > (b) A service to enable a client to get detailed information about a > particular part. > (c) A service to enable a client to submit a Purchase Order (PO). > > Clearly, an HTTP GET is the way to implement services (a) and (b). For > service (c) a client will want to do an HTTP POST. (Correct?) I would > like to consider further how service (c) would be implemented in a > REST-ful manner. Just make sure that you don't merge REST and HTTP. REST is just a summary of the key aspects of the Web that helped it succeed and keep it strong. HTTP is one of the Web protocols - which exhibits the most of these aspects. > > My understanding is that an XML Schema (or DTD) would be created by > Parts Depot, Inc which defines the format that the PO must take. A > client then will create a PO instance document which conforms to the XML > Schema, and submit that XML document as the payload of an HTTP POST. > Correct? Yes. The POST identifies the format being sent via the Content-Type header. The receiver can do any mappings it chooses - if sensible. > With a SOAP implementation of this service the only difference > would be that the XML document would be wrapped within a SOAP envelope > (and there may be a SOAP header). Is this a correct assessment of the > differences between REST and SOAP for this service? The HTTP approach would have an HTTP header with "Content-Type: application/purchase-order", so HTTP aware firewalls, gateways, etc. can do useful things. The SOAP approach would require cracking both HTTP (and ignoring the http headers) and XML to do the same thing. > Is the ability to > add headers in SOAP going to be an advantage over REST in this > scenario? REST doesn't talk too much about headers - only to the extent that they shouldn't be used for resource or method identification. You can qualify operations via headers, like in HTTP you can "GET if-none-match" and stuff. HTTP does talk about though, and SOAP might have a more rigorous model for headers. Or it might not. > 2. Distinguishing characteristics of REST? > http://www.parts-depot.com?part=00345 > http://www.parts-depot.com/part/00345 > Why is the later REST-ful but the former is not? May I conclude that in > a REST-ful system you would not use URLs with query strings? Both are equivalent to REST and to HTTP (even though 'normalizing' query strings is difficult). An HTTP based URI has path segments and query strings. The combination of these is the full resource identifier. URI also have parameters like http://host/path/path;param/path;param?query - but these are rarely used and not all libraries/clients/servers parse them properly. Both query strings and segment parameters are a convenience for the resource model implementation on the server. They generally should not be constructed by the client - they should be provided as opaque blobs via some response body (likely in XML, but not necessarily). > > Can someone enumerate the distinguishing characteristics of a REST > system? In other words, how will I recognize a REST service when I see > one? - addressable resources - uniform interfaces that apply to all resources - stateless messages - 'representations' - multiple content types accepted or sent If you implement a networked system that supported these concepts you'll have a decent foundation - regardless of the protocol oor technology used.
----- Original Message ----- From: "xemplify" <xemplify@...> > > Perhaps in this example of a PO, a more interesting approach is for > the user to do a GET on a blank PO URI. This could return a PO XML > instance with the parts and amounts left blank, but the whole XML > structure present. Then the user could fill in the amounts and parts > required and do a POST to the orders URI. This way if the service > provider needs to change the PO format in a minor way, the chance of > affecting the users is less because for each transaction the user > begins by doing a GET on the blank PO URI. And if the user is clever > they will add their details to the blank order in a way that won't be > affected by such minor changes (for example if an extra element is > added). (This is my personal interpretation of Walter's > mysterious "start with the output"). > > What does everyone think? > I'd like to hear what Walter said - but a 'template' approach might be interesting. Let's say we did that - how would the (automated) client know what parts of the template to modify? If we had XML, we could use XPath or something. Then the XML could change as long as the XPath used didn't need to change. Then the client and server would be coordinating based on the list of XPath statements. So the client would know about the data to write via a set of hardcoded text - which you could just send to the server directly as name-value pairs. I'd like to hear more of how this would work... I'm somewhat tangled up in the world of PO/PO-ACK/etc. right now, so this is interesting to me.
----- Original Message ----- From: "Robert Leftwich" <robert@...> > > It is my understanding that a query string is valid if used as an optimization to a query-less > URI mechanism, i.e. if in your scenario http://www.parts-depot.com/part/00345 is > traversable/find-able via http://www.parts-depot.com/part/ which returns an XML > list of all the available parts that includes links to the individual parts as in your tutorial > (incidentally I think http://www.parts-depot.com/parts/00345 and http://www.parts-depot.com/parts/ > are regarded as a slightly better naming approach because the name more closely matches the resource). The path-based uri looks nicer and I personally favor it, but it is only important to the server implementation. The client sees them conceptually as uri1 and uri2 - no paths, no queries, just blobs. Designing code with this viewpoint results in needing to do certain things - like returning the URI of the new PO in the response message rather than assuming the client will know where it is - but that effort results in a more flexible and interoperable system. It'll work fine without it, but you are just limiting the scope of your system (which might be acceptable for the problem you are trying to solve).
Yesterday I started a new page in the Rest Wiki, which spun off from a discussion in Wiki Wiki: http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext We've had several discussions about related topics on rest-discuss, but they have always dead-ended without convergence or resolution. Some of the related topics include: * Sessions * Business protocols like Offer-Acceptance for Purchase Orders and extended ones like Order-Delivery-Payment or Order-Payment-Delivery. Several people from this list have been interested, including Paul Prescod, Mike Dierken and me. Quote from Paul: "Have you ever booked a ticket on Expedia? It has a very complicated state machine expressed through hypertext. The hypertext expression has a variety of advantages like for instance (if it is well implemented) I can send some body a URL from the middle of the state machine and they can continue with the computation without worrying about which state it was in. By examining the referenced document they can determine the state. This is preferable to having separate state machines on the client and the server and requiring them to stay in sync. I think it is better to let the server own the state machine totally and tell the client where it is in the process. I wonder if this wouldn't be easier to discuss on a mailing list like rest-discuss? -- PaulPrescod" I'm hoping that a Wiki page will lead to more convergence than rest- discuss, and result in a coherent document or set of same. If nobody participates, I'll understand that it was a bad idea and do something appropriate with the Wiki page. -Bob Haugen
On Thu, 23 May 2002, xemplify wrote:
> --- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote:
> > (c) A service to enable a client to submit a Purchase Order (PO).
> > I would like to consider further how service (c) would be
> > implemented in a REST-ful manner.
> Yes I am interested in how this could be done too.
> > My understanding is that an XML Schema (or DTD) would be created by
> > Parts Depot, Inc which defines the format that the PO must take. A
> > client then will create a PO instance document which conforms to
> > the XML Schema, and submit that XML document as the payload of an
> > HTTP POST.
> > Correct?
> Walter Perry, leader of the NY XML SIG, has a different view when it
> comes to interacting with processes. I will do my best try to express
> my understanding of his views. In Walter's eyes the most important
> thing for a user to determine is what is a process's output. If the
> output is not of use, then the process is not of use. Walter is a
> little bit vaguer about how to identify a processes input format, he
> always says something like 'the best way to determine a process's
> input is to look at its output' (paraphrased).
> Perhaps in this example of a PO, a more interesting approach is for
> the user to do a GET on a blank PO URI. This could return a PO XML
> instance with the parts and amounts left blank, but the whole XML
> structure present. Then the user could fill in the amounts and parts
> required and do a POST to the orders URI. This way if the service
> provider needs to change the PO format in a minor way, the chance of
> affecting the users is less because for each transaction the user
> begins by doing a GET on the blank PO URI. And if the user is clever
> they will add their details to the blank order in a way that won't be
> affected by such minor changes (for example if an extra element is
> added). (This is my personal interpretation of Walter's
> mysterious "start with the output").
I believe that Roger is more correct in his assessment of the
steps that need to take place. Roberts description of the process
has more of a 'screen scraping' mentality. The DTD/Schema defines
the information required/allowed by the PO, period. Future changes
to the internal representation of that document remain transparent
to the user. Unless Parts Depot, Inc. provides a field in the
DTD/Schema that allows the user to add their own details (and I'm
not really sure what you mean here) to the PO, doing so would
cause an error.
> What does everyone think?
> As for validation, Walter says it is up for the process to
> instantiate an instance of the data from the input it is given. And
> the user can determine if their input to the process was adequate if
> they get meaningful output. So schemata and DTDs are not required.
This certainly requires a lot more hand-shaking than forcing the
user to validate their input data against a DTD/Schema. If the user
inputs data that is not validated by the process then the steps
required to notify the user of where and why the errors occured
increase proportionally. If the originator of the PO (Parts Depot)
supplies knowledge of the correct input it is up to the user to
supply correct input.
edge
--
e d g e @ e d g i n t o n . n e t
______________________________________________________________________
"I'd love to go out with you, but I have to floss my cat."
bhaugen32 wrote: > >... > > Some of the related topics include: > * Sessions > * Business protocols like Offer-Acceptance for Purchase Orders and > extended ones like Order-Delivery-Payment or Order-Payment-Delivery. I'm sorry that the conversations didn't end in something concrete. Could you provide one or two or six URLs with a concrete description of the Offer-Acceptance for Purchase Orders and similar problems? I've got distracted by other things as you discussed them with Mike Dierken and didn't realize that you never came up with solutions you considered complete. If you can give me the URLs we'll all be at the same place again (reset our state based on hypertext) and I'll add my thoughts. One thing I remember is that some people were using "transaction" in the sense of transactional integrity and some people were using it merely to mean a "Communication involving two or more people that affects all those involved; personal interaction"/"The doing or performing of any business; management of any affair; performance." http://www.dictionary.com/cgi-bin/dict.pl?term=transaction&r=67 We had this same terminological problem during the REST/SOAP panel. Lucas used transaction in the latter sense and Rohit thought he meant in the database sense. Paul Prescod
Paul Prescod > I'm sorry that the conversations didn't end in something concrete. Don't be sorry, you stimulated and contributed outstandingly to the conversation. > Could > you provide one or two or six URLs with a concrete description of the > Offer-Acceptance for Purchase Orders and similar problems? Got any problems if I provide them on the Rest Wiki page? The first thing I plan to do (later today) is collect fragments of the conversation from rest-discuss and related lists. > I've got > distracted by other things as you discussed them with Mike Dierken and > didn't realize that you never came up with solutions you considered > complete. I don't expect "complete" yet. > If you can give me the URLs we'll all be at the same place > again (reset our state based on hypertext) and I'll add my thoughts. If we do it on the Rest Wiki, then the topic will be a Web resource (or hyperlinked group of same) and we won't need to chase all the fragments again. Wikis have some problems, but for me, they are much more RESTful than Yahoo Groups. > One thing I remember is that some people were using "transaction" in the > sense of transactional integrity and some people were using it merely to > mean a "Communication involving two or more people that affects all > those involved; personal interaction"/"The doing or performing of any > business; management of any affair; performance." > http://www.dictionary.com/cgi-bin/dict.pl?term=transaction&r=67 > > We had this same terminological problem during the REST/SOAP panel. > Lucas used transaction in the latter sense and Rohit thought he meant in > the database sense. The appropriate transaction model for Web conversations is another very closely related issue. I strongly favor state-alignment transactions over anything even remotely resembling database transactions, but that may be because I am thinking of business exchanges. I suspect mostly people are not even thinking of the issues. W3C-ws-arch is still thinking database transactions. -Bob Haugen
You are right that wikis are more RESTful. So go ahead and use one. My only complaints are: a) they don't generate events in my inbox b) the editing user interface is so brutal. There are so many web-based forums out there these days that the limitations of web browsers as text editors are becoming really annoying. One day I have to think about whether this is purely an implementation issue or a lack of standardization. For instance maybe there should be an attribute that would indicate whether a textarea can contain HTML, so that the editor could use its HTML editor. Maybe there should be a way to say "UserWillWantSpellCheck". Also as an implementation issue it is bad that the "back button" can lose your edits. But I know these are not problems with wiki in particular and I will be happy to work on the Wiki. Paul Prescod
Paul Prescod wrote: > You are right that wikis are more RESTful. So go ahead and use one. My > only complaints are: > > a) they don't generate events in my inbox > > b) the editing user interface is so brutal. I agree with you on both of the above. But then I use Yahoo Groups strictly from the browser (do not get emails) so it is even worse. However, you are one of the main people I want to engage, so let's keep going in rest-discuss for a bit and I'll summarize anything we agree on to the rest-wiki page. Maybe the best of both venues, such as they are. The three main scenarios I remember from previous rest-discuss conversations were: 1. Event notifications (publish-subscribe). They already have their own rest-wiki page: http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents 2. Purchasing (offer-acceptance), with many fragments of conversation on rest-discuss, but no rest-wiki page. Purchasing can be client-server, in which case Amazon is probably the defacto standard, and is fairly RESTful. Peer-to-peer for B2B is different, and the existing standards (RosettaNet and ebXML) use something like EDI-mailbox-style SOAP. (ebXML actually uses SOAP, RNet uses something analogous that they defined way before SOAP.) 3. Travel: your Expedia example, and another based on Appendix D of the Web Services Flow Language document. Expedia is client-server; I think the WSFL example included P2P interactions. Then there were a couple of rest-discuss threads on session state, that is analogous to transaction-state or conversation-state in P2P EDI-mailbox-style. I'm most interested in trying to RESTify B2B transactions. By "transaction", I mean "business state alignment" between two trading partners, for example, an offer-acceptance transaction where both parties have definitive evidence of agreement that the offer was accepted (or not). And yes I do think the transaction-model issue deserves its own rest- wiki page. My next step is to collect a bunch of URLs to previous rest-discuss thread-starting messages and other related documents. I'll post them on a separate rest-wiki page linked to the StateMachinesAsHypertext page. -Bob Haugen
Paul Prescod wrote: > You are right that wikis are more RESTful. So go ahead and use one. My > only complaints are: > > a) they don't generate events in my inbox > > b) the editing user interface is so brutal. So what would it take to implement HTTPEvents for Rest-Wiki? http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > I'd like to hear what Walter said - but a 'template' approach might > be interesting. I was paraphrasing Walter's general approach to XML processing. I gave my own personal interpretation in the example, I think it deviates from Walter's intention. I found this piece written by him that you might find interesting: <http://ibiblio.org/bosak/conf/xmldev99/perry.htm> > Let's say we did that - how would the (automated) client know what > parts of the template to modify? > If we had XML, we could use XPath or something. Then the XML could > change as long as the XPath used didn't need to change. Yes, that's one way of doing it. Let's say I set the part id at XPath: /order/orderline[i]/part-ref and the quantity at: /order/orderline[i]/quantity Or just walk the tree until I find 'part-ref' or 'part-id' or 'part*' and keep a record of the nodes traversed and then make the XPath on the fly and set the part id there. I think in Walter's approach the server side would do such piecing the data together from the input it receives. > I'd like to hear more of how this would work... I'm somewhat > tangled up in > the world of PO/PO-ACK/etc. right now, so this is interesting to me. I just threw the idea out to see what people thought. I'm not really sure on implementation details, or if what I described is really feasible. Regards, Robert McKinnon
A colleague pointed out Jon Udell's InfoWorld article on REST: http://www.infoworld.com/articles/pl/xml/02/05/20/020520pllinks.xml IW also covered the TAG debate on SOAP last week: http://www.infoworld.com/articles/hn/xml/02/05/10/020510hnsoapdebate.xml I've been trying to do some REST evangelization, so it's nice to be able to point to articles like these two and Paul's at xml.com when making my case. It's even better when the people I'm trying to evangelize point out the articles to me! Jim (I tried posting this yesterday, but never saw the message come through. If anyone else did, I apologize.)
Pauls' comment in 'REST/SOAP ideas summary' (http://groups.yahoo.com/group/rest-discuss/message/1301) where he said "The term REST has evolved (for better or worse) from what Roy Fielding used it to mean..." prompted me to go back to the source and contrast it with what is written at the front page of the REST wiki where it says "In particular, REST suggests that what the Web got right is having a small, global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a potentially infinite set of nouns..." Nowhere in either of the standard references to REST by Fielding does it suggest this at all, there is no mention of nouns, verbs, coordination languages or even Unix pipelines for that matter. It appears that the entire front page at REST wiki bears little if any correlation to the term REST as defined by Fielding and at the very least it should say this and describe the process by which the term evolved or was co-opted to take on the meaning/s detailed on the wiki. Does this strike anyone else as confusing or misleading? Robert
Interesting, but I have a suggestion. Either scratch the OSI protocol layers discussion or try comparing against the Arpanet/Internet Reference Model instead. As is, I think it weakens your argument. Most of the existing protocols on the Internet don't follow the OSI model either, so another protocol behaving in a non OSI way is no big deal. Specifically if you look at RFC-871, it observes that the Internet design is not a rigid 7 layer stack, but a hierarchy where you can do the sorts of protocol nesting that SOAP is doing. Without that sort of nesting tunneling and gatewaying are impossible. For that matter, the OSI official position on their 7-layer cake is that it is supposed to be descriptive and not prescriptive, offering a language to talk about protocols and not an absolute dictum as to protocol design. If the OSI committees had realized this we'd have been spared much hassle. http://www.faqs.org/rfcs/rfc871.html http://www.med.utah.edu/medinfo/horthner/webclass/sld018.htm Hmmmm...thinking about it, this whole deal with SOAP and REST reminds me of the OSI/ARPANet wars of years gone by. They had a nice looking model with a gawd-awful committee process pushing it, we had a simple model and the no standardization without implementation policy. --john [B]eware of the panacea peddlers: just because you wind up naked doesn't make you an emperor. -- Michael A Padlipsky --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > == REST From a Protocols Point of View == > > There is another way to come to the REST position without any interest > in Web architecture. One can look at SOAP purely as a protocol without > even considering the problems it is supposed to solve. It bends or > breaks all of the rules common among Internet protocols. For instance, > if one reads a book on the roles of networking protocols, it is clear > that SOAP is a layer 6 (presentation layer) protocol but SOAP actually > runs on top of HTTP and SMTP, which are both layer 7 protocols. That > makes SOAP a layer 8 protocol. Unfortunately the standard network stack > diagrams max out at 7! By definition the 7th layer, the application > layer, is the top layer. SOAP treats layer 7 protocols as "transport" > protocols. It pretends that they are layer 4 protocols. This causes > various sorts of discomfort for system administrators, security > analysts and protocol purists. >
At 12:15 PM 24/05/2002, Jeff Bone wrote: >> Does this strike anyone else as confusing or misleading? > >It may be confusing, but it's far from misleading. The front page of that >wiki --- indeed, part of the motivation for wiki, the list, etc. --- was to >attempt to communicate the understanding several of us garnered from long >and sometimes heated discussions with Roy. So it's not surprising that >different language is used to describe the same concepts in different >contexts: small connector set -> generic interfaces -> coordination >languages, etc. > >I don't think this is what Paul is talking about when he says that the term >has evolved, but then I'm not really sure what he's talking about in that >context. IMHO, REST has a very specific, literal interpretation grounded in >Roy's work. (To the extent that I might've inadvertently "diluted" that >meaning with some of the things I've hucked out there discussing this stuff, >my deep apologies.) Having re-read your "REST, RPC, mountains, molehills, and a retraction (sort of)" at http://www.xent.com/pipermail/fork/2001-August/002801.html I can see where you are coming from and am now somewhat less confused - although, some might argue differently:-). It appears that for me at least, the wiki fails to communicate the 'steps to REST enlightenment' :-) that you describe in that email. Robert
----- Original Message ----- From: "Robert Leftwich" <robert@...> > > It appears that the entire front page at REST wiki bears little if any > correlation to the term REST as defined by Fielding and at the very least > it should say this and describe the process by which the term evolved or > was co-opted to take on the meaning/s detailed on the wiki. > > Does this strike anyone else as confusing or misleading? > I think early on there was a need to contrast REST with the different RPC approaches - and the key introduction in that realm was the comparison of nouns .vs. verbs. I looked over Roy's dissertation a few days ago also and summarized some (but not all) points of REST as this: > > Can someone enumerate the distinguishing characteristics of a REST > system? In other words, how will I recognize a REST service when I see > one? - addressable resources - uniform interfaces that apply to all resources - stateless messages - 'representations' - multiple content types accepted or sent If you've already moved past the "rpc doesn't scale" arguments, these and other aspects of Roy's paper have more meat. Perhaps JeffB and MarkB would like to update the front page to clarify the issues you brought up.
----- Original Message ----- From: "Robert Leftwich" <robert@...> > with what is written at the front page of the REST wiki where it says "In > particular, REST suggests that what the Web got right is having a small, > global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a > potentially infinite set of nouns..." Nowhere in either of the standard > references to REST by Fielding does it suggest this at all, there is no > mention of nouns, verbs, coordination languages or even Unix pipelines for > that matter. Section 5.1.5 [1] explicitly talks about 'Uniform Interface'. "The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components " This does not explicitly talk about methods, but the translation for a wider audience (through the Wiki and this forum) framed it in terms familiar to the programming community. In addition to that, there are several mentions of 'generic interface' and 'standard methods'. [2] "A cache is able to determine the cacheability of a response because the interface is generic rather than specific to each resource" There is a section [3] that talks about "...standard methods and media types are used to indicate semantics and exchange information". Also there is mention of "...the added constraints of the generic resource interface..." [4] The principal aspects of REST are enumerated (section 5.1.5) in a way not easily digested by the current audience of the REST forums. Adding clarity and bringing these down to earth is why the this forum and the Wiki was started. --- [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#5_1_5 "The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components " [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5 _2_2 "A cache is able to determine the cacheability of a response because the interface is generic rather than specific to each resource. " [3] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5 _3_1 "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." [4] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5 _4 "REST component interactions are structured in a layered client-server style, but the added constraints of the generic resource interface create the opportunity for substitutability and inspection by intermediaries"
Hi, I recently began reading the discussion on REST vs. SOAP on this dl and on the RESTwiki and found it to be quite eye-opening. I especially appreciate Paul Prescod's excellent articles and posts, and of course Roy Fielding's seminal thesis. Of the numerous benefits of the REST model, two things jumped out at me: 1. The benefit of a naming system (URI's) that encourages the explicit naming of resources so that those resources can become active participants in the system - thus, become leverageable by other applications and used in ways that the original resource provide may not have thought of. 2. The importance of using a few universal verbs (GET, PUT, POST, DELETE) for applications that want to scale to the web level, where it is difficult to coordinate and enforce changes to every participant. These two concepts got me to thinking about REST and Object-Oriented programming. At first, it would seem clear that they are opposing architectural approaches, especially when OO is view in the terms of CORBA or SOAP-RPC. But, I actually think there is more in common than meets the eye. Maybe this has already been discussed, but I would like to explore a way of looking at REST from an object-oriented viewpoint. One of the fundamental concepts behind OO is that everything is an object and every object has basic methods that it must support. By using these basic methods, a whole bunch of interesting applications can be written which manipulate objects without knowing anything else about these objects (for example, containers, sorters, formatters, storage, etc). Every object is addressable in the namespace of the OO system, in a similar way that URI's are addressable in the current web system. And the generic object manipulators are not unlike how people create new applications from URI's that may be totally outside of the original intent of the URI providers. I think where CORBA and SOAP-RPC deviate from this is in their focus: 1. They don't encourage making all objects addressable, but rather encourage hiding objects behind a few addressable objects. 2. That they don't focus on just a few universal methods for all objects, but focus on defining new methods, many of them simply to access the data hidden per above. These two factors together vastly diminish the capability to benefit from the web's network effects and reduce the ability to create interesting applications from existing "objects". To take this a little further, it seems that there may be some room for expanding from the current 4 basic methods (GET, PUT, POST, and DELETE) which are very much document-centric to include some basic methods for transaction-centric objects. As Bob Haugen mentioned in recent email, we would like to model transactions in REST. If we think of URI's are objects, a transaction may be like a thread object. We may want to add START, STOP, CANCEL, and GETSTATE (maybe can be overloaded by GET). With some basic set of extensions, we can write applications that can control and monitor arbitrary transaction systems. Anyway, just some late night ramblings. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
At 04:57 PM 24/05/2002, S. Mike Dierken wrote: >----- Original Message ----- >From: "Robert Leftwich" <robert@...> > > >> with what is written at the front page of the REST wiki where it says "In >> particular, REST suggests that what the Web got right is having a small, >> global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to >a >> potentially infinite set of nouns..." Nowhere in either of the standard >> references to REST by Fielding does it suggest this at all, there is no >> mention of nouns, verbs, coordination languages or even Unix pipelines for >> that matter. > >Section 5.1.5 [1] explicitly talks about 'Uniform Interface'. "The central >feature that distinguishes the REST architectural style from other >network-based styles is its emphasis on a uniform interface between >components " I find it interesting that the feature of REST that is gaining almost all the attention is fourth out of six in the list of constraints that define the REST architectural style. Note that Fielding says 'the central feature that distinguishes the REST architectural style from other network-based styles...' , i.e. uniform interfaces are a central distinguishing feature, not THE central feature of the entire architecture. >This does not explicitly talk about methods, but the translation for a wider >audience (through the Wiki and this forum) framed it in terms familiar to >the programming community..... > >The principal aspects of REST are enumerated (section 5.1.5) in a way not >easily digested by the current audience of the REST forums. >Adding clarity and bringing these down to earth is why the this forum and >the Wiki was started. I think I've just identified one of the problems I have been having - I was reading Fieldings' work and thinking along architectural style lines i.e. nothing implementation specific, and then reading the REST wiki where it talks about very implementation specific details, i.e. HTTP methods, and I was not making (and the wiki doesn't make explicit) the connection that HTTP is a feature of the current implementation of the REST architectural style, it just states categorically that 'REST suggests that what the Web got right is having a small, global set of verbs (HttpMethods...' Would the following be clearer and more importantly, accurate? 'In particular, REST suggests that what the Web got right in its' implementation of the architectural style whose key elements are addressable resources, a uniform interface between components, stateless messages and representations that capture the state of a resource is the use of URI's as the addressable resources, HTTP methods (GET, POST, PUT, DELETE, etc) as the uniform interface, HTTP as the stateless messages and media types as the representations. The use of HTTP methods can be viewed as a small, global set of verbs that are applied to a potentially infinite set of nouns (URIs - though we're careful to keep in mind that some VerbsCanAlsoBeNouns)...' Robert
If you transition from 'object' oriented programming to 'interface' oriented programming and transition from method based access to property based access, I think you will find many similarities to REST in the micro-cosm of procedural languages. By moving to interfaces rather than objects, you tend towards reducing the total number of interfaces in the system. When you move towards using properties (getFoo(), setFoo()) you also tend to have these properties defined in terms of interfaces - often reusing the same interface. In the end - especially with languages with property-oriented syntax - a lot of syntactical dirt starts falling away from your code and things become simpler and cleaner. Without soap. ;) ----- Original Message ----- From: "Joe Hsy" <joe.hsy@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, May 24, 2002 1:56 AM Subject: [rest-discuss] REST-OO? > > Hi, > > I recently began reading the discussion on REST vs. SOAP on this dl and on > the RESTwiki and found it to be quite eye-opening. I especially appreciate > Paul Prescod's excellent articles and posts, and of course Roy Fielding's > seminal thesis. > > Of the numerous benefits of the REST model, two things jumped out at me: > > 1. The benefit of a naming system (URI's) that encourages the explicit > naming of resources so that those resources can become active participants > in the system - thus, become leverageable by other applications and used in > ways that the original resource provide may not have thought of. > > 2. The importance of using a few universal verbs (GET, PUT, POST, DELETE) > for applications that want to scale to the web level, where it is difficult > to coordinate and enforce changes to every participant. > > These two concepts got me to thinking about REST and Object-Oriented > programming. At first, it would seem clear that they are opposing > architectural approaches, especially when OO is view in the terms of CORBA > or SOAP-RPC. But, I actually think there is more in common than meets the > eye. Maybe this has already been discussed, but I would like to explore a > way of looking at REST from an object-oriented viewpoint. > > One of the fundamental concepts behind OO is that everything is an object > and every object has basic methods that it must support. By using these > basic methods, a whole bunch of interesting applications can be written > which manipulate objects without knowing anything else about these objects > (for example, containers, sorters, formatters, storage, etc). > > Every object is addressable in the namespace of the OO system, in a similar > way that URI's are addressable in the current web system. And the generic > object manipulators are not unlike how people create new applications from > URI's that may be totally outside of the original intent of the URI > providers. > > I think where CORBA and SOAP-RPC deviate from this is in their focus: > > 1. They don't encourage making all objects addressable, but rather encourage > hiding objects behind a few addressable objects. > > 2. That they don't focus on just a few universal methods for all objects, > but focus on defining new methods, many of them simply to access the data > hidden per above. > > These two factors together vastly diminish the capability to benefit from > the web's network effects and reduce the ability to create interesting > applications from existing "objects". > > To take this a little further, it seems that there may be some room for > expanding from the current 4 basic methods (GET, PUT, POST, and DELETE) > which are very much document-centric to include some basic methods for > transaction-centric objects. > > As Bob Haugen mentioned in recent email, we would like to model transactions > in REST. If we think of URI's are objects, a transaction may be like a > thread object. We may want to add START, STOP, CANCEL, and GETSTATE (maybe > can be overloaded by GET). With some basic set of extensions, we can write > applications that can control and monitor arbitrary transaction systems. > > Anyway, just some late night ramblings. > > //Joe > > This email message, and any attachments to it, are for the sole use of the > intended recipients, and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution of > this email message or its attachments is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy all > copies of the original message. > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Robert Leftwich wrote: > > Pauls' comment in 'REST/SOAP ideas summary' > (http://groups.yahoo.com/group/rest-discuss/message/1301) where he said > "The term REST has evolved (for better or worse) from what Roy Fielding > used it to mean..." prompted me to go back to the source and contrast it > with what is written at the front page of the REST wiki where it says "In > particular, REST suggests that what the Web got right is having a small, > global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a > potentially infinite set of nouns..." Nowhere in either of the standard > references to REST by Fielding does it suggest this at all, there is no > mention of nouns, verbs, coordination languages or even Unix pipelines for > that matter. I strongly agree that the front page of the Wiki emphasizes certain aspects that were central to a particular conversation at a particular time. I personally have found the "addressing" argument much more persuasive and easy to understand, so that is MY focus, even though it is not, er, addressed on the front of the Wiki. Also, I have long been concerned that the focus on a "small set of verbs" misses the point that it is not the small set that is central but rather their generality and commonality. Four, six, ten, fifty. It doesn't matter much as long as they are general. I've also come over time to see this argument as incomplete: "Another way of saying this is that REST works because it keeps interface complexity from scaling with N^2. In an infinite world of uncoordinated (i.e., independently developed) objects that interact with one another using specialized interfaces, the interface "connection" complexity is order N^2, because each object can have a unique interface to each other object. An infinite world of uncoordinated objects that share a common, generic interface, on the other hand, has only a complexity of order N, because no matter how many objects there are, they will all be able to act on one another in predictable ways." Let's be more explicit, we are pushing complexity around and hopefully reducing it but not competely changing its order notation. We are not going to take a purchase order client system and plug it into a content management system and expect them to just understand each other anytime soon. My sense is that REST helps by *centralizing* the incompatibilities in the vocabulary and stanardizating *as much as can be standradized* (which is certainly addressing and secondarily method names). And what I really meant when I said that the term REST had evolved included this noun/verb stuff but also a) the emphasis on addressing which is more implicit in Roy's writing, b) the sense that it is a competitor to web services c) the sense that it should even be used for web-service-like stuff (Roy has never said that to me...maybe he doesn't agree or maybe he just doesn't care) d) many of the best practices we send around which really are about "how to build applications on a REST framework" as opposed to "what is REST" (the difference between OO languages and OO design). BTW, in case anyone cares, ;), I am about to run off for the weekend but I'm downloading REST-related pages to do some writing and thinking about session handling, OO+REST etc. Paul Prescod
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > > Also, I have long been concerned that the focus on a "small > set of verbs" misses the point that it is not the small set > that is central but rather their generality and commonality. Shared understanding. A GET has shared meaning across the web (what's maybe not shared is when to prefer it). Anyone can implement it, any node can understand it. Speech acts for the masses. Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPO7fiuaWiFwg2CH4EQIQgACg3eUSMCAf6RKmPhYXMZgtKfLH9IIAn3gH 2JTUm+fgU2x3m5oBKp0TR6pC =aMA5 -----END PGP SIGNATURE-----
I gave a talk on REST on Friday. A woman in the audience made an excellent point: "In order to counteract all the hype around SOAP, you need to point out not only the differences in REST versus SOAP for today's Web services, but also the differences in enabling capability in tomorrow's environment [e.g., semantic Web]. It would be an easy step from your REST examples to RDF and ontology enabling, whereas with SOAP I'm not sure what would happen - like with firewalls, how could an inferencer do it's thing if the data is all buried inside?" She noted that DAML-S is REST-ful. This week I will talk to her more about this. /Roger P.S. I have added a lot more material to my REST tutorial (including the above comments). As always, feedback is much appreciate.
+cc: maxf@... On Sun, 26 May 2002, Roger L. Costello wrote: > I gave a talk on REST on Friday. A woman in the audience made an > excellent point: > > "In order to counteract all the hype around SOAP, you need to point out > not only the differences in REST versus SOAP for today's Web services, > but also the differences in enabling capability in tomorrow's > environment [e.g., semantic Web]. It would be an easy step from your > REST examples to RDF and ontology enabling This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding XSLT'd into RDF, and queried and stored using RDF tools. And *merged*, which is imho the interesting thing. Taking SOAP Encoded msgs from multiple sources and merging them into a single store, so that queries that need both info-sources to be answered can be serviced. The two worlds aren't as far apart as people suppose... More on this soon I hope, using the Ruby/RAA stuff as a testbed (see prev thread here on this...). cheers, Dan -- mailto:danbri@... http://www.w3.org/People/DanBri/
On Sunday 2002-05-26 at 15:51:14(-0400) Dan Brickley wrote: > > +cc: maxf@... > > On Sun, 26 May 2002, Roger L. Costello wrote: > > > I gave a talk on REST on Friday. A woman in the audience made an > > excellent point: > > > > "In order to counteract all the hype around SOAP, you need to point out > > not only the differences in REST versus SOAP for today's Web services, > > but also the differences in enabling capability in tomorrow's > > environment [e.g., semantic Web]. It would be an easy step from your > > REST examples to RDF and ontology enabling Interesting. I was watching a presentation on RDF a couple of weeks ago and came to the realization that for RDF to work properly it seems you have to have REST. RDF is all about links and you can't link to a SOAP endpoint because the SOAP endpoints are just conduits that listen for and dispatch SOAP messages. > > This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding > XSLT'd into RDF, and queried and stored using RDF tools. And *merged*, > which is imho the interesting thing. Taking SOAP Encoded msgs from > multiple sources and merging them into a single store, so that queries > that need both info-sources to be answered can be serviced. Yes, this makes sense. SOAP messages themselves are documents. But most people would ship those messages to SOAP listeners. They would not just put the messages at the end of a URI. > > The two worlds aren't as far apart as people suppose... This statement is true as far as SOAP messages are concerned. It's the SOAP RPC side of the coin that poses a challenge. > > More on this soon I hope, using the Ruby/RAA stuff as a testbed (see prev > thread here on this...). > > cheers, > > Dan > > > -- > mailto:danbri@... > http://www.w3.org/People/DanBri/ > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Allan Doyle http://www.intl-interfaces.com adoyle@...
On Sun, 26 May 2002, Allan Doyle wrote:
> On Sunday 2002-05-26 at 15:51:14(-0400) Dan Brickley wrote:
> >
> > +cc: maxf@...
> >
> > On Sun, 26 May 2002, Roger L. Costello wrote:
> >
> > > I gave a talk on REST on Friday. A woman in the audience made an
> > > excellent point:
> > >
> > > "In order to counteract all the hype around SOAP, you need to point out
> > > not only the differences in REST versus SOAP for today's Web services,
> > > but also the differences in enabling capability in tomorrow's
> > > environment [e.g., semantic Web]. It would be an easy step from your
> > > REST examples to RDF and ontology enabling
>
> Interesting. I was watching a presentation on RDF a couple of weeks
> ago and came to the realization that for RDF to work properly it seems
> you have to have REST. RDF is all about links and you can't link to a
> SOAP endpoint because the SOAP endpoints are just conduits that listen
> for and dispatch SOAP messages.
Yep. Using GET would fix a lot of this. I hear something like that is in
the works. A large % of (public) SOAP services seem to basically be database
lookups, so GETable data would be very useful.
>
> >
> > This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding
> > XSLT'd into RDF, and queried and stored using RDF tools. And *merged*,
> > which is imho the interesting thing. Taking SOAP Encoded msgs from
> > multiple sources and merging them into a single store, so that queries
> > that need both info-sources to be answered can be serviced.
>
> Yes, this makes sense. SOAP messages themselves are documents. But
> most people would ship those messages to SOAP listeners. They would
> not just put the messages at the end of a URI.
There are lots of unexpected uses for things in the Web. SOAP Encoding
files could reasonable turn up in tar.gz files, on CDROMs, attached to
mail messages, embedded in media objects. To the extent that it's a useful
data format, it should be usable outside of protocol transactions. Maybe
it deserves an application/??? content type?
> > The two worlds aren't as far apart as people suppose...
>
> This statement is true as far as SOAP messages are concerned. It's the
> SOAP RPC side of the coin that poses a challenge.
Oddly enough, I seem to be the only person who sees RDF as being
(technically) closer to the SOAP Encoding format, which in turn seems
mostly used for RPC interaction with SOAP services. Both variants pose a
challenge, that's for sure :)
Let me try to elaborate on the RDF <-> SOAP Encoding thing by example
(thanks to Max Foumentin and Holden Glova for help putting this together):
First a chunk of SOAP Enc XML, then the RDF, then the triples of the graph
that the latter encodes. If you can't read both SOAP Encoding and RDF
syntax, you'll have to take some of this on faith. Main message: the two
are pretty close, different XML encodings of a very similar data model.
So...
Here is some software description metadata, in SOAP Encoding format:
(here is your brain...)
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
<RAA_Info xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/" xmlns:n2="http://www.ruby-lang.org/xmlns/ruby/type/custom" xsi:type="n2:RAA_Info" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<category xsi:type="n2:RAA_Category">
<minor xsi:type="xsd:string">devel</minor>
<major xsi:type="xsd:string">Library</major>
</category>
<update xsi:type="xsd:dateTime">2000-10-12T19:10:26Z</update>
<owner xsi:type="n2:RAA_Owner">
<email xsi:type="xsd:string">gotoken@...</email>
<name xsi:type="xsd:string">gotoken</name>
<id xsi:type="xsd:string">gotoken@...-gotoken</id>
</owner>
<product xmlns:n3="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1" xsi:type="n3:Product">
<description xsi:type="xsd:string">xmp is an example printer, which is helpful to show example code.</description>
<version xsi:type="xsd:string">2000-10-12</version>
<license xsi:type="xsd:string">Ruby's</license>
<download xsi:type="xsd:string">http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz</download>
<status xsi:type="xsd:string">stable</status>
<homepage xsi:type="xsd:string">http://www.notwork.org/~gotoken/ruby/p/xmp/</homepage>
<name xsi:type="xsd:string">xmp</name>
</product>
</RAA_Info>
</env:Body>
</env:Envelope>
Here is some software description metadata, in an RDF/XML encoded format:
(here is your brain on drugs... ;-)
(thanks to an XSLT from Max; URL to follow another time)
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#" xmlns:raa="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<RAA_Info xmlns:n2="http://www.ruby-lang.org/xmlns/ruby/type/custom" xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<category rdf:parseType="Resource">
<rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Category"/>
<minor>devel</minor>
<major>Library</major>
</category>
<update>2000-10-12T19:10:26Z</update>
<owner rdf:parseType="Resource">
<rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Owner"/>
<email>gotoken@...</email>
<name>gotoken</name>
<id>gotoken@...-gotoken</id>
</owner>
<product xmlns:n3="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1" rdf:parseType="Resource">
<rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#Product"/>
<description>xmp is an example printer, which is helpful to show example code.</description>
<version>2000-10-12</version>
<license>Ruby's</license>
<download>http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz</download>
<status>stable</status>
<homepage>http://www.notwork.org/~gotoken/ruby/p/xmp/</homepage>
<name>xmp</name>
</product>
</RAA_Info>
</rdf:RDF>
Here is the result of feeding this to an RDF parser:
(a couple of parser bugs in this, which I won't bother fixing. the
product and update lines are wrong. ignore those please!)
this is a textual representation of the abstract graph structure, encoded
in the RDF and (indirectly) in the SOAP Encoding too.
first column is source object ID, second is URI of the relationship
that connects them, 3rd is target object ID or literal value. This format
is N-Triples, which the RDF Working Group use for test cases,
see http://www.w3.org/TR/rdf-testcases/ for more on format and its use in
testing and QA for RDF.
_:genid1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Info> .
_:genid2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Category> .
_:genid2 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#minor> "devel" .
_:genid2 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#major> "Library" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#category> _:genid2 .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#update> _:genid3 .
_:genid4 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Owner> .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#email> "gotoken@..." .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#name> "gotoken" .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#id> "gotoken@...-gotoken" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#owner> _:genid4 .
_:genid5 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#Product> .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#description> "xmp is an example printer, which is helpful to show example code." .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#version> "2000-10-12" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#license> "Ruby's" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#download> "http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#status> "stable" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#homepage> "http://www.notwork.org/~gotoken/ruby/p/xmp/" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#name> "xmp" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#product> _:genid5 .
The mapping (via Max's XSLT) had to make a few assumptions (eg. re
namespaces). But the basic graph structure is imho much the same. Mapping
SOAP Encoding with arrays etc might be fiddlier, or even impossible.
Nobody knows yet. Note also the current demo is w/ version 1.1 SOAP not
the 1.2 under development at W3C.
Why do I find this interesting?
The former format has a load of RPC-ish tools. They make it easy to map
the data into programmatic objects.
The latter format has a load of RPC-ish tools. They make it easy to merge
the data into RDF stores and query it with other URI-oriented data loaded
from other sources.
It'd be nice to use both sets of tools on the same data. Really nice...
Is this making any sense?
Dan
--
mailto:danbri@...
http://www.w3.org/People/DanBri/
Wow, awesome post. I too agree that the OO nature of REST is quite interesting. A REST component basically does all the things you'd expect of an object; has identity, encapsulated behaviour, supports inheritance through a type system such as RDF. Generic interfaces are also a feature of component based OO systems, such as Java Beans. The only thing REST doesn't do from an OO POV is hide data. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Hi Has anyone on this list taken a look at the OAI stuff? http://www.openarchives.org/ My impression is that the first version of their spec: http://www.openarchives.org/OAI/openarchivesprotocol.html Is quite RESTful but the new one is more SOAP like and not so RESTful: http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm However I must admit that I haven't fully got my head around their specifications... Any thoughts anyone? Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
On Mon, 27 May 2002, Chris Croome wrote: > Hi > > Has anyone on this list taken a look at the OAI stuff? > > http://www.openarchives.org/ Last I looked, and last I talked to Carl Lagoze about this, they weren't using HTTP content-negotiation where they probably could/should've. imho etc :) Dan -- mailto:danbri@... http://www.w3.org/People/DanBri/
On Mon, May 27, 2002 at 10:09:08AM -0400, Chris Croome wrote: > Hi > > Has anyone on this list taken a look at the OAI stuff? > > http://www.openarchives.org/ A quick look shows a "verb" attribute used in their URI, intended to perform some operation. Not a good sign. The verbs there seem safe, but they'll likely have problems in the future with URI evolution, if they continue to think of a URI parameter as an API. Also, what about when they make that information mutable, and instead of GetRecord, they want to SetRecord? Presumably a new URI would be required, rather than using PUT. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
------ Forwarded Message From: Jeff Bone <jbone@...> Date: Mon, 27 May 2002 21:30:33 -0500 To: Paul Prescod <paul@...> Subject: Re: [rest-discuss] The evolution of REST On 5/24/02 5:27 PM, "Paul Prescod" <paul@...> wrote: > I personally have found the "addressing" argument much more > persuasive and easy to understand, so that is MY focus, even though it > is not, er, addressed on the front of the Wiki. Everybody does, er, realize that the front page of the Wiki is open to change to reflect current consensus (or even personal opinion) at any time, by any person, without previous authorization or even discussion? That's the point of Wiki! Out of courtesy, it's probably not a good idea to enact gross changes without some discussion, but otherwise... I'm amenable to a change to reflect primary emphasis on addressability. I would simply ask that the rather stellar (ahem! ;-) quote that's cited from THE c2 wiki just be shoved further down page. (Grinz --- love being quoted, dont want to lose those somewhat-insightful words. :-) > > Also, I have long been concerned that the focus on a "small set of > verbs" misses the point that it is not the small set that is central but > rather their generality and commonality. Four, six, ten, fifty. It > doesn't matter much as long as they are general. Actually, I *do* believe this number is critically important. That number is an exponential factor, not a multiplicative constant, in determining the compositional complexity of any software system. At some point --- maybe, modulo more commercial concerns --- I may trot out the mathematical argument here. But I think this is the under-recognized and supremely important aspect of the meta-theory behind REST: the "width" and variety of interfaces has a direct and geometric impact on the overall complexity of systems that use those interfaces... > Let's be more explicit, we are pushing complexity around and hopefully > reducing it but not competely changing its order notation. This argument is no more and no less compelling and authoritative than its contrary --- it relies on an intuitive, unsupported, and potentially "superstitious" notion that there is some canonically meaningful notion of complexity that is static across all formulations. An even simpler notion of complexity --- lines of code --- may in fact be canonically meaningful but is *certainly* not static across all formulations; and the argument for reduction of compositional complexity via interface minimization relies on just that notion. Jb ------ End of Forwarded Message
On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote: > Wow, awesome post. I too agree that the OO nature of REST is quite > interesting. A REST component basically does all the things you'd > expect of an object; has identity, encapsulated behaviour, supports > inheritance through a type system such as RDF. Generic interfaces > are also a feature of component based OO systems, such as Java Beans. > The only thing REST doesn't do from an OO POV is hide data. IMO, the problem -w- REST v. OOP is identical to the problem which has long plagued me [1] -w- OOP v. generative communication ala Linda. This is not to say that REST and generative communication are identical or directly analogous, but IMO they bear many interesting similarities... Jb [1] http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr o.Corp.Sun.COM&rnum=1
On Mon, 27 May 2002, Jeff Bone wrote: > On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote: > > > Wow, awesome post. I too agree that the OO nature of REST is quite > > interesting. A REST component basically does all the things you'd > > expect of an object; has identity, encapsulated behaviour, supports > > inheritance through a type system such as RDF. Generic interfaces > > are also a feature of component based OO systems, such as Java Beans. > > The only thing REST doesn't do from an OO POV is hide data. > > IMO, the problem -w- REST v. OOP is identical to the problem which has long > plagued me [1] -w- OOP v. generative communication ala Linda. This is not > to say that REST and generative communication are identical or directly > analogous, but IMO they bear many interesting similarities... Yes, I came to this view too... various links hoarded in... http://lists.w3.org/Archives/Public/xml-dist-app/2000Mar/0055.html BTW I ran into an old WWW4 paper on WWW Meets Linda that was quite interesting, http://www.w3.org/Conferences/WWW4/Papers/174/ and based around actual implementation (a Perl Linda). Dan > > Jb > > [1] > http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr > o.Corp.Sun.COM&rnum=1
Mark, I hadn't thought of RDF as a type of inheritance, but that is a neat idea. In essence, it is a bit like defining a base class or a virtual class. Regarding the hiding of data in OOP, I actually think even that has similarities, per below. Dan, Jeff, I can definitely see the similarities in the discussion between OOP vs. REST and OOP vs. generative communication ala Linda. However, let me try to reframe this discussion. I've always viewed objects in OOP as both data and active agent. That is why I really see such commonality between URIs and objects. URI's are resources, not necessarily data. Treating all URIs as data is certainly useful, but so is treating them as active agents. Thus, I don't actually think OOP itself encourages hiding of data per se, rather that is an artifact of distributed object systems like CORBA or SOAP-RPC. In OOP systems such as C++, the result of a call returns objects which are fully addressable. This is not so in CORBA or SOAP-RPC since the results are not addressable objects, but pure data that fall completely outside of the namespace. Historically, one of the biggest issues of distributed programming is that it is difficult to pass by reference. Thus, you have to pass the entire data from one addressing space to another (thus RPCs). If we think of the URI naming system as an universal addressing space - we are in essence creating the ability to pass by reference - isn't that what a link is, after all? It should be possible to build a full-blown distributed OOP system that is based on the internet URI addressing space. Issues like object persistence and cost of access will need to be resolved, but I don't think there are insurmountable obstacles. I believe the resulting system would be not only RESTful, but present a more familiar model of programming for developers. //Joe -----Original Message----- From: Dan Brickley [mailto:danbri@...] Sent: Monday, May 27, 2002 9:58 PM To: Jeff Bone Cc: Mark Baker; rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] REST-OO? On Mon, 27 May 2002, Jeff Bone wrote: > On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote: > > > Wow, awesome post. I too agree that the OO nature of REST is quite > > interesting. A REST component basically does all the things you'd > > expect of an object; has identity, encapsulated behaviour, supports > > inheritance through a type system such as RDF. Generic interfaces > > are also a feature of component based OO systems, such as Java Beans. > > The only thing REST doesn't do from an OO POV is hide data. > > IMO, the problem -w- REST v. OOP is identical to the problem which has long > plagued me [1] -w- OOP v. generative communication ala Linda. This is not > to say that REST and generative communication are identical or directly > analogous, but IMO they bear many interesting similarities... Yes, I came to this view too... various links hoarded in... http://lists.w3.org/Archives/Public/xml-dist-app/2000Mar/0055.html BTW I ran into an old WWW4 paper on WWW Meets Linda that was quite interesting, http://www.w3.org/Conferences/WWW4/Papers/174/ and based around actual implementation (a Perl Linda). Dan > > Jb > > [1] > http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr > o.Corp.Sun.COM&rnum=1 Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
I worked on a set of related Rest-Wiki pages over the weekend: http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext http://internet.conveyor.com/RESTwiki/moin.cgi/RestifiedPurchasing http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi rements Topics include the subject of this message, plus: * Sessions * Transactions * Purchasing * Travel arrangements We've discussed all of these topics several times on this list, but the advantage of the Wiki is to give the topics an identity and converge all the ideas into one set of resources. So for example when "purchase orders" come up again, as they did last week, there is a reference available. The pages are by no means complete. Purchasing is fleshed out a lot more than any of the others. Paul indicated he was working on sessions, so I left that part completely blank. But I am personally going to give it a rest for a while and see if anybody else think it's useful enough to contribute. It's a wiki, so feel free to edit. I'm sure I missed something and screwed up something else. Have fun, Bob Haugen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Jeff Bone [mailto:jbone@...] > > On 5/24/02 5:27 PM, "Paul Prescod" <paul@...> wrote: > > > > > Also, I have long been concerned that the focus on a "small set > > of verbs" misses the point that it is not the small set that > is central > > but rather their generality and commonality. Four, six, > ten, fifty. It > > doesn't matter much as long as they are general. > > Actually, I *do* believe this number is critically important. > That number is an exponential factor, not a multiplicative > constant, in determining the compositional complexity of any > software system. At some point --- maybe, modulo more > commercial concerns --- I may trot out the mathematical > argument here. But I think this is the under-recognized and > supremely important aspect of the meta-theory behind REST: > the "width" and variety of interfaces has a direct and > geometric impact on the overall complexity of systems that > use those interfaces... All this assumes that verb count at least correlates with managing complexity if not actually reducing it. In the not unrelated world of speech act theory, the prevalent view seems to be that there is no natural restriction on performatives (verb) count; as soon as we've written down all the ones we think we need, we're done. The main thing is to clearly define what those verbs mean. I haven't seem arguments against extending the verb set over time. The original KQML took some flack, not dissimilar to that of RDF's by logicians, for having imprecisely defined verbs. FIPA-ACL attempts to address this by having clear semantics for its verbs (and one assumes then, shared behaviours). There are quite a few verbs in KQML and FIPA-ACL. I imagine there is an assumption that if the verb set is well grounded, the meaning and intention of new verbs can be inferred, not unlike the assumptions surrounding RDF and semantic web entities. That's a different kind of software than is written in the middleware trenches today. Contrast this with the RPC extension mechanism, the procedure, which is the ad-hoc addition of new verbs. Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPPN/W+aWiFwg2CH4EQLcEgCg6XlQrMltwf2Ar3+H4qyEUbr3uP4AoJFc kFoKLnH1kVNpl5Iaz9SHBFRe =IZVq -----END PGP SIGNATURE-----
Dan Brickley wrote: > This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding > XSLT'd into RDF, and queried and stored using RDF tools. And *merged*, > which is imho the interesting thing. Taking SOAP Encoded msgs from > multiple sources and merging them into a single store, so that queries > that need both info-sources to be answered can be serviced. > I forwarded Dan's message to the woman whom I quoted earlier. Here's her response: "Yeah, you can turn soap into rdf and do the merging thing, but I guess what I don't see is how soap is better than daml-s for describing and manipulating complex services. Maybe I haven't looked at soap closely enough, but I've never seen examples with it that can express conditional inputs and outputs, ordering and dependencies of subprocesses, etc that you can do in daml-s. And if it's just a straight, simple information producing service, then you don't necessarily need either one [if you're not concerned with being automatically brokered]" /Roger
FYI: A web site illustrating the SOAP and REST styles for querying astronomical data. http://www.orbitarium.com/soap.html http://www.orbitarium.com/rest.html Example REST URL to get geocentruc position information about Mars:: http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPosition&planet=Mars /Roger
On Tue, May 28, 2002 at 01:42:31PM -0400, Roger L. Costello wrote: > FYI: A web site illustrating the SOAP and REST styles for querying > astronomical data. > > http://www.orbitarium.com/soap.html > http://www.orbitarium.com/rest.html > > Example REST URL to get geocentruc position information about Mars:: > > http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPo > sition&planet=Mars Interesting. That URI structure has problems though; try building an HTML form to use the REST/GET based service. You can't, cleanly; you'd have to use a hidden form field called "method". Best just to have a URI like this; http://www.orbitarium.com/geocentricPosition?planet=Mars MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tuesday 2002-05-28 at 14:06:08(-0400) Mark Baker wrote:
> On Tue, May 28, 2002 at 01:42:31PM -0400, Roger L. Costello wrote:
> > FYI: A web site illustrating the SOAP and REST styles for querying
> > astronomical data.
> >
> > http://www.orbitarium.com/soap.html
> > http://www.orbitarium.com/rest.html
> >
> > Example REST URL to get geocentruc position information about Mars::
> >
> > http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPo
> > sition&planet=Mars
>
> Interesting. That URI structure has problems though; try building an
> HTML form to use the REST/GET based service. You can't, cleanly;
> you'd have to use a hidden form field called "method".
>
> Best just to have a URI like this;
>
> http://www.orbitarium.com/geocentricPosition?planet=Mars
Or how about
http://www.orbitarium.com/mars/geocentricPosition
http://www.orbitarium.com/mars/heliocentricPosition
...
http://www.orbitarium.com/mercury/geocentricPosition
http://www.orbitarium.com/mercury/heliocentricPosition
with
http://www.orbitarium.com/mars/geocentricPosition/julianDate?2452321.0
http://www.orbitarium.com/mars/heliocentricPosition/julianDate?2452321.0
...
and having all these linked from a top level page:
http://www.orbitarium.com
Mercury: Geocentric Position, Heliocentric Position...
Venus : Geocentric Position, Heliocentric Position...
Earth : Heliocentric Position...
Mars : Geocentric Position, Heliocentric Position...
...
Much of the benefit of REST is that resource documents are
findable via link traversal, meaning that there's an entry point that
provides a way to navigate to the greatest level of detail/information
possible. If Google picks up the top level, you will be able to do a
search on "mars geocentric position" and find the document with the
current position instantly.
Furthermore, if you include decent documentation in the XML responses,
then you increase your chances of it being found in a search.
Also, to complete the job, you probably want to indicate to the http
servers (httpd, squid, akamai, etc.) that the pages with "current"
position are not to be cached, but pages with an absolute time can be
cached.
Content negotiation can be used to provide the same info in various
languages or return formats.
I think the way to approach a REST design is to decide how to set up a
document hierarchy that conveys the most information without having to
resort to parameters to pass arguments.
Allan
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA. distobj@...
> http://www.markbaker.ca http://www.idokorro.com
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle http://www.intl-interfaces.com
adoyle@...
On Tue, May 28, 2002 at 04:39:59AM -0400, Joe Hsy wrote: > It should be possible to build a full-blown distributed OOP system that > is > based on the internet URI addressing space. How do you see this being any different than the Web? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Hi Mark,
I was not thinking different from the web, but building on the web. As we
talked about, there are already many attributes the current web and the REST
architecture that can be seen as object-oriented. But much of it is not
explicitly laid out and there are also some OO concepts that could use some
additional support tools.
I guess by full-blown, I meant fleshing it out from the current base set and
to create tools for current OOP programmers to be able to program for the
web using a familiar development environment.
Let me use the recently discussed orbitarium example (with the URI
variations suggested by you and Allan Doyle) and see how a standard java
programmer may want to access and manipulate such a resource:
Assuming there is an RDF description of the orbitarium which describes the
orbitarium:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:o="http://www.orbitarium.com/planets/vocab#">
<rdf:Description rdf:about="http://www.orbitarium.com/about">
<o:planets>
<rdf:Seq>
<rdf:li
rdf:resource="http://www.orbitarium.com/planets/Mercury"/>
<rdf:li rdf:resource="http://www.orbitarium.com/planets/Venus"/>
<rdf:li rdf:resource="http://www.orbitarium.com/planets/Mars"/>
</rdf:Seq>
</o:planets>
</rdf:Description>
</rdf:RDF>
Ignoring that earth is the 3rd planet, it would nice to have a tool that
reads the RDF and instantiates an orbitarium object and the 3 planets
objects which map directly to these resources. As an example, the class
definition generated for the orbitarium could be something like this:
class Orbitarium {
String about;
Vector planets;
}
class Planet {
String resource;
Float GetGeocentricPosition() {
return GET(resource+"/GeocentricPosition");
}
Float GetHeliocentricPosition() {
return GET(resource+"/HeliocentricPosition");
}
}
Note that these objects are in essence "references" to the source objects.
There are probably some way to make these types of URI references a real
reference type in the program's addressing space, but that isn't necessary
to make this work.
I can now write a display program that can plot the planet orbits over time
using the existing programming methodologies, despite the fact that the
source of the data is sitting somewhere else on the web.
And if I create the charts in SVG, it would be great if I have a tool that
takes my planet chart object and publish it by generating an RDF file. And
in fact I can include in my publishing call the original planet objects
(assuming proper publishing rights are observed):
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:j="http://www.joesorbitarium.com/planets/vocab#"
xmlns:o="http://www.orbitarium.com/planets/vocab#">
<rdf:Description rdf:about="http://www.joesorbitarium.com/about">
<j:planetcharts>
<rdf:Seq>
<rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Mercury"/>
<rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Venus"/>
<rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Mars"/>
</rdf:Seq>
</j:planetcharts>
<o:planets>
<rdf:Seq>
<rdf:li
rdf:resource="http://www.orbitarium.com/planets/Mercury"/>
<rdf:li rdf:resource="http://www.orbitarium.com/planets/Venus"/>
<rdf:li rdf:resource="http://www.orbitarium.com/planets/Mars"/>
</rdf:Seq>
</o:planets>
</rdf:Description>
</rdf:RDF>
I'm not an RDF expert, so forgive me if some of this is not proper usage.
But, my main point is that one of the reasons SOAP was getting momentum is
that it presents a familiar programming model. I think we can do the same
with REST by presenting not an RPC model, but a OOP model for building
RESTful applications.
//Joe
-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Tuesday, May 28, 2002 12:35 PM
To: Joe Hsy
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] REST-OO? (URIs as passing by reference)
On Tue, May 28, 2002 at 04:39:59AM -0400, Joe Hsy wrote:
> It should be possible to build a full-blown distributed OOP system that
> is
> based on the internet URI addressing space.
How do you see this being any different than the Web?
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
> ----- Original Message ----- > From: "Jeff Bone" <jbone@...> > Everybody does, er, realize that the front page of the Wiki is open to > change to reflect current consensus (or even personal opinion) at any time, > by any person, without previous authorization or even discussion? I've been thinking that the front page needs a more direct summary of REST as well as a clarification of REST .vs. resource modeling. I see the term REST used where a more narrow term would be better - I like 'resource modeling' for that. Here is my suggestion of a direct summary of REST and an explanation that the 'information architecture' aspect is mainly what people are talking about. Comments welcome... -- mike's summary -- REST is an architectural style for building large-scale networked applications. It is a description of the facets of the WWW that made the Web so successful. REST describes a networked system in terms of - data elements (resource, resource identifier, representation) - connectors (client, server, cache, resolver, tunnel) - components (server, gateway, proxy, user agent) Data elements are accessed through a standardized interface. Components communicate by transferring representations of resources through this interface rather than operating directly upon the resource itself. Connectors present an abstract interface for component communication, hiding the implementation details of communication mechanisms. Components use connectors to access, provide access or mediate access to resources. It is important that intermediaries are an explicit aspect of the architecture. Since REST is an extracted description of the WWW, it is no suprise that the protocol that exhibits the most number of these aspects is HTTP. However, REST and HTTP are separate concepts - it is entirely possible to apply REST concepts to other protocols and systems. Since most people see the immediate value of components and connectors, most discussion has been focused on the 'information architecture' aspects of REST - resources, representations, URIs, standardized interfaces, etc. This area is informally known as 'resource modeling'. Most examples are framed in HTTP messages and URI addressable resources. The theory is that many complex systems can be fully described and implemented with just pure HTTP. --
Bob's adding of the travel agent scenario to the 'State machine as hypertext' wiki page along with the comment 'No attempts to RESTify this example have been reported' prompted me to try out my REST skills - be warned, the training wheels are still on:-)
The resources modelled are similar to those identified in the original document:
TripIdentifier
Participants
Participant1
Participant2
....
ParticipantN
Journey
Stage1
Stage2
....
StageN
A full uri could be http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday for a planned but not yet requested (i.e. a sandbox) and http://www.mytravel.com/person_identifier/trips/requested/XML2002 for a started but not yet fully authorized trip (i.e. tickets issued) and http://www.mytravel.com/person_identifier/trips/issued/XML2001 for a trip whose tickets have been issued.
The traveller could play in his sandbox to his hearts content, adding participants in the REST manner (i.e. doing a POST to /JulyHoliday/Particpants to get a uri for a new participant - /JulyHoliday/Particpants/ParticipantN and then performing a PUT to that uri using the appropriate participant representation [an XML structure containing first-name, last-name, address and birthdate, where an address consists of a street, city, state, zip, email and phone]) and deleting participants by using an http DELETE. Similarly, the requisite stages could be added as required.
Once completed, the traveller could request the trip be organized , which could be done by the a POST/PUT combination to /requested/HulyHoliday/ using the composite xml structure obtained from a GET to /planned/JulyHoliday/ (note that optionally the planned version could be preserved, otherwise it is deleted via http DELETE - what about integrity issues here, i.e. the DELETE failing?)
Now it gets interesting - how does the travel agent know that a new trip has been requested and start the ball rolling? One way would be to have a resource /trips/requested/new which the individual travel agents subscribe to using the techniques described in HttpEvents. When a new trip is requested a notification containing the new trip uri is sent to all the subscribers. The difficulty with this approach is that in the case of multiple travel agents, how is the new trip assigned to one and only one agent and how are all the other agents notified that the trip is now assigned to an agent and is no longer available?
Once an agent accepts responsibility for a trip, they will add the requisite legs to the trip using POST/PUT to the uri /requested/JulyHoliday/legs/planned/ ending up with a uri /requested/JulyHoliday/legs/planned/leg1..n and once this is completed the agent could request the specified legs by moving them to the /requested/JulyHoliday/legs/requested/ uri. The airline could be notified of the requested legs (HttpEvents via email?) and it could POST to /requested/JulyHoliday/legs/confirmed/leg1...n with the relevant seat information, etc as each leg is confirmed. (Hmm... what happens to /legs/requested/...?).
It's getting late and my brain is shutting down. I hope this makes sense to someone else and can be used as the basis for a discussion.
Robert
Robert, I'm swamped today, but will study your article and follow the feedback as I get time. But when you think it a coherent story has emerged, please consider publishing it on the Wiki. Maybe spin a new page off the section that is sort of begging for a RESTification? Or even before it's coherent. Wikis are good for group-annealing of documents. Maybe the mailing list is better for discussion, I don't know. And maybe if the Wiki pages get really good, some of us can put together an article for one of the Web mags, cleaning up the best of the Wiki content. -Bob Haugen
I noticed your email address on a list serve related to technology and web development. Our company has developed a simple, risk-free and cost effective method of generating leads and creating awareness for your Company through targeted email marketing. Please read on to find out more about this awesome service. The process: You provide us with keywords pertaining to your company's target market. Using our proprietary spider software, we spider the Internet searching for email addresses that are on pages that match those keywords. We setup a database driven form, which allows the prospect to input their contact, company, and any other relative information that you may require. We send emails to the addresses collected. These emails do not contain your companys name, so that your company is protected. Once the prospect has filled out and submitted their information, the data is automatically written to a database. You may then login to our web driven application and view the current leads that have been submitted. Results: We typically provide our clients with anywhere from 30 200 leads per week with our standard package depending on: Target market Keywords used Product pricing We will help develop a customized system for your company that will ensure maximum return. Pricing: Our standard package includes the following: HTML email design and implementation Form and database setup Over 100,000 emails distributed per month (done on a weekly basis) Email address collection and filtering Cost: $775 per Month - Our standard pricing is $1500 per month, but if you order before June 6th 2002 we will do it for this low price as long as you are our customer. The above price is all-inclusive, and no other charges will be incurred. We can also provide higher quantities of distribution if required. Please contact us for details. If you would like more information on our services or would like to get started please click here Cordially, Gary Michaels
At 01:17 AM 30/05/2002, bhaugen32 wrote: >But when you think it a coherent story has emerged, please consider >publishing it on the Wiki. Maybe spin a new page off the section >that is sort of begging for a RESTification? That was the plan. >Or even before it's coherent. Wikis are good for group-annealing of >documents. Maybe the mailing list is better for discussion, I don't >know. I feel that the mailing list is better for discussion and I wanted to make sure it is a valid starting point/direction before putting it on the wiki. If we can knock off the really rough edges (or, to continue the analogy, start with a new piece of wood if it is not the right colour/size/quality/etc) then the wiki can/may help finish it off. >And maybe if the Wiki pages get really good, some of us can put >together an article for one of the Web mags, cleaning up the best of >the Wiki content. Sounds like an excellent idea. Robert
I added some new pages to the Wiki. http://internet.conveyor.com/RESTwiki/moin.cgi/ShortSummaryOfRest http://internet.conveyor.com/RESTwiki/moin.cgi/AccessThroughRepresentations Comments and corrections welcome.
"S. Mike Dierken" wrote: > I added some new pages to the Wiki. > > http://internet.conveyor.com/RESTwiki/moin.cgi/ShortSummaryOfRest > http://internet.conveyor.com/RESTwiki/moin.cgi/AccessThroughRepresenta tions > > Comments and corrections welcome. Mike, thank you very much! Both of the above are necessary and important. Assuming you want to use rest-discuss for quibbles, here's one: >REST describes a networked system in terms of > data elements (resource, resource identifier, representation) I don't think "data element" is an accurate description of a resource. I think resources are much more like large-grained very generic objects in that they have methods and identity. Even the representation does not need to be limited to "just data" (unless we consider everything to be "just data"). Maybe "object" is not the correct word, either, but it's closer than "data element". -Bob Haugen
> ----- Original Message ----- > From: "bhaugen32" <bhaugen32@...> > Assuming you want to use rest-discuss for quibbles, here's one: > >REST describes a networked system in terms of > > data elements (resource, resource identifier, representation) > I don't think "data element" is an accurate description of a > resource. I think resources are much more like large-grained very > generic objects in that they have methods and identity. Even the > representation does not need to be limited to "just data" (unless we > consider everything to be "just data"). I used 'data element' because that was the term from Roy's dissertation. I think 'data element' is a category of features of a networked architecture - as compared with message flow or processing units/components or whatever. I would like to clear up the ambiguity though - how about: "The REST documents describe networked systems in terms of three architectural concepts: data elements, components and connectors. Specifically, REST uses these instances of the concepts: data elements : resource, resource identifier, representation (etc...) "
"S. Mike Dierken" wrote: > > > ----- Original Message ----- > > From: "bhaugen32" <bhaugen32@y...> > > > Assuming you want to use rest-discuss for quibbles, here's one: > > >REST describes a networked system in terms of > > > data elements (resource, resource identifier, representation) > > > I don't think "data element" is an accurate description of a > > resource. I think resources are much more like large-grained very > > generic objects in that they have methods and identity. Even the > > representation does not need to be limited to "just data" (unless we > > consider everything to be "just data"). > > I used 'data element' because that was the term from Roy's dissertation. > I think 'data element' is a category of features of a networked > architecture - as compared with message flow or processing units/components > or whatever. Ok, I re-examined the dissertation and see where you got "resource = data element". Table 5-1, right? So who am I to say different? Still don't make any sense to me, especially if I read the next paragraph of the dissertation: "5.2.1.1 Resources and Resource Identifiers The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent." Doesn't smell like a data element to me. But I suppose the cat is out of the bag, huh? > I would like to clear up the ambiguity though - how about: > > "The REST documents describe networked systems in terms of three > architectural concepts: data elements, components and connectors. > Specifically, REST uses these instances of the concepts: > data elements : resource, resource identifier, representation > (etc...) Doesn't resolve the problem in my mind, which is that resources are different kinds of things from representations. I'll withdraw my objection, though, since I am but a pup amongst the big dogs on this corner...
----- Original Message ----- From: "bhaugen32" <bhaugen32@...> > Doesn't resolve the problem in my mind, which is that resources are > different kinds of things from representations. They are different - but they are 'data' concepts, as opposed to 'procedural coding library' concept. You can look at REST in different ways - in terms of its static data aspects, in terms of layers and APIs, in terms of logic elements, etc. > I'll withdraw my objection, though, since I am but a pup amongst the > big dogs on this corner... Don't do that... we need fresh meat all the time ;)
Seems to me that REST fits right in with evolving the Web into a Semantic Web. /Roger FYI, As seen in ShelfLife: http://lists2.rlg.org/cgi-bin/lyris.pl?visit=shelflife-from-rlg&id=181277488 > HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB > The evolution of the Semantic Web -- the ongoing project of > developing computer languages that depict information in a form that > both humans and machines can process -- could benefit from the > models, systems and lessons learned within the hypermedia community, > according to a trio of Dutch hypermedia researchers. In fact, say > Jacco van Ossenbruggen, Lynda Hardman and Lloyd Rutledge, the > primary model for many hypermedia systems is directly applicable to > the Semantic Web. Hypermedia systems are, basically, structured > databases (in various media -- audio, video, etc.) with pieces of > information (called nodes) and links to related pieces of > information. These systems typically denote link access points or > link "anchors" in some manner within a node when it's displayed on a > computer screen, such as underlined text displayed within documents > on the Web. In order to annotate a specific portion of a Web > resource, it needs an anchoring mechanism, and to establish a > relationship between the annotation and the target resource, a > linking model is necessary. Such elements will be paramount in the > development of the Semantic Web, say the researchers. (Journal of > Digital Information 17 May 2002) http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/
On Fri, 31 May 2002, Roger L. Costello wrote: > Seems to me that REST fits right in with evolving the Web into a > Semantic Web. /Roger Absolutely! BTW that URL doesn't work for me. Aha, you meant http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/ not the rlg.org one. The RDF model is a natural extension of the typed links approach in hypermedia. This was clear right from TimBL's original proposal for the creation of the Web (wonder why it's taken us so long...). I've a half-finished bunch of notes on this at http://www.w3.org/1999/11/11-WWWProposal/thenandnow (2.5 yrs old!), or go straight to the original... http://www.w3.org/History/1989/proposal.html Dan > FYI, As seen in ShelfLife: > http://lists2.rlg.org/cgi-bin/lyris.pl?visit=shelflife-from-rlg&id=181277488 > > HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB > > > The evolution of the Semantic Web -- the ongoing project of > > developing computer languages that depict information in a form that > > both humans and machines can process -- could benefit from the > > models, systems and lessons learned within the hypermedia community, > > according to a trio of Dutch hypermedia researchers. In fact, say > > Jacco van Ossenbruggen, Lynda Hardman and Lloyd Rutledge, the > > primary model for many hypermedia systems is directly applicable to > > the Semantic Web. Hypermedia systems are, basically, structured > > databases (in various media -- audio, video, etc.) with pieces of > > information (called nodes) and links to related pieces of > > information. These systems typically denote link access points or > > link "anchors" in some manner within a node when it's displayed on a > > computer screen, such as underlined text displayed within documents > > on the Web. In order to annotate a specific portion of a Web > > resource, it needs an anchoring mechanism, and to establish a > > relationship between the annotation and the target resource, a > > linking model is necessary. Such elements will be paramount in the > > development of the Semantic Web, say the researchers. (Journal of > > Digital Information 17 May 2002) > http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/ > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
I'm ready to try to take one more baby step in this conversation. This baby step focuses on URI-per-entity vs URI-per-state. Robert Leftwich wrote: > The resources modelled are similar to those identified in the original document: > > TripIdentifier > Participants > Participant1 > Participant2 > .... > ParticipantN > Journey > Stage1 > Stage2 > .... > StageN > > A full uri could be > http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday > for a planned but not yet requested (i.e. a sandbox) and > http://www.mytravel.com/person_identifier/trips/requested/XML2002 > for a started but not yet fully authorized trip > (i.e. tickets issued) and > http://www.mytravel.com/person_identifier/trips/issued/XML2001 > for a trip whose tickets have been issued. I'm very skeptical of changing the URI of a business entity whenever it changes state. I think the URI should be the permanent identity of the business entity and its state should be represented either by data elements or hyperlinks. Paul Prescod and I have discussed this before; Paul may like having the URI change per state. So don't necessarily take my word for this. But I think increasingly business entities will be hyperlinked together. The states of the business entities will be very important, but so are the hyperlinks. What happens to the hyperlinks if the URIs change? -Bob Haugen
At 01:35 AM 1/06/2002, bhaugen32 wrote:
>Robert Leftwich wrote:
>> A full uri could be
>> http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday
>> for a planned but not yet requested (i.e. a sandbox) and
>> http://www.mytravel.com/person_identifier/trips/requested/XML2002
>> for a started but not yet fully authorized trip
>> (i.e. tickets issued) and
>> http://www.mytravel.com/person_identifier/trips/issued/XML2001
>> for a trip whose tickets have been issued.
>
>I'm very skeptical of changing the URI of a business entity whenever
>it changes state.
Could you perhaps use the concept of permalink (from the blogging world?) where there is a permanent link for the resource, but also alternative 'views' on the resources that are state-based? Something like:
permalinks -
http://www.mytravel.com/person_identifier/trips/XML2001/
http://www.mytravel.com/person_identifier/trips/JulyHoliday/
...
alternative state-based 'views'
http://www.mytravel.com/person_identifier/trips/planned/
http://www.mytravel.com/person_identifier/trips/issued/
...
alternative views would return collections of resources that match the view, using the permalinks i.e. http://www.mytravel.com/person_identifier/trips/planned/ would return :
<trips>
<trip permalink='http://www.mytravel.com/person_identifier/trips/Xmas2002/'
link='http://www.mytravel.com/person_identifier/trips/panned/Xmas2002/' />
<trip permalink='http://www.mytravel.com/person_identifier/trips/Easter2003/'
link='http://www.mytravel.com/person_identifier/trips/panned/Easter2003/' />
....
</trips>
Anyone using a state-based link to a trip that is no longer in that state would receive a 301 moved status code with the link to the current state.
You could still use the state-based uri to manipulate the state as mentioned in the OP.
Still, I feel a little uneasy about the existence of more than 1 URI for the same resource, but this happens all the time on the web and the 3xx status codes show that this behavior was identified and catered for.
>I think the URI should be the permanent identity of the business
>entity and its state should be represented either by data elements or
>hyperlinks.
Can you give an example of state being represented by hyperlinks?
Robert
PS Anyone else feel that email is definitely NOT the best medium for brainstorming ideas. It's hard to beat a bunch of people locked in a room to sort out a few things :-(
----- Original Message ----- From: "Robert Leftwich" <robert@...> > Bob's adding of the travel agent scenario to the 'State machine as hypertext' wiki page along with the comment 'No attempts to RESTify this example have been reported' prompted me to try out my REST skills - be warned, the training wheels are still on:-) > > The resources modelled are similar to those identified in the original document: > > TripIdentifier > Participants > Participant1 > Participant2 > .... > ParticipantN > Journey > Stage1 > Stage2 > .... > StageN > If I'm reading this right, it sounds like you are making each item a full resource. To me, the data called out in the original document (appended at the end of the message) don't necessarily need to be full URI resources. I don't see the URIs, their structure or nesting as all that important. In the nested text shown above, the Participant1 could be an independent entity that is merely referenced by the trip, rather than being 'subordinate' to the trip resource. Here's how I would do it: The information types seem to be 'traveler', 'trip', 'stage', 'participant', etc. I'd start with a coarse-grained resource like 'trip' and expand out into 'traveler' or 'participant' if necessary. Within, I'd have an XML blob with details and any useful links. The resources I generated in walking through this are: -- submit a new trip -- http://services.travelagents.com/trips/ -- new trip that was created -- http://services.travelagents.com/trips/0173/ -- callbacks for airline to confirm reservations -- http://services.travelagents.com/trips/0173/airline/ack/ http://services.travelagents.com/trips/0173/airline/status/ -- submit new reservations -- http://services.airliner.com/reservations/ -- new reservation that was created -- http://reservations.airliner.com/agents/travelagents.com/res-0029/ Note - the URIs do /not/ have to be related textually - the URI of the new reservation at the airline is even on a different host for example. The connection between all these is through HTTP headers, or they could also be done via href's inside some XML. -- step one -- The overall flow of this example is as follows: A traveler will plan her trip by specifying the various stages of his overall journey and all of its participants. For each of the stages, the traveler specifies the location that she wants to visit as well as the date when she wants to begin and the date when she wants to end the particular stay. When the traveler is finished with this, she sends this information together with the list of all participants of the trip as well as the information about the credit card to be charged for the ordered tickets to the travel agent. == Create a new trip === POST http://services.travelagents.com/trips/ HTTP/1.1 Content-Type: text/xml Content-Model: TripSpecification <trip> <stage> <location>maui</location> <start>immediately</start> <finish>never</finish> </stage> <participant> <name>Mike</name> </participant> <payment>VISA</payment> <recipient>mdierken@...</recipient> </trip> == Acknowledgement of submission (with location of trip) == HTTP/1.1 202 Accepted Location: http://services.travelagents.com/trips/0173/ -- step two -- The credit card information has been passed when the business process was instantiated. Next, the traveler will await the submission of the electronic tickets as well as the final itinerary for the trip. -- step three -- When the agent receives the traveler's trip order, he will determine the legs for each of the stages, which includes an initial seat reservation for each of the participants as well as the rate chosen. To actually make the corresponding ticket orders the agent submits these legs together with the information about the credit card to be charged to the airline company. == Create new reservations at airline === POST http://services.airliner.com/reservations/ HTTP/1.1 Reply-To: http://services.travelagents.com/trips/0173/airline/ack/ Status-To: http://services.travelagents.com/trips/0173/airline/status/ Content-Type: text/xml Content-Model: ReservationRequest Authenticiation: Basic [travelagents:password] <reservation> <!-- URI of secure payment verification callback - the airlines have to auth to get in --> <payment>http://services.travelagents.com/payment/verification/xyz/</payment > <recipient>mdierken@...</recipient> <leg> <flight>UA-1024</flight> <seat>33A</seat> <rate>$12.00</rate> </leg> <leg> <flight>NW-832</flight> <seat>22B</seat> <rate>$12.00</rate> </leg> </reservation> == Acknowledgement of submission (with location of reservation) == HTTP/1.1 202 Accepted Location: http://reservations.airliner.com/agents/travelagents.com/res-0029/ -- step four -- When the airline receives the ticket order submitted by the agent, the requested seats will be checked and if available assigned to the corresponding participants. After that, the credit card will be charged, and the updated leg information is sent back to the agent as confirmation of the flights. -- step five -- After that, the airline sends the electronic tickets by e-mail to the traveler. Information about the recipient of the tickets has been specified by the traveler when instantiating the trip order process and this information is passed to the agent as well as to the airline. -- step six -- Then, the agent will wait for the confirmation of the flights, which especially includes the actual seats reserved for each of the participants. This information is completed into an itinerary, which is then sent to the traveler. == Acknowledge new reservation at airline === POST http://services.travelagents.com/trips/0173/airline/ack/ HTTP/1.1 Content-Type: text/xml Content-Model: ReservationConfirmation Authenticiation: Basic [airliner:password] <reservation> <leg> <flight>UA-1024</flight> <seat>33A</seat> <rate>$923.00</rate> </leg> <leg> <flight>NW-832</flight> <seat>22B</seat> <rate>$923.00</rate> </leg> </reservation> == Confirm receipt of reservation info == HTTP/1.1 200 OK --- scenario from IBM's WS Flow Language document --- "The overall flow of this example is as follows: A traveler will plan her trip by specifying the various stages of his overall journey and all of its participants. For each of the stages, the traveler specifies the location that she wants to visit as well as the date when she wants to begin and the date when she wants to end the particular stay. When the traveler is finished with this, she sends this information together with the list of all participants of the trip as well as the information about the credit card to be charged for the ordered tickets to the travel agent. The credit card information has been passed when the business process was instantiated. Next, the traveler will await the submission of the electronic tickets as well as the final itinerary for the trip. When the agent receives the traveler's trip order, he will determine the legs for each of the stages, which includes an initial seat reservation for each of the participants as well as the rate chosen. To actuall y make the corresponding ticket orders the agent submits these legs together with the information about the credit card to be charged to the airline company. Then, the agent will wait for the confirmation of the flights, which especially includes the actual seats reserved for each of the participants. This information is completed into an itinerary, which is then sent to the traveler. When the airline receives the ticket order submitted by the agent, the requested seats will be checked and if available assigned to the corresponding participants. After that, the credit card will be charged, and the updated leg information is sent back to the agent as confirmation of the flights. After that, the airline sends the electronic tickets by e-mail to the traveler. Information about the recipient of the tickets has been specified by the traveler when instantiating the trip order process and this information is passed to the agent as well as to the airline."
I've posted it to the Wiki as well: http://internet.conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui (say g'night gracie...) ----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com>; "Robert Leftwich" <robert@...> Sent: Saturday, June 01, 2002 12:45 AM Subject: Re: [rest-discuss] REST and travel agents revisited > > ----- Original Message ----- > From: "Robert Leftwich" <robert@...> > > > > Bob's adding of the travel agent scenario to the 'State machine as > hypertext' wiki page along with the comment 'No attempts to RESTify this > example have been reported' prompted me to try out my REST skills - be > warned, the training wheels are still on:-) > > > > The resources modelled are similar to those identified in the original > document: > > > > TripIdentifier > > Participants > > Participant1 > > Participant2 > > .... > > ParticipantN > > Journey > > Stage1 > > Stage2 > > .... > > StageN > > > If I'm reading this right, it sounds like you are making each item a full > resource. > To me, the data called out in the original document (appended at the end of > the message) don't necessarily need to be full URI resources. > I don't see the URIs, their structure or nesting as all that important. > In the nested text shown above, the Participant1 could be an independent > entity that is merely referenced by the trip, rather than being > 'subordinate' to the trip resource. > > Here's how I would do it: > The information types seem to be 'traveler', 'trip', 'stage', 'participant', > etc. > I'd start with a coarse-grained resource like 'trip' and expand out into > 'traveler' or 'participant' if necessary. > Within, I'd have an XML blob with details and any useful links. > > The resources I generated in walking through this are: > -- submit a new trip -- > http://services.travelagents.com/trips/ > -- new trip that was created -- > http://services.travelagents.com/trips/0173/ > -- callbacks for airline to confirm reservations -- > http://services.travelagents.com/trips/0173/airline/ack/ > http://services.travelagents.com/trips/0173/airline/status/ > -- submit new reservations -- > http://services.airliner.com/reservations/ > -- new reservation that was created -- > http://reservations.airliner.com/agents/travelagents.com/res-0029/ > > Note - the URIs do /not/ have to be related textually - the URI of the new > reservation at the airline is even on a different host for example. The > connection between all these is through HTTP headers, or they could also be > done via href's inside some XML. > > > -- step one -- > The overall flow of this example is as follows: A traveler will plan her > trip > by specifying the various stages of his overall journey and all of its > participants. For each of the stages, the traveler specifies the location > that > she wants to visit as well as the date when she wants to begin and the date > when she wants to end the particular stay. When the traveler is finished > with > this, she sends this information together with the list of all participants > of > the trip as well as the information about the credit card to be charged for > the > ordered tickets to the travel agent. > > == Create a new trip === > POST http://services.travelagents.com/trips/ HTTP/1.1 > Content-Type: text/xml > Content-Model: TripSpecification > > <trip> > <stage> > <location>maui</location> > <start>immediately</start> > <finish>never</finish> > </stage> > <participant> > <name>Mike</name> > </participant> > <payment>VISA</payment> > <recipient>mdierken@...</recipient> > </trip> > > == Acknowledgement of submission (with location of trip) == > HTTP/1.1 202 Accepted > Location: http://services.travelagents.com/trips/0173/ > > > -- step two -- > The credit card information has been passed when the business process was > instantiated. > Next, the traveler will await the submission of the electronic tickets as > well as the final itinerary > for the trip. > > -- step three -- > When the agent receives the traveler's trip order, he will > determine the legs for each of the stages, which includes an initial seat > reservation for each of the participants as well as the rate chosen. > To actually make the corresponding ticket orders the agent submits these > legs together with the information about the credit card to be charged to > the > airline company. > > == Create new reservations at airline === > POST http://services.airliner.com/reservations/ HTTP/1.1 > Reply-To: http://services.travelagents.com/trips/0173/airline/ack/ > Status-To: http://services.travelagents.com/trips/0173/airline/status/ > Content-Type: text/xml > Content-Model: ReservationRequest > Authenticiation: Basic [travelagents:password] > > <reservation> > <!-- URI of secure payment verification callback - the airlines have to > auth to get in --> > > <payment>http://services.travelagents.com/payment/verification/xyz/</payment > > > <recipient>mdierken@...</recipient> > <leg> > <flight>UA-1024</flight> > <seat>33A</seat> > <rate>$12.00</rate> > </leg> > <leg> > <flight>NW-832</flight> > <seat>22B</seat> > <rate>$12.00</rate> > </leg> > </reservation> > > == Acknowledgement of submission (with location of reservation) == > HTTP/1.1 202 Accepted > Location: http://reservations.airliner.com/agents/travelagents.com/res-0029/ > > -- step four -- > When the airline receives the ticket order submitted by the agent, the > requested seats will be checked and if available assigned to the > corresponding > participants. After that, the credit card will be charged, and the updated > leg > information is sent back to the agent as confirmation of the flights. > > -- step five -- > After that, the airline sends the electronic tickets by e-mail to the > traveler. > Information about the recipient of the tickets has been specified by the > traveler when instantiating the trip order process and this information is > passed to the agent as well as to the airline. > > -- step six -- > Then, the agent will wait for the confirmation of the flights, which > especially includes the actual seats reserved for each of the participants. > This information is completed into an itinerary, which is then sent to the > traveler. > > == Acknowledge new reservation at airline === > POST http://services.travelagents.com/trips/0173/airline/ack/ HTTP/1.1 > Content-Type: text/xml > Content-Model: ReservationConfirmation > Authenticiation: Basic [airliner:password] > > <reservation> > <leg> > <flight>UA-1024</flight> > <seat>33A</seat> > <rate>$923.00</rate> > </leg> > <leg> > <flight>NW-832</flight> > <seat>22B</seat> > <rate>$923.00</rate> > </leg> > </reservation> > > == Confirm receipt of reservation info == > HTTP/1.1 200 OK > > > --- scenario from IBM's WS Flow Language document --- > "The overall flow of this example is as follows: A traveler will plan her > trip > by specifying the various stages of his overall journey and all of its > participants. For each of the stages, the traveler specifies the location > that > she wants to visit as well as the date when she wants to begin and the date > when she wants to end the particular stay. When the traveler is finished > with > this, she sends this information together with the list of all participants > of > the trip as well as the information about the credit card to be charged for > the > ordered tickets to the travel agent. The credit card information has been > passed when the business process was instantiated. Next, the traveler will > await the submission of the electronic tickets as well as the final > itinerary > for the trip. When the agent receives the traveler's trip order, he will > determine the legs for each of the stages, which includes an initial seat > reservation for each of the participants as well as the rate chosen. To > actuall > y make the corresponding ticket orders the agent submits these legs together > with the information about the credit card to be charged to the airline > company. Then, the agent will wait for the confirmation of the flights, > which > especially includes the actual seats reserved for each of the participants. > This information is completed into an itinerary, which is then sent to the > traveler. > > When the airline receives the ticket order submitted by the agent, the > requested seats will be checked and if available assigned to the > corresponding > participants. After that, the credit card will be charged, and the updated > leg > information is sent back to the agent as confirmation of the flights. After > that, the airline sends the electronic tickets by e-mail to the traveler. > Information about the recipient of the tickets has been specified by the > traveler when instantiating the trip order process and this information is > passed to the agent as well as to the airline." > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
I'm gonna watch Mike Dierken and you roll with the RESTification and just respond to one issue here. Nice title, Mike! Robert Leftwich wrote: > Can you give an example of state being represented by hyperlinks? Here's two: * A leg of the trip is ticketed. The "ticketed" state is signified by a hyperlink to a Ticket resource on the airline site. (I'm not necessarily suggesting this as a REST model for your scenario, just as an example for discussion.) * A business entity type (e.g. a Trip type or Order type) has a public state machine published by a company or standards org. Each state in the state machine is a resource. Every entity that is an instance of that type hyperlinks to its current State resource, which gives rules, transitions to possible next states, etc. For the state-alignment transaction model (which I think will work in REST, contrary to some recent statements on the ws-arch list), participants do need to agree on states. One way to do that would be to publish the state-transition model for an entity type as hypertext, and have each resource that wants to be an instance of the type link to the same set of states. There are other ways to do it, but that's one way.
Robert, Mike, anybody, Do you know if this is a realistic travel-agent scenario? For example, I would have thought that the agent would put a temporary hold on the seats and ask the traveler to approve the itinerary before booking the tickets. Not trying to complicate things, but I've seen a lot of these business processes for different orchestration "languages" that are not the way anybody would actually do business, but instead are designed to match the features of the "language" well.
Mike wrote: [snip] > == Acknowledgement of submission (with location of trip) == > HTTP/1.1 202 Accepted > Location: http://services.travelagents.com/trips/0173/ [snip] Quick HTTP question: is it standard to include a Location header field with 202 responses? After looking at RFC 2616 (sect 14.30), it mentions using Location with 201 and 3xx responses and an absolute URI to specify the location of the resource. I'm developing a REST toolkit and I want to make sure my HTTP client and server code implements this right. Thanks, Philip Eskelin
HTTP allows persistent connections. That is, the client initiates a request and the connection stays open until the client closes it. While it is open the client can issue multiple requests. During this open connection a request can depend on prior requests. Right? Isn't this violating the REST principle that all requests be stateless, i.e., to promote scalability the server is not expected to maintain information about prior requests? /Roger
I think that I understand the REST abstraction of an HTTP GET: A resource is an abstraction of a concept. How the resource is implemented is encapsulated. When a client issues an HTTP GET the client receives a representation of the resource. Correct? I am not clear on what the REST abstraction is of an HTTP POST, PUT or DELETE. Is this the intended abstraction for an HTTP POST: the client sends to the resource a partial representation of the resource, which it expects the resource to incorporate into itself. Is that the REST abstraction for an HTTP POST? And what is the abstraction with an HTTP PUT? Is it that the client sends to the resource a new, complete representation of the resource which it expects the resource to replace itself with? Is the abstraction for an HTTP DELETE that the resource should completely delete itself? In the three cases (POST, PUT, DELETE) it seems like the client is asking the resource to commit partial or complete suicide for the sake of the client's new representation. That doesn't seem to be a very reasonable thing to ask of a resource. /Roger
My take on this from an HTTP spec perspective (see http://internet.conveyor.com/RESTwiki/moin.cgi/HttpMethods - an extract from the HTTP specs) is as follows: At 07:14 AM 3/06/2002, Roger L. Costello wrote: >I think that I understand the REST abstraction of an HTTP GET: A >resource is an abstraction of a concept. How the resource is >implemented is encapsulated. When a client issues an HTTP GET the >client receives a representation of the resource. Correct? Yes, but interestingly HTTP allows a partial retrieval by the use of the Range header field, which would be useful if the resource was a collection of some sort. >Is this the intended abstraction for an HTTP POST: the client >sends to the resource a partial representation of the resource, which it >expects the resource to incorporate into itself. Is that the REST >abstraction for an HTTP POST? POST adds additional sub-resources to an existing resource, e.g. annotations, chat-style messages, database appends. "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. " >And what is the abstraction with an HTTP PUT? Is it that the client >sends to the resource a new, complete representation of the resource >which it expects the resource to replace itself with? Interestingly (again), "the PUT method SHOULD be considered as a modified version of the one residing on the origin server", but it does not have to be. PUT can also result in the creation of a new resource "If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent" "The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. " >Is the abstraction for an HTTP DELETE that the resource should >completely delete itself? "The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully." >In the three cases (POST, PUT, DELETE) it seems like the client is >asking the resource to commit partial or complete suicide for the sake >of the client's new representation. Not true for POST, possibly true for PUT and DELETE. >That doesn't seem to be a very >reasonable thing to ask of a resource. Doesn't it depend on what the resource is and what the servers 'actual' interpretation of the method is? Robert
Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the rest-discuss group. File : / Looking for fast Internet service? Uploaded by : davenorjsak <davenorjsak@...> Description : Click above to learn what DIRECTV has to offer. You can access this file at the URL http://groups.yahoo.com/group/rest-discuss/files/%20Looking%20for%20fast%20Internet%20service%3F To learn more about file sharing for your group, please visit http://help.yahoo.com/help/us/groups/files Regards, davenorjsak <davenorjsak@...>
At 05:45 PM 1/06/2002, S. Mike Dierken wrote: >----- Original Message ----- >From: "Robert Leftwich" <robert@...> >> The resources modelled are similar to those identified in the original >document: >> >> TripIdentifier >> Participants >> Participant1 >> Participant2 >> .... >> ParticipantN >> Journey >> Stage1 >> Stage2 >> .... >> StageN >> >If I'm reading this right, it sounds like you are making each item a full >resource. That was to allow access to the sub-resources directly, allowing changes to participants, stages, etc The usefulness of this probably varies depending on the system, but in my case, it is most definitely useful (it's somewhat confusing, in that I am using the travel agent example as a proxy for the real thing). The other area I was attempting to explore was that of a state machine as hypertext, which this design does not address. >To me, the data called out in the original document (appended at the end of >the message) don't necessarily need to be full URI resources. Agreed >I don't see the URIs, their structure or nesting as all that important. That's an interesting comment in the light of the whole 'resource modeling' side to REST. >In the nested text shown above, the Participant1 could be an independent >entity that is merely referenced by the trip, rather than being >'subordinate' to the trip resource. True. I was going to say 'but the nesting above doesn't necessitate a dependant entity' but in the light of the HTTP spec a sub-resource should be owned by its parent (in the sense a directory owns a file in it). I suppose the sub-resource could be a proxy for the real thing. >-- step one -- >The overall flow of this example is as follows: A traveler will plan her >trip >by specifying the various stages of his overall journey and all of its >participants. For each of the stages, the traveler specifies the location >that >she wants to visit as well as the date when she wants to begin and the date >when she wants to end the particular stay. When the traveler is finished >with >this, she sends this information together with the list of all participants >of >the trip as well as the information about the credit card to be charged for >the >ordered tickets to the travel agent. > >== Create a new trip === >POST http://services.travelagents.com/trips/ HTTP/1.1 >Content-Type: text/xml >Content-Model: TripSpecification > ><trip> ><stage> > <location>maui</location> > <start>immediately</start> > <finish>never</finish> ></stage> ><participant> > <name>Mike</name> ></participant> ><payment>VISA</payment> ><recipient>mdierken@...</recipient> ></trip> > >== Acknowledgement of submission (with location of trip) == >HTTP/1.1 202 Accepted >Location: http://services.travelagents.com/trips/0173/ What is Content-Model? Is it a standard HTTP header or an app-specific one? If it is the former, I cannot find mention of it in RFC 2616 (or anywhere else for that matter). Of course this use case is somewhat simplistic as it does not mention problems such as changing participants or stages after submission, problems in seat allocation, flight cancellation, etc but it should serve well enough as a discussion focus. Robert
On Sun, Jun 02, 2002 at 04:05:42PM -0400, Roger L. Costello wrote: > HTTP allows persistent connections. That is, the client initiates a > request and the connection stays open until the client closes it. While > it is open the client can issue multiple requests. During this open > connection a request can depend on prior requests. Right? Isn't this > violating the REST principle that all requests be stateless, i.e., to > promote scalability the server is not expected to maintain information > about prior requests? /Roger "Stateless" just means that all the information that's needed to interpret the meaning of the message, is available in the message itself. The type of connection used doesn't impact this at all, so it's fine. It's funny you mentioned this, as a related bug has apparently just been discovered in IIS; http://lists.w3.org/Archives/Public/www-talk/2002MayJun/0056 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
POST doesn't have to create new resources, it can just be a logical "add" where what is "added" can be consumed as soon as it's processed and not provided its own identity. I like thinking about it as an "add operation, because the notion of containment is very much key to how I model. But it's more abstract an operation than you appear to suggest. FWIW, I've written a couple of things that talk about this; http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model http://www.markbaker.ca/2002/03/RestRDF/ MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tue, May 28, 2002 at 01:39:59AM -0700, Joe Hsy wrote: > Historically, one of the biggest issues of distributed programming is that > it is difficult to pass by reference. Thus, you have to pass the entire > data from one addressing space to another (thus RPCs). If we think of the > URI naming system as an universal addressing space - we are in essence > creating the ability to pass by reference - isn't that what a link is, after > all? Pass by reference is a problem in distributed systems, but it seems to be solved in CORBA, and I believe in DCOM as well. The problem I usually think of is *garbage collection*. The SOAP RFC quotes garbage collection as a reason for not providing for object references. I'm still settling on this whole REST thing, but as I understand it, the idea in REST is to avoid transient references as much as possible. Instead, store whatever information is needed to rebuild the object in the URI. jlp
----- Original Message ----- From: "Philip Eskelin" <philip@...> > Mike wrote: > [snip] > > == Acknowledgement of submission (with location of trip) == > > HTTP/1.1 202 Accepted > > Location: http://services.travelagents.com/trips/0173/ > [snip] > > Quick HTTP question: is it standard to include a Location header field with 202 > responses? After looking at RFC 2616 (sect 14.30), it mentions using Location > with 201 and 3xx responses and an absolute URI to specify the location of the > resource. I'm developing a REST toolkit and I want to make sure my HTTP client > and server code implements this right. Nope - that was my little addition. I haven't sent a mail to IETF asking about the appropriateness. Probably should do that...
----- Original Message ----- From: "Roger L. Costello" <costello@...> > HTTP allows persistent connections. That is, the client initiates a > request and the connection stays open until the client closes it. While > it is open the client can issue multiple requests. During this open > connection a request can depend on prior requests. Right? No - the requests are (should) be independent. They each must specify resource, method, auth, encoding, etc. As a side note, imagine what would happen if what was kept open was not the connection but the response... a never-ending view onto the (past and future) state of a resource. If you are into Fun Tricks with Sockets you can do neat stuff.
----- Original Message ----- From: "Robert Leftwich" <robert@...> > >If I'm reading this right, it sounds like you are making each item a full > >resource. > > That was to allow access to the sub-resources directly, allowing changes to participants, stages, etc If as a URI the participant would be "Trip1/participants/Participant1", then that person is not identifiable separate from a trip. I was thinking that the trip would point to participants independent of any particular trip. Just a different way of splitting it up. > > >I don't see the URIs, their structure or nesting as all that important. > > That's an interesting comment in the light of the whole 'resource modeling' side to REST. I meant the URI text format - whether you use '/' or '?' or ';' or whatever - is not meaningful to the client. Having one resource nested within another is not part of the coordination between client and server. The XML (or whatever) representation of a resource will explicitly point to whatever resource should be used (with absolute or relative URIs).
----- Original Message ----- From: "Robert Leftwich" <robert@...> > >== Create a new trip === > >POST http://services.travelagents.com/trips/ HTTP/1.1 > >Content-Type: text/xml > >Content-Model: TripSpecification > > What is Content-Model? Is it a standard HTTP header or an app-specific one? > If it is the former, I cannot find mention of it in RFC 2616 (or anywhere else for that matter). Another mike-ism. I think it is useful to identify the meaning the entity body separate from any particular encoding/syntax. Not actually standard HTTP. It cuts across debates on whether a DTD identifier, or Schema location or 'root' namespace URI or whatever is the ultimate semantically meaningful value.
----- Original Message ----- From: "Jason Petrone" <jpetrone@...> > I'm still settling on this whole REST thing, but as I understand it, the > idea in REST is to avoid transient references as much as possible. > Instead, store whatever information is needed to rebuild the object in > the URI. By 'rebuild' to you mean 're-acquire' or do you mean that the URI has the full state of the object?
On Mon, Jun 03, 2002 at 10:05:57AM -0700, S. Mike Dierken wrote: > From: "Jason Petrone" <jpetrone@...> > > I'm still settling on this whole REST thing, but as I understand it, the > > idea in REST is to avoid transient references as much as possible. > > Instead, store whatever information is needed to rebuild the object in > > the URI. > > By 'rebuild' to you mean 're-acquire' or do you mean that the URI has the > full state of the object? Correct me if I am wrong, but I meant that "the URI has the full state of the object." I suppose there will be some cases where encoding the full state in the URI is not possible, but I'm not confident enough to speak to that. jlp
----- Original Message ----- From: "Jason Petrone" <jpetrone@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, June 03, 2002 10:50 AM Subject: Re: [rest-discuss] REST-OO? (URIs as passing by reference) > On Mon, Jun 03, 2002 at 10:05:57AM -0700, S. Mike Dierken wrote: > > From: "Jason Petrone" <jpetrone@...> > > > I'm still settling on this whole REST thing, but as I understand it, the > > > idea in REST is to avoid transient references as much as possible. > > > Instead, store whatever information is needed to rebuild the object in > > > the URI. > > > > By 'rebuild' to you mean 're-acquire' or do you mean that the URI has the > > full state of the object? > > Correct me if I am wrong, but I meant that "the URI has the full state > of the object." > > I suppose there will be some cases where encoding the full state in the > URI is not possible, but I'm not confident enough to speak to that. > I don't think it is a primary goal of REST to avoid transient references, although it is a good design principle. Regardless, I'm pretty sure REST and pure-HTTP advocates are not suggesting that the URI stores the full state of the object. What is being recommended is that the URI - and the URI alone - /identifies/ the object. The state remains within the 'origin server' and clients can interact with the object only through sending and receiving representations of the object. Many discussions show fairly long URI with a lot of information in it, but that is not intended to be the /state/ of the object. Do you have any examples that made it look like the URI had the full state of the object?
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-11.txt HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet --- Abstract This document describes how to exchange structured business data securely using HTTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the HTTP POST requests. This document extends the procedures and payload packaging options of AS1 in the following ways: HTTPS may be used to obtain data, privacy both synchronous and asynchronous reply procedures are, described multipart/form-data packaging may be used, a generalized multipart/report format is added to the MDN format of AS1, replies may include a multipart/mixed payload that contains both the acknowledgement and an additional EDI payload.
Hi Folks, Below is an except from Fielding's REST dissertation, describing why cookies are not RESTful. Can someone explain what he is saying here? "Likewise, the use of cookies to identify a user-specific 'shopping basket' within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase." /Roger
On Tue, Jun 04, 2002 at 08:28:52AM -0400, Roger L. Costello wrote: > Hi Folks, > > Below is an except from Fielding's REST dissertation, describing why > cookies are not RESTful. Can someone explain what he is saying here? > > "Likewise, the use of cookies to identify a user-specific 'shopping > basket' within a server-side database could be more efficiently > implemented by defining the semantics of shopping items within the > hypermedia data formats, allowing the user agent to select and store > those items within their own client-side shopping basket, complete with > a URI to be used for check-out when the client is ready to purchase." You know that cookies are stateful, right? That is, they make it so that there isn't enough information in the HTTP message to understand what it does, because it depends on the information represented by the cookie which is invisible to everybody but the server. So if you wanted to do a shopping basket statelessly, it's up to the client to manage that the state of the basket, submitting a representation of the basket to the server when it wants to checkout. The local URI would be needed to identify which shopping basket, so that when you opted to put something in the basket, you would do a local POST of the representation of the item to your basket. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Basically he's saying that cookies are a quick hack that ignores REST. Rather than specifying session state in a message header, session state should be part of the server resource. So instead of: GET /someresource session-state-store-on-client: mynameis=slimshady use: GET /slimshady/someresource - Lucas
On Tuesday 2002-06-04 at 08:51:30(-0400) Mark Baker wrote: > On Tue, Jun 04, 2002 at 08:28:52AM -0400, Roger L. Costello wrote: > > Hi Folks, > > > > Below is an except from Fielding's REST dissertation, describing why > > cookies are not RESTful. Can someone explain what he is saying here? > > > > "Likewise, the use of cookies to identify a user-specific 'shopping > > basket' within a server-side database could be more efficiently > > implemented by defining the semantics of shopping items within the > > hypermedia data formats, allowing the user agent to select and store > > those items within their own client-side shopping basket, complete with > > a URI to be used for check-out when the client is ready to purchase." > > You know that cookies are stateful, right? That is, they make it so > that there isn't enough information in the HTTP message to understand > what it does, because it depends on the information represented by > the cookie which is invisible to everybody but the server. Just a nit. The second part of that sentence is true, but the first part is not the issue. Any individual HTTP message need not contain the state, let alone let you understand what it does. The state should be contained in representations that are accessible via GET (or maybe POST). Cookies are out of band as far as REST is concerned, and are downright anti-REST because you will probably never see the cookie contents but those contents are responsible for a ton of information transfer between client and server. If you moved the cookie info to a URI-accessible location, then it would be RESTful. A big issue with current practice (not with HTTP or REST) is that usually clients don't have HTTP servers running in them or on their behalf so the server can't get at client-side state with a simple GET. (c.f. the "client-side shopping basket" statement above). This asymmetry also impacts the ability to do decent asynchronous callbacks from the server to the client. > > So if you wanted to do a shopping basket statelessly, it's up to the > client to manage that the state of the basket, submitting a > representation of the basket to the server when it wants to checkout. > The local URI would be needed to identify which shopping basket, so that > when you opted to put something in the basket, you would do a local POST > of the representation of the item to your basket. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Allan Doyle http://www.intl-interfaces.com adoyle@...
Allan, On Tue, Jun 04, 2002 at 09:38:19AM -0400, Allan Doyle wrote: > > You know that cookies are stateful, right? That is, they make it so > > that there isn't enough information in the HTTP message to understand > > what it does, because it depends on the information represented by > > the cookie which is invisible to everybody but the server. > > Just a nit. The second part of that sentence is true, but the first > part is not the issue. Any individual HTTP message need not contain > the state, let alone let you understand what it does. The state > should be contained in representations that are accessible via GET (or > maybe POST). No, the first part is the issue (though I could have chosen a better word than "does"). You appear to be confusing "stateful interaction" with "stateful service". Just take a message, and ask yourself this question; "Will this message mean the same thing in 20 years?". If so, then that is stateless. If you use cookies with HTTP, then the answer is "no", because the cookie would have expired in that time, and that would change the meaning of the message. Note that the "meaning of the message" is not the same as "the result of the message being processed". Obviously a message sent now, versus the same one sent 20 years from now, will do something different. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tuesday 2002-06-04 at 10:11:38(-0400) Mark Baker wrote: > Allan, > > On Tue, Jun 04, 2002 at 09:38:19AM -0400, Allan Doyle wrote: > > > You know that cookies are stateful, right? That is, they make it so > > > that there isn't enough information in the HTTP message to understand > > > what it does, because it depends on the information represented by > > > the cookie which is invisible to everybody but the server. > > > > Just a nit. The second part of that sentence is true, but the first > > part is not the issue. Any individual HTTP message need not contain > > the state, let alone let you understand what it does. The state > > should be contained in representations that are accessible via GET (or > > maybe POST). > > No, the first part is the issue (though I could have chosen a better > word than "does"). You appear to be confusing "stateful interaction" > with "stateful service". I read it differently because the subject was cookies. Cookies are for session state, i.e. stateful service. > > Just take a message, and ask yourself this question; "Will this message > mean the same thing in 20 years?". If so, then that is stateless. If > you use cookies with HTTP, then the answer is "no", because the cookie > would have expired in that time, and that would change the meaning of > the message. Yes, I agree fully with this. > > Note that the "meaning of the message" is not the same as "the result > of the message being processed". Obviously a message sent now, versus > the same one sent 20 years from now, will do something different. and this... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Allan Doyle http://www.intl-interfaces.com adoyle@...
Mark Baker wrote: > So if you wanted to do a shopping basket statelessly, it's up to the > client to manage that the state of the basket, submitting a > representation of the basket to the server when it wants to checkout. Why couldn't the shopping basket be kept on the server, with a customer-specific URI? Why is it any different than an uncommitted order? The order gets a URI on the server. I'm not saying you would always want to do it that way - given the percentage of abandoned shopping baskets - but wouldn't be a RESTful alternative? -Bob Haugen
State-Alignment Transaction Model AKA RosettaNet/ebXML/UNCEFACT Business Transactions This transaction model was first published for RosettaNet (as far as I know). But I understand that it came from telecom practices. I think it is also very similar to some previous work on consensus. But I am not an expert in transaction or consensus theory. I just know that this transaction model has been used fairly widely in real electronic commerce by real companies (e.g. Intel and Siemens). It is also the simplest Web transaction model I have seen, and seems to me to be RESTifiable. First I'll describe the model in its native form, and then consider RESTificiation. RosettaNet transactions use something like EDI-mailbox-style SOAP. It's a peer-to-peer interaction between two business activities, hidden behind business services (service access points) with dispatchers directing messages to the business activities. It's not actually SOAP, but ebXML adopted the same transaction model and does use SOAP. It's not REST because the business entities (whose states are to be aligned) are hidden behind the service access point and dispatcher. But I think that the EDI-mailbox-style is a RosettaNet+ebXML implementation detail. UN/CEFACT has a metamodel for this transaction model that claims to be technology-neutral. So if the transaction model is not RESTifiable, UN/CEFACT might be concerned. The basics of the transaction model: It's a two-party request-response interaction, with receipt acknowledgements for both request and response. The interactions are between a requesting business activity and a responding business activity. UN/CEFACT describes five different patterns for different kinds of business interactions. I will consider only one pattern here which is most applicable to Offer-Acceptance, the business protocol for contract formation and order placement. In an Offer-Acceptance state-alignment transaction consists of these steps: 1. The requesting activity sends an Offer document to the responding activity via the responding business service. 2. The responding business service sends back a receipt acknowledgment for the Offer document, or an error message. If an error message, the transaction fails with a Control Failure. In some cases, there can be two acknowledgments or possible points of error: the first for schema validation, the second for business rules. UN/CEFACT, ebXML and RosettaNet V1.0 require both; RosettaNet V2.0 only requires one. 3. The responding business activity does whatever it needs to do to decide whether it can fill the order or not. It then sends back a Response document that says it either Accepts or Rejects (declines) the offer. If Rejection, the transaction fails with a Contract Failure. 4. The requesting business service sends back a receipt acknowledgment for the Response document, or an error message. If an error message, the transaction fails with a Control Failure. If the Response document says "Accept" and there were no error messages, the transaction succeeds. There are time constraints on each step. If any timeout occurs, the transaction fails with a Control Failure. In cases where the Response document says "Accept" but has an error, and the error message from the requesting business service cannot be delivered, the transaction model specifies a separate Notification of Failure to be sent from the requesting business service via another channel. Otherwise the responding activity may think incorrectly that the transaction succeeded. State Alignment: There are two levels of state alignment in this transaction model: 1. The state of the transaction, aligned between the requesting and responding business activities, where the events that trigger state transitions are the requesting and responding documents, receipt acknowledgments and/or error messages. 2. The state of the business entity being offered, for example an Order. Example states might include Offered, Accepted and Rejected The event that triggers a state transition in the Order is the end of the transaction. If the transaction succeeds, the Order transitions to the Accepted state. If the transaction fails with a Contract Failure. the Order transitions to the Rejected state. If the transaction fails with a Control Failure, the Order stays in the Offered state. Restification: I'll stick with a peer-to-peer configuration because it is most like the source. But I think the same underlying principles apply to a client-service configuration, although only the Web resource for the business entity will exist only on the server side. Replace the business service access points with resources representing the business entity being offered, for example the Order. (Alternatively, each transaction might become a sub-resource under the Order.) RosettaNet and ebXML assume that a business service access point will handle many transactions for many business activities, so each message contains tags for dispatching to the business collaboration (long conversation about the Order), business transaction, and business activity. If the resource is the Order, then only the business transaction and business activity tags are required. If the resource is the Transaction, then the business activity can be assumed. In either case, I think the REST style is functionally equivalent to the EDI-mailbox style, but has at least two advantages: 1. the business entities and transaction results are Web resources, and 2. the "service access point" is finer-grained. I assume the members of this list understand some of the advantages of #1. If not, and there's interest, I could expand and of course help is always appreciated. There is a lot more to the transaction model mostly about security issues. But I think those are also functionally equivalent between a REST and EDI-mailbox style. So what do you all think? Does this have promise for fulfilling the business transaction requirement for REST? Should I post it on the rest-wiki? What else is required or would be nice to add? -Bob Haugen
On Tue, Jun 04, 2002 at 10:39:30AM -0400, bhaugen32 wrote: > Mark Baker wrote: > > So if you wanted to do a shopping basket statelessly, it's up to the > > client to manage that the state of the basket, submitting a > > representation of the basket to the server when it wants to > checkout. > > Why couldn't the shopping basket be kept on the server, with a > customer-specific URI? Why is it any different than an uncommitted > order? The order gets a URI on the server. > > I'm not saying you would always want to do it that way - given the > percentage of abandoned shopping baskets - but wouldn't be a RESTful > alternative? There are cases when you'd want this, for example when the shopping basket did things very specific to the app. But generally, I don't think that shopping baskets do very much at all, and could be generalized to some dumb client-side container in which the representations of the things you want are placed. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Allan Doyle wrote: > > Cookies are out of band as far as REST is concerned, and are > downright anti-REST because you will probably never see the cookie > contents but those contents are responsible for a ton of information > transfer between client and server. If you moved the cookie info to a > URI-accessible location, then it would be RESTful. A big issue with > current practice (not with HTTP or REST) is that usually clients don't > have HTTP servers running in them or on their behalf so the server > can't get at client-side state with a simple GET. (c.f. the > "client-side shopping basket" statement above). This asymmetry also > impacts the ability to do decent asynchronous callbacks from the > server to the client. > I've been struggling with authentication/authorization and how to fit it into the REST model... I'm probably confusing several issues (and I'm probably unaware of others), but it seems very difficult to provide authentication and authorization without cookies or some similar mechanism - and I'm not sure I see a solution that doesn't just shift the problem (state-hiding) somewhere else. In all the examples I've seen, the resources are assumed to be publicly accessible. In the example above, the suggestion is to move the hidden state stored in a cookie to a URI-accessible location. However, once I've done that, I would think that I am then obliged to ensure that only the user who owns that information is able to retrieve it. How do I do that if I cant also issue the user a token (cookie) that they can then use as proof of identity? My first thoughts were that you could use HTTPS with client certs to provide identity, but it seems that you've only shifted the problem around. Instead of providing proof of identity with a cookie, your providing it with a certificate. Or maybe using a cookie for authentication doesnt violate the no-hidden-state rule. --Chuck
On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote: > I've been struggling with authentication/authorization and how to fit it > into the REST model... It's already there, with HTTP authentication. A 401 response to a HTTP request tells the client to provide a header with the authentication info, next time it does that request. On subsequent requests, that header is always included, making the interaction stateless. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Roger L. Costello [mailto:costello@...] > Sent: 04 June 2002 13:29 > To: rest-discuss@yahoogroups.com; costello@... > Subject: [rest-discuss] Cookies not RESTful - need explaination > > > Hi Folks, > > Below is an except from Fielding's REST dissertation, > describing why cookies are not RESTful. Can someone explain > what he is saying here? > > "Likewise, the use of cookies to identify a user-specific > 'shopping basket' within a server-side database could be more > efficiently implemented by defining the semantics of shopping > items within the hypermedia data formats, allowing the user > agent to select and store those items within their own > client-side shopping basket, complete with a URI to be used > for check-out when the client is ready to purchase." He wants you to store the basket details on the client using URIs to manage the representations. The cost is coordinating client and server software. I imagine that cost would less if the client could also act as a server, i.e. you could get at the basket using HTTP methods. It would be efficient insofar as you'd stop routing around your local CPU to do processing on the server's. Cookies may not be restful, but the more appealing argument to some might be that they could throw away their enterprise class web server infrastructure, load balancers et al and apportion some of the costs to the client. I haven't heard an argument for rest based on reducing server side costs, it would be an interesting one. Bill -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPPzvUuaWiFwg2CH4EQLwzwCgiY4ZxB7zVXpORPRBiKWcumiFUd4AoJl4 7IZp/H7jS9Ne4clLuCChzSB8 =C8E3 -----END PGP SIGNATURE-----
If a client makes a request of a server which has information from a prior request (e.g., session ID) is that request stateful or stateless? Aren't HTTP requests by definition "stateless", and it is the server-side application which maintains state information (e.g,, session ID) to simulate a (stateful) connection. I guess that I need a real concrete definition of what stateless means. Lucas Gonze wrote: > So instead of: > GET /someresource > session-state-store-on-client: mynameis=slimshady > > use: > GET /slimshady/someresource Why is it that putting information in the HTTP header is not RESTful, whereas putting information in a URL is RESTful? /Roger
----- Original Message ----- From: "Mark Baker" <distobj@...> > > You know that cookies are stateful, right? That is, they make it so > that there isn't enough information in the HTTP message to understand > what it does, because it depends on the information represented by > the cookie which is invisible to everybody but the server. I'm confused - a cookie is part of the HTTP message, both request and response. The client can read and write them and so can the server. And anyway, combining information from the request and server-only state isn't a bad thing - security permissions, etc. do this all the time. The problem I have is that they are often used to qualify the URI - for example http://my.example.org/startpage.asp is the same URI for everyone, but the page - the 'actual' resource - is different based on the value of the cookie. This makes the sample URI unsharable, uncacheable, etc. - which is good or bad depending on what you are trying to do. They are also often used to identify the user, or at least a user's server-side session.
----- Original Message ----- From: "Chuck Hinson" <hinson@...> > > In all the examples I've seen, the resources are assumed to be publicly > accessible. The examples I write have the assumption that permissions exist on the server for the resources. Any message that has a cookie in it can be captured and re-played with the cookie intact, so the message itself is just as 'public' as the URI only. > In the example above, the suggestion is to move the hidden > state stored in a cookie to a URI-accessible location. I wouldn't call it 'state' that is in the cookie, the data usually is used as values for lookup on the server side. > However, once I've > done that, I would think that I am then obliged to ensure that only the user > who owns that information is able to retrieve it. Yes, that would be a good thing. > How do I do that if I cant also issue the user a token (cookie) > that they can then use as proof of identity? This token isn't proof of identity. It can be captured, copied, and replayed elsewhere. Cookie based approaches are just breaking the URI into two pieces and hoping that the Bad Guys don't capture both pieces. Since that is not doable, people make one piece very transient, which only reduces the window of opportunity. Now that I think about it, using HTTPS would minimize the chance that other people will find the cookie. > > My first thoughts were that you could use HTTPS with client certs to provide > identity, but it seems that you've only shifted the problem around. Instead > of providing proof of identity with a cookie, your providing it with a > certificate. Or maybe using a cookie for authentication doesnt violate the > no-hidden-state rule. > I think there is an interesting design question here regarding coordination costs of establishing trust: - server provides tokens for identity - client provides tokens for identity I'll have to think about this for a while.
Mark Baker wrote: > On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote: > >>I've been struggling with authentication/authorization and how to fit it >>into the REST model... > > > It's already there, with HTTP authentication. > > A 401 response to a HTTP request tells the client to provide a header > with the authentication info, next time it does that request. On > subsequent requests, that header is always included, making the > interaction stateless. > Hmm. I guess I already knew that. However, the lack of support by browsers for anything other than Basic Auth pretty much eliminates the Authorization header as a solution today. (Once again, reality interferes...) Given that, it would seem that using a cookie for authentication is a reasonable alternative -- the spec say use the Authorization header; browsers and servers dont support that very well, so I'll use a header that they do support and that happens to be a cookie. --Chuck > MB
On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote: > I'm confused - a cookie is part of the HTTP message, both request and > response. Yes, but the information necessary to understand what a message with a cookie means, is not part of the message. GET /foo HTTP/1.1 has one meaning for all time, which you can lookup in RFC 2616. GET /foo HTTP/1.1 Cookie: bar=goo can have many meanings depending upon what magic that cookie induces in the behaviour of the server. You can't look up what it means anywhere. > The problem I have is that they are often used to qualify the URI - for > example > http://my.example.org/startpage.asp is the same URI for everyone, but > the > page - the 'actual' resource - is different based on the value of the > cookie. This makes the sample URI unsharable, uncacheable, etc. - which > is > good or bad depending on what you are trying to do. > They are also often used to identify the user, or at least a user's > server-side session. Right, that's a special case of the problem I described above; if you allow a message's meaning to change (be it the identified-resource, the authorization info, etc..) depending upon information not in the message itself, then you can very easily do the Wrong Thing. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > >... > > Right, that's a special case of the problem I described above; if you > allow a message's meaning to change (be it the identified-resource, the > authorization info, etc..) depending upon information not in the message > itself, then you can very easily do the Wrong Thing. I think you mean "information in the message or *REFERENCED* by the message through a derferencerable URI." Am I right? For instance it is not wrong for a "purchase now" message to point to a shopping cart URI. As long as the two do not change you could understand that message a hundred years from now on a totally different device. Paul Prescod
Mark Baker wrote: > > On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote: > > I'm confused - a cookie is part of the HTTP message, both request and > > response. > > Yes, but the information necessary to understand what a message with > a cookie means, is not part of the message. > > GET /foo HTTP/1.1 > > has one meaning for all time, which you can lookup in RFC 2616. > > GET /foo HTTP/1.1 > Cookie: bar=goo > > can have many meanings depending upon what magic that cookie induces > in the behaviour of the server. You can't look up what it means > anywhere. Let me see if I understand what you are saying Mark: if the HTTP header contains information (e.g., cookie information) that is used by the server application then that is not RESTful. However, if we were to move the (e.g., cookie) information into the HTTP message body, then it would be RESTful. Is that it? That doesn't seem reasonable since the HTTP header contains a lot of information that a server application will typically use, such as the content type that the client will accept (e.g., text/html), and many other things. These HTTP headers induces behaviour in the server application. Taking this argument to its logical conclusion, then I conclude that no HTTP message can ever be RESTful, unless it has no HTTP headers, since HTTP headers by their very nature induces behaviour in the server application. Yes? To restate my earlier question: what exactly does it mean to be stateless? In light of the above, does it mean that all information is carried in the HTTP message body? That is, the server application's behaviour is not influenced by anything in the HTTP header? Sorry to be so dense on this. However, I feel that it is a critical issue that I want to make certain I fully understand as I go out into the world to preach the merits of REST. /Roger
On Tue, Jun 04, 2002 at 02:47:41PM -0700, Paul Prescod wrote: > > Right, that's a special case of the problem I described above; if you > > allow a message's meaning to change (be it the identified-resource, the > > authorization info, etc..) depending upon information not in the message > > itself, then you can very easily do the Wrong Thing. > > I think you mean "information in the message or *REFERENCED* by the > message through a derferencerable URI." Am I right? No, in the message itself. If the meaning of the message depends on information you get from dereferencing a URI (or anything else outside the message), then it is stateful. > For instance it is > not wrong for a "purchase now" message to point to a shopping cart URI. > As long as the two do not change you could understand that message a > hundred years from now on a totally different device. Right, because the meaning of "purchase this shopping cart now" doesn't depend on what you get by dereferencing the shopping cart URI. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "Chuck Hinson" <hinson@...> > > Hmm. I guess I already knew that. However, the lack of support by browsers > for anything other than Basic Auth pretty much eliminates the Authorization > header as a solution today. (Once again, reality interferes...) The systems I'm envisioning go way beyond the browser - and then the full potential of HTTP is available. Build a different user agent, or if you really must, use components that do provide full HTTP access (IXMLHTTPRequest in IE and others). > > Given that, it would seem that using a cookie for authentication is a > reasonable alternative -- the spec say use the Authorization header; > browsers and servers dont support that very well, so I'll use a header that > they do support and that happens to be a cookie. It isn't reasonable, but there is little alternative. I'm amazed the browser world has gone this long without extending FORM to support users entering credentials. A big reason sites use FORMs is to control the UI. It shouldn't be a big deal to for FORM to specify that it is user input for credentials at the specified URI.
On Tue, Jun 04, 2002 at 07:16:47PM -0400, Roger L. Costello wrote: > Let me see if I understand what you are saying Mark: if the HTTP header > contains information (e.g., cookie information) that is used by the > server application then that is not RESTful. No ... > However, if we were to > move the (e.g., cookie) information into the HTTP message body, then it > would be RESTful. Is that it? Hmm, no. By "message", I mean the entire HTTP message; request line, headers, and body. Think about taking an HTTP message, and storing it to disk for 20 years. When you "reconstitute" it at that time, will people still know what it means? If it used cookies, they won't, because some information necessary to understanding it was on the server, and it expired years ago. Compare it to FTP, if that helps. If I pickle the (logical) command "RETR foo.zip" to disk, and reconstitute it 10 minutes later, nobody will know what it means because they don't know what the current directory is, and hence which foo.zip to retrieve. FTP is a stateful protocol. > Sorry to be so dense on this. However, I feel that it is a critical > issue that I want to make certain I fully understand as I go out into > the world to preach the merits of REST. /Roger It's definitely a critical issue, as statelessness is so key to visibility and reliability. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Some thoughts... > behaviour in the server application. Taking this argument to its > logical conclusion, then I conclude that no HTTP message can ever be > RESTful, unless it has no HTTP headers, since HTTP headers by their very > nature induces behaviour in the server application. Yes? An HTTP message can certainly be RESTful. You can accomplish this by correctly using a URI to reference a real, true object. The headers can still be there, and are very helpful as metadata and instructions on how to handle the message itself. For instance, REST likes to transfer state of objects. But, some objects can be represented many different ways. For example, a daily report can be represented as a PDF, HTML, XML, etc. That's just the physical form. The logical object itself is the same. Now, this object might have a URI of http://example.org/finance/report/2002/06/05. Using that URI, I can GET and SET that report throughout time and space. But how do I know what I'm getting? HTTP is the protocol we're using, so HTTP headers are introduced. Think of the headers like the envolope. They tell us more info about the resource. That info isn't needed to identify the object (that's done with the URI). So the HTTP header will say "Content-type: application/pdf" to indicate what bytes are being sent. This doesn't violate REST (IMO) since we haven't obfuscated the object identifier. > To restate my earlier question: what exactly does it mean to be > stateless? In light of the above, does it mean that all information is > carried in the HTTP message body? That is, the server application's > behaviour is not influenced by anything in the HTTP header? It might help for your understanding of REST to divorce yourself from HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used for an implementation of REST, but isn't the perfect embodiment of REST. To be stateless means to carry all information needed for the request along with the request. That request must be able to stand alone. If the process requires three messages in a certain order, each depending on the first one, that is not stateless. Hope I didn't confuse things more. :) Seth
[snip] Seth wrote: > HTTP headers are introduced. Think of the headers like the envolope. For obvious reasons, any mention of the word "envelope" in RESTful discussions makes me shudder....gives me nightmares where employees from Microsoft and IBM force-feed me bars of soap until I wake up in a cold sweat ;-) -Philip
Philip Eskelin wrote: > [snip] > Seth wrote: > >>HTTP headers are introduced. Think of the headers like the envolope. > > > For obvious reasons, any mention of the word "envelope" in RESTful discussions > makes me shudder....gives me nightmares where employees from Microsoft and IBM > force-feed me bars of soap until I wake up in a cold sweat ;-) Yeah, except SOAP can be used to communicate a RESTful protocol. It's all about how you use the transport mechanism. Seth
Seth wrote: > Philip Eskelin wrote: > > [snip] > > Seth wrote: > > > > >HTTP headers are introduced. Think of the headers like the envolope. > > > > > > For obvious reasons, any mention of the word "envelope" in RESTful discussions > > makes me shudder....gives me nightmares where employees from Microsoft and IBM > > force-feed me bars of soap until I wake up in a cold sweat ;-) > > Yeah, except SOAP can be used to communicate a RESTful protocol. It's > all about how you use the transport mechanism. I've always thought it would be interesting if someone sponsored a "tunneling contest" to see who can tunnel the most protocols in the most creative fashion. Someone might try to say "hello world" across a network by distributing dynamic data exchange between windows on separate machines by taking a DDE execute message and marshaling it as COM invocation using an RPC tunneled through canonicalized, base 64-encoded XML-RPC messages communicated via a RESTful implementation built with Python on SOAP running on HTTP implemented over TCP/IP, where a proxy server sitting inside a firewall receives the request, unmarshals each of its layers, and faxes the message to a gorilla who takes the paper and feeds it into a scanner that performs OCR to interpret the message and send it to a Windows desktop running a NetDDE server that dispatches the request by writing the message to a temporary HTML file containing JavaScript loaded by a web browser that displays the original "hello world" in a message box. -Phil
"Philip Eskelin" wrote: > I'm developing a REST toolkit Philip and anybody else who is developing REST toolkits please announce when something becomes available for use? Either here or maybe better, start a rest-wiki page? I'm not developing one, but would like to use one. Thanks, Bob Haugen
Bob, Thanks for showing interest! Originally, my toolkit wasn't officially REST. But as I began to read RESTwiki and lurk on this group, I realized that my design turned out to be very RESTful. I'm also working on including environmental acquisition [1], which I find complements REST *very* well. They're a powerful combo. I hesitate to say much until I've got a stable release, but I plan on announcing availability as soon as possible. Then, whether we mention it on RESTwiki or create a separate wiki instance is fine with me. My hope is that its availability will help us really see and be able to use something that's concrete and helps us refine our notion of REST. Thanks, Philip [1] http://www.ccs.neu.edu/home/lorenz/research/acquisition/ -----Original Message----- From: bhaugen32 [mailto:bhaugen32@...] Sent: Wednesday, June 05, 2002 10:54 AM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] Re: REST toolkits "Philip Eskelin" wrote: > I'm developing a REST toolkit Philip and anybody else who is developing REST toolkits please announce when something becomes available for use? Either here or maybe better, start a rest-wiki page? I'm not developing one, but would like to use one. Thanks, Bob Haugen
Scott wrote: > Our company is in kind of the same boat WRT REST. We started > building our product back in spring of 2000, and now we're > finding out that we've incorporated a lot of RESTful features. > At the moment we're working on putting together a developer > release for people to play with until we can get to a Beta > release. That's great. We should try to provide a place on RESTwiki (if it doesn't already exist) that starts to collect references to some of these efforts. I feel like I'm at the same location in development as you are, so it will be interesting to share our interpretations of REST once the work goes public. -Philip
/me catches up on this list What Web server are you using? Is the content generated, or just on disk? This problem (load balancing vs. ETag generation) was recognized a while back, and I know that Apache has recently put a fix in (but IIRC you have to explicitly configure the behaviour). Depending on your situation, there are a number of ways to approach the problem. Cheers, ----- Original Message ----- From: "Simon Fell" <sf@...> To: <rest-discuss@yahoogroups.com> Sent: Sunday, May 19, 2002 1:58 PM Subject: Re[2]: [rest-discuss] HTTP caching questions ? > ok, here goes. > > Basically i need to support efficient checks that content is upto > date, and to also support resumable downloads [some of the content is large > binary files accessed via a potentially un-reliable low bandwidth > connection]. This content is potentially served by a set of web servers > running behind a HTTP load balancer. > > For a single server scenario, this seems pretty straightforward, At > the client cache I track expected size [from the content-length > header], Etag and last-modified. for subsequent requests I populate a > If-None-Match header from the etag, a Range & Range-If header if the > expected size is not the same as the cached file size, and i send a > If-Modified-Since header if i don't have a Range header [my reading of > the use of Range & Range-If lead me to believe to not use > If-Modified-Since if i'm using ranges]. > > My concern is when i have 2 or more web servers, all running behind a > load balancer [local director etc], that each server will be assigning > different etags to the same content (i don't see anything in the spec > that lets me assume different server instances will generate the same > etag for the same content, even for the same versions of HTTP server > software). This is leading me to think about not using etags, and to > just use the modified date, but then it doesn't look like you can do > ranges with modified dates. Its also crossed my mind to use > content-md5, but this doesn't seem very widely support [if at all]. > > Any suggestions ? > > Thanks > Simon > > Saturday, May 18, 2002, 1:50:51 PM, you wrote: > > > I think it would be great if you asked the questions here. I am not > > "deep" in HTTP cacheing but I know that Mark Nottingham is and I suspect > > Mark Baker knows quite a bit also. This list seems to be the last refuge > > of people who don't think of HTTP as a dinosaur ;). > > > simonfell99 wrote: > >> > >> Hi, > >> > >> I'm in the process of prototyping a REST version of an existing RPC > >> based system, a large chunk of this system revolves around > >> efficiently managing updates to content at the client system. I'm > >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- > >> Since, If-None-Match and If-Range). I have some questions about how > >> this works when deployed on a cluster of servers with a load > >> balancer, is this a good place to ask, or can someone recommend a > >> good list to discuss HTTP caching. > >> > >> Tx > >> Simon > >> > >> > >> To unsubscribe from this group, send an email to: > >> rest-discuss-unsubscribe@yahoogroups.com > >> > >> > >> > >> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
Thanks Mark, I'm using Apache, I found the info about the directives that control the etag generation, and am in the process of getting some servers updated so i can test this out. I was hoping to find a solution that wasn't reliant on specific behavior in the web server, but couldn't come up with anything. The content is generated, but due to the way the generation process works, its static files as far as the web server is concerned. Cheers, Simon Thursday, June 06, 2002, 12:22:36 PM, you wrote: > /me catches up on this list > What Web server are you using? Is the content generated, or just on disk? > This problem (load balancing vs. ETag generation) was recognized a while > back, and I know that Apache has recently put a fix in (but IIRC you have > to explicitly configure the behaviour). Depending on your situation, there > are a number of ways to approach the problem. > Cheers, > ----- Original Message ----- > From: "Simon Fell" <sf@...> > To: <rest-discuss@yahoogroups.com> > Sent: Sunday, May 19, 2002 1:58 PM > Subject: Re[2]: [rest-discuss] HTTP caching questions ? >> ok, here goes. >> >> Basically i need to support efficient checks that content is upto >> date, and to also support resumable downloads [some of the content is > large >> binary files accessed via a potentially un-reliable low bandwidth >> connection]. This content is potentially served by a set of web servers >> running behind a HTTP load balancer. >> >> For a single server scenario, this seems pretty straightforward, At >> the client cache I track expected size [from the content-length >> header], Etag and last-modified. for subsequent requests I populate a >> If-None-Match header from the etag, a Range & Range-If header if the >> expected size is not the same as the cached file size, and i send a >> If-Modified-Since header if i don't have a Range header [my reading of >> the use of Range & Range-If lead me to believe to not use >> If-Modified-Since if i'm using ranges]. >> >> My concern is when i have 2 or more web servers, all running behind a >> load balancer [local director etc], that each server will be assigning >> different etags to the same content (i don't see anything in the spec >> that lets me assume different server instances will generate the same >> etag for the same content, even for the same versions of HTTP server >> software). This is leading me to think about not using etags, and to >> just use the modified date, but then it doesn't look like you can do >> ranges with modified dates. Its also crossed my mind to use >> content-md5, but this doesn't seem very widely support [if at all]. >> >> Any suggestions ? >> >> Thanks >> Simon >> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote: >> >> > I think it would be great if you asked the questions here. I am not >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I > suspect >> > Mark Baker knows quite a bit also. This list seems to be the last > refuge >> > of people who don't think of HTTP as a dinosaur ;). >> >> > simonfell99 wrote: >> >> >> >> Hi, >> >> >> >> I'm in the process of prototyping a REST version of an existing RPC >> >> based system, a large chunk of this system revolves around >> >> efficiently managing updates to content at the client system. I'm >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- >> >> Since, If-None-Match and If-Range). I have some questions about how >> >> this works when deployed on a cluster of servers with a load >> >> balancer, is this a good place to ask, or can someone recommend a >> >> good list to discuss HTTP caching. >> >> >> >> Tx >> >> Simon >> >> >> >> >> >> To unsubscribe from this group, send an email to: >> >> rest-discuss-unsubscribe@yahoogroups.com >> >>
>It might help for your understanding of REST to divorce yourself from >HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used >for an implementation of REST, but isn't the perfect embodiment of REST. Is it me, or does this sound strangely close to the thinking that brought about Don Box's notorious "HTTP is Dead" keynote? Replace REST with SOAP in the last sentence, and what do you have? Put another way, is there a meaningful non-HTTP implementation of REST out in the wild? Sorry, but I really tripped on this statement. Would anybody care to expand on it?
> > ----- Original Message ----- > > From: "Simon Fell" <sf@...> > >> > >> My concern is when i have 2 or more web servers, all running behind a > >> load balancer [local director etc], that each server will be assigning > >> different etags to the same content (i don't see anything in the spec > >> that lets me assume different server instances will generate the same > >> etag for the same content, even for the same versions of HTTP server > >> software). If the server instances are behind a load balancer, then shouldn't both appear to be a single 'server' in http-spec-land, and the intended behavior is that the etag should match? In other words, the http spec does let you assume that different machines behind a logical 'server' will provide the same etag - but it doesn't assume that it is /easy/ to do that...
----- Original Message ----- From: "Gordon Weakliem" <gweakliem@...> > > Is it me, or does this sound strangely close to the thinking that brought about Don Box's notorious "HTTP is Dead" > keynote? Replace REST with SOAP in the last sentence, and what do you have? Put another way, is > there a meaningful non-HTTP implementation of REST out in the wild? > Sorry, but I really tripped on this statement. Would anybody care to expand on it? I think of SQL based systems as something with a lot of REST-like qualities. They are much better at the jobs they were designed for than a REST based system, but REST is better at jobs /it/ was designed for.
Do you mean that the content is generated and written to static files, or that it's served by a process that runs in response to requests (e.g., CGI, PHP, etc.), but that the results are generally cacheable? ----- Original Message ----- From: "Simon Fell" <sf@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Thursday, June 06, 2002 7:09 PM Subject: Re[4]: [rest-discuss] HTTP caching questions ? > Thanks Mark, > > I'm using Apache, I found the info about the directives that control > the etag generation, and am in the process of getting some servers > updated so i can test this out. > > I was hoping to find a solution that wasn't reliant on specific > behavior in the web server, but couldn't come up with anything. > > The content is generated, but due to the way the generation process > works, its static files as far as the web server is concerned. > > Cheers, > Simon > > Thursday, June 06, 2002, 12:22:36 PM, you wrote: > > > /me catches up on this list > > > What Web server are you using? Is the content generated, or just on disk? > > > This problem (load balancing vs. ETag generation) was recognized a while > > back, and I know that Apache has recently put a fix in (but IIRC you have > > to explicitly configure the behaviour). Depending on your situation, there > > are a number of ways to approach the problem. > > > Cheers, > > > > ----- Original Message ----- > > From: "Simon Fell" <sf@...> > > To: <rest-discuss@yahoogroups.com> > > Sent: Sunday, May 19, 2002 1:58 PM > > Subject: Re[2]: [rest-discuss] HTTP caching questions ? > > > >> ok, here goes. > >> > >> Basically i need to support efficient checks that content is upto > >> date, and to also support resumable downloads [some of the content is > > large > >> binary files accessed via a potentially un-reliable low bandwidth > >> connection]. This content is potentially served by a set of web servers > >> running behind a HTTP load balancer. > >> > >> For a single server scenario, this seems pretty straightforward, At > >> the client cache I track expected size [from the content-length > >> header], Etag and last-modified. for subsequent requests I populate a > >> If-None-Match header from the etag, a Range & Range-If header if the > >> expected size is not the same as the cached file size, and i send a > >> If-Modified-Since header if i don't have a Range header [my reading of > >> the use of Range & Range-If lead me to believe to not use > >> If-Modified-Since if i'm using ranges]. > >> > >> My concern is when i have 2 or more web servers, all running behind a > >> load balancer [local director etc], that each server will be assigning > >> different etags to the same content (i don't see anything in the spec > >> that lets me assume different server instances will generate the same > >> etag for the same content, even for the same versions of HTTP server > >> software). This is leading me to think about not using etags, and to > >> just use the modified date, but then it doesn't look like you can do > >> ranges with modified dates. Its also crossed my mind to use > >> content-md5, but this doesn't seem very widely support [if at all]. > >> > >> Any suggestions ? > >> > >> Thanks > >> Simon > >> > >> Saturday, May 18, 2002, 1:50:51 PM, you wrote: > >> > >> > I think it would be great if you asked the questions here. I am not > >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I > > suspect > >> > Mark Baker knows quite a bit also. This list seems to be the last > > refuge > >> > of people who don't think of HTTP as a dinosaur ;). > >> > >> > simonfell99 wrote: > >> >> > >> >> Hi, > >> >> > >> >> I'm in the process of prototyping a REST version of an existing RPC > >> >> based system, a large chunk of this system revolves around > >> >> efficiently managing updates to content at the client system. I'm > >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- > >> >> Since, If-None-Match and If-Range). I have some questions about how > >> >> this works when deployed on a cluster of servers with a load > >> >> balancer, is this a good place to ask, or can someone recommend a > >> >> good list to discuss HTTP caching. > >> >> > >> >> Tx > >> >> Simon > >> >> > >> >> > >> >> To unsubscribe from this group, send an email to: > >> >> rest-discuss-unsubscribe@yahoogroups.com > >> >> >
The content is generated and written to a static file as part of a separate process that happens before the HTTP requests start to occur. The resulting static files are cachable. At some future date the plan it to ditch the separate process, and have the content generated dynamically in the HTTP server itself [probably using servlets], the results of this are still cachable. I assume in this case I'll have to handle etag validation myself in the servlet. Cheers, Simon Thursday, June 06, 2002, 9:49:34 PM, you wrote: > Do you mean that the content is generated and written to static files, or > that it's served by a process that runs in response to requests (e.g., > CGI, PHP, etc.), but that the results are generally cacheable? > ----- Original Message ----- > From: "Simon Fell" <sf@...> > To: "Mark Nottingham" <mnot@...> > Cc: <rest-discuss@yahoogroups.com> > Sent: Thursday, June 06, 2002 7:09 PM > Subject: Re[4]: [rest-discuss] HTTP caching questions ? >> Thanks Mark, >> >> I'm using Apache, I found the info about the directives that control >> the etag generation, and am in the process of getting some servers >> updated so i can test this out. >> >> I was hoping to find a solution that wasn't reliant on specific >> behavior in the web server, but couldn't come up with anything. >> >> The content is generated, but due to the way the generation process >> works, its static files as far as the web server is concerned. >> >> Cheers, >> Simon >> >> Thursday, June 06, 2002, 12:22:36 PM, you wrote: >> >> > /me catches up on this list >> >> > What Web server are you using? Is the content generated, or just on > disk? >> >> > This problem (load balancing vs. ETag generation) was recognized a > while >> > back, and I know that Apache has recently put a fix in (but IIRC you > have >> > to explicitly configure the behaviour). Depending on your situation, > there >> > are a number of ways to approach the problem. >> >> > Cheers, >> >> >> > ----- Original Message ----- >> > From: "Simon Fell" <sf@...> >> > To: <rest-discuss@yahoogroups.com> >> > Sent: Sunday, May 19, 2002 1:58 PM >> > Subject: Re[2]: [rest-discuss] HTTP caching questions ? >> >> >> >> ok, here goes. >> >> >> >> Basically i need to support efficient checks that content is upto >> >> date, and to also support resumable downloads [some of the content is >> > large >> >> binary files accessed via a potentially un-reliable low bandwidth >> >> connection]. This content is potentially served by a set of web > servers >> >> running behind a HTTP load balancer. >> >> >> >> For a single server scenario, this seems pretty straightforward, At >> >> the client cache I track expected size [from the content-length >> >> header], Etag and last-modified. for subsequent requests I populate a >> >> If-None-Match header from the etag, a Range & Range-If header if the >> >> expected size is not the same as the cached file size, and i send a >> >> If-Modified-Since header if i don't have a Range header [my reading > of >> >> the use of Range & Range-If lead me to believe to not use >> >> If-Modified-Since if i'm using ranges]. >> >> >> >> My concern is when i have 2 or more web servers, all running behind a >> >> load balancer [local director etc], that each server will be > assigning >> >> different etags to the same content (i don't see anything in the spec >> >> that lets me assume different server instances will generate the same >> >> etag for the same content, even for the same versions of HTTP server >> >> software). This is leading me to think about not using etags, and to >> >> just use the modified date, but then it doesn't look like you can do >> >> ranges with modified dates. Its also crossed my mind to use >> >> content-md5, but this doesn't seem very widely support [if at all]. >> >> >> >> Any suggestions ? >> >> >> >> Thanks >> >> Simon >> >> >> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote: >> >> >> >> > I think it would be great if you asked the questions here. I am not >> >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I >> > suspect >> >> > Mark Baker knows quite a bit also. This list seems to be the last >> > refuge >> >> > of people who don't think of HTTP as a dinosaur ;). >> >> >> >> > simonfell99 wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> I'm in the process of prototyping a REST version of an existing > RPC >> >> >> based system, a large chunk of this system revolves around >> >> >> efficiently managing updates to content at the client system. I'm >> >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- >> >> >> Since, If-None-Match and If-Range). I have some questions about > how >> >> >> this works when deployed on a cluster of servers with a load >> >> >> balancer, is this a good place to ask, or can someone recommend a >> >> >> good list to discuss HTTP caching. >> >> >> >> >> >> Tx >> >> >> Simon >> >> >> >> >> >> >> >> >> To unsubscribe from this group, send an email to: >> >> >> rest-discuss-unsubscribe@yahoogroups.com >> >> >> >>
That's probably the way to go. I had a hope in the back of my mind that you could assign ETags using .htaccess, but some quick testing rules that out. If you want to generate and validate ETags, you might be interested in cgi_buffer[1]; there isn't Java in there, but it may be useful as a starting point. 1. http://www.mnot.net/cgi_buffer/ ----- Original Message ----- From: "Simon Fell" <sf@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Thursday, June 06, 2002 10:01 PM Subject: Re[6]: [rest-discuss] HTTP caching questions ? > The content is generated and written to a static file as part of a > separate process that happens before the HTTP requests start to occur. > The resulting static files are cachable. > > At some future date the plan it to ditch the separate process, and > have the content generated dynamically in the HTTP server itself > [probably using servlets], the results of this are still cachable. I > assume in this case I'll have to handle etag validation myself in the > servlet. > > Cheers, > Simon > > Thursday, June 06, 2002, 9:49:34 PM, you wrote: > > > Do you mean that the content is generated and written to static files, or > > that it's served by a process that runs in response to requests (e.g., > > CGI, PHP, etc.), but that the results are generally cacheable? > > > > ----- Original Message ----- > > From: "Simon Fell" <sf@...> > > To: "Mark Nottingham" <mnot@...> > > Cc: <rest-discuss@yahoogroups.com> > > Sent: Thursday, June 06, 2002 7:09 PM > > Subject: Re[4]: [rest-discuss] HTTP caching questions ? > > > >> Thanks Mark, > >> > >> I'm using Apache, I found the info about the directives that control > >> the etag generation, and am in the process of getting some servers > >> updated so i can test this out. > >> > >> I was hoping to find a solution that wasn't reliant on specific > >> behavior in the web server, but couldn't come up with anything. > >> > >> The content is generated, but due to the way the generation process > >> works, its static files as far as the web server is concerned. > >> > >> Cheers, > >> Simon > >> > >> Thursday, June 06, 2002, 12:22:36 PM, you wrote: > >> > >> > /me catches up on this list > >> > >> > What Web server are you using? Is the content generated, or just on > > disk? > >> > >> > This problem (load balancing vs. ETag generation) was recognized a > > while > >> > back, and I know that Apache has recently put a fix in (but IIRC you > > have > >> > to explicitly configure the behaviour). Depending on your situation, > > there > >> > are a number of ways to approach the problem. > >> > >> > Cheers, > >> > >> > >> > ----- Original Message ----- > >> > From: "Simon Fell" <sf@...> > >> > To: <rest-discuss@yahoogroups.com> > >> > Sent: Sunday, May 19, 2002 1:58 PM > >> > Subject: Re[2]: [rest-discuss] HTTP caching questions ? > >> > >> > >> >> ok, here goes. > >> >> > >> >> Basically i need to support efficient checks that content is upto > >> >> date, and to also support resumable downloads [some of the content is > >> > large > >> >> binary files accessed via a potentially un-reliable low bandwidth > >> >> connection]. This content is potentially served by a set of web > > servers > >> >> running behind a HTTP load balancer. > >> >> > >> >> For a single server scenario, this seems pretty straightforward, At > >> >> the client cache I track expected size [from the content-length > >> >> header], Etag and last-modified. for subsequent requests I populate a > >> >> If-None-Match header from the etag, a Range & Range-If header if the > >> >> expected size is not the same as the cached file size, and i send a > >> >> If-Modified-Since header if i don't have a Range header [my reading > > of > >> >> the use of Range & Range-If lead me to believe to not use > >> >> If-Modified-Since if i'm using ranges]. > >> >> > >> >> My concern is when i have 2 or more web servers, all running behind a > >> >> load balancer [local director etc], that each server will be > > assigning > >> >> different etags to the same content (i don't see anything in the spec > >> >> that lets me assume different server instances will generate the same > >> >> etag for the same content, even for the same versions of HTTP server > >> >> software). This is leading me to think about not using etags, and to > >> >> just use the modified date, but then it doesn't look like you can do > >> >> ranges with modified dates. Its also crossed my mind to use > >> >> content-md5, but this doesn't seem very widely support [if at all]. > >> >> > >> >> Any suggestions ? > >> >> > >> >> Thanks > >> >> Simon > >> >> > >> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote: > >> >> > >> >> > I think it would be great if you asked the questions here. I am not > >> >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I > >> > suspect > >> >> > Mark Baker knows quite a bit also. This list seems to be the last > >> > refuge > >> >> > of people who don't think of HTTP as a dinosaur ;). > >> >> > >> >> > simonfell99 wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> I'm in the process of prototyping a REST version of an existing > > RPC > >> >> >> based system, a large chunk of this system revolves around > >> >> >> efficiently managing updates to content at the client system. I'm > >> >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified- > >> >> >> Since, If-None-Match and If-Range). I have some questions about > > how > >> >> >> this works when deployed on a cluster of servers with a load > >> >> >> balancer, is this a good place to ask, or can someone recommend a > >> >> >> good list to discuss HTTP caching. > >> >> >> > >> >> >> Tx > >> >> >> Simon > >> >> >> > >> >> >> > >> >> >> To unsubscribe from this group, send an email to: > >> >> >> rest-discuss-unsubscribe@yahoogroups.com > >> >> >> > >> >
I am having a debate with a colleague. I am arguing that when SOAP is used you POST to the SOAP server, and it then looks inside the SOAP message to determine which application to delegate to. Thus, when you invoke a Web service the URI is to the SOAP server, not to the target application (i.e., resource). For example, if a company has deployed three Web services then despite which Web service a client wishes to invoke, the URI will always be the same, for example: http://www.parts-depot.com/soap/server What differs, of course, is the contents of the SOAP message. I argue that this hiding of the identity of the target resource in the SOAP message is a disadvantage of SOAP (one of the key disadvantages of SOAP). My colleague argues that this is not true. He says that a client can provide the URI directly to the target Web service (resource), for example: http://www.parts-depot.com/parts http://www.parts-depot.com/parts/part/00345 http://www.parts-depot.com/parts/purchase-order He claims that he has done this using WebLogic. Here's a quote from him: "We were able to have 2 web services on the same machines with different URI, using WebLogic. I haven't used WebLogic, so I can't verify his statement. Can someone settle this debate please? /Roger
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I have somewhat of dilemma with regard to representing URI's to resources in
the data returned back to the client. I know I could use things like XLink or
RDF (I have the theoretical howto, not practical knowledge) to represent the
URI's in the data, but I am not sure what the point would be - perhaps
someone can enlighten me and point me to some recommended starting points? I
have searched the web for XLink and RDF stuff but it isn't really clear why I
would do this.
Here is a small snippet of what I currently have:
<craft>
<package name="package_name" uri="http://craft.org/package/package_name/">
<homepage-url location="http://somehost.com" />
<download-url location="http://somehost.com/ri.tgz" />
.....
</package>
</craft>
Any pointers on this dilemma would be greatly appreciated, thank you in
advance.
- --
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9AJHR0X8w8X71zPcRAodvAJsGVi4loj2+FTKaDkGyQudTkrkoYACfXnOv
s6uvUKdqczoSvG2ycn4au7I=
=FgXK
-----END PGP SIGNATURE-----
"Roger L. Costello" wrote: > > I am having a debate with a colleague. I am arguing that when SOAP is > used you POST to the SOAP server, and it then looks inside the SOAP > message to determine which application to delegate to. The protocol can only suggest, not enforce, a dispatching strategy. Still, Sam Ruby and I discussed this issue a few weeks ago and we could not come up with a simple, documented way (or at least a way that is simply documented) to do dispatching to a logical resource in the popular SOAP toolkits out there. >... > My colleague argues that this is not true. He says that a client can > provide the URI directly to the target Web service (resource), for > example: > > http://www.parts-depot.com/parts > http://www.parts-depot.com/parts/part/00345 > http://www.parts-depot.com/parts/purchase-order > > He claims that he has done this using WebLogic. Here's a quote from him: > > "We were able to have 2 web services on the same machines with different > URI, using WebLogic. Sure, that latter statement is absolutely true. You can have ten web services at ten URIs if you want. But let's say someone adds a purchase order. Will WebLogic make it easy for software to accept SOAP POSTs to a newly created URI? Or would it have to do something gross like tweaking a configuration file or copying files around the file system. In other words, do you have to trick it into supporting dynamically created objects with new URIs or is it a native feature? SOAP won't stop you from being more intelligent than the average SOAP service but most SOAP toolkits will make it difficult or impossible. And even if a single SOAP-based web service did the right thing, you don't get the network effect if you are the only person who has figured out how to trick the tools into doing what you want. Paul Prescod
I would like to thank all those who have argued so eloquently, so patiently the case of REST, both on the list groups and in articles, and who have answered my oftentimes naive questions. I came across some wonderful wisdom lately, that I think has relevance to the REST "cause". There is an online e-book called the Wisdom of Henry Hazlitt[1]. He is a delightful writer (his most famous book is Economics in One Lesson, which is great!). In one part of the e-book is a transcript of a speech that he gave to an audience of economists. He talks about the free market, and why there is increasingly less openness in the market. He talks about how, when you're in the minority, it is important to clearly, logically articulate your position. Many people on this list have done so. You are to be applauded. I intend on doing my part in the upcoming weeks and months. Below is an excerpt from Henry Hazlitt's talk. /Roger The Wisdom of Henry Hazlitt Why are we drifting deeper and deeper into socialism and the dark night of totalitarianism? Why have those of us who believe in human liberty been so ineffective? "We Haven't Been Good Enough" I am going to give what is no doubt a terribly oversimplified answer to that question. In the first place, we are almost hopelessly outnumbered. Our voices are simply drowned out in the general tumult and clamor. But there is another reason. And this is hard to say, above all to an audience of this sort, which contains some of the most brilliant writers and minds in the fields of economics, of jurisprudence, of politics, not only of this age but of any age. But the hard thing must be said that, collectively, we just haven't been good enough. We haven't convinced the majority. Is this because the majority just won't listen to reason? I am enough of an optimist, and I have enough faith in human nature, to believe that people will listen to reason if they are convinced that it is reason. Somewhere, there must be some missing argument, something that we haven't seen clearly enough, or said clearly enough, or, perhaps, just not said often enough. A minority is in a very awkward position. The individuals in it can't afford to be just as good as the individuals in the majority. If they hope to convert the majority they have to be much better; and the smaller the minority, the better they have to be. They have to think better. They have to know more. They have to write better. They have to have better controversial manners. Above all, they have to have far more courage. And they have to be infinitely patient. [1] http://www.hazlitt.org/e-texts/wisdom/
At 02:12 PM 6/7/02, Roger L. Costello quoted Henry Hazlitt, [1] http://www.hazlitt.org/e-texts/wisdom/ >Why have those of us who believe in human liberty been so ineffective? > > "We Haven't Been Good Enough" > >I am going to give what is no doubt a terribly oversimplified answer to >that question. In the first place, we are almost hopelessly outnumbered. >Our voices are simply drowned out in the general tumult and clamor. But >there is another reason....collectively, we just haven't been good enough. I think REST like many other technologies, is moving in the right direction. I'm an accountant, an economist really. Not a programmer. As a user, I just look at software and ask, "does this give me a net advantage, or disadvantage?" But when non-programmers look at the entire range of verbs, nouns, platforms, software objects, routing, business models, tiers etc. there is a complete and total paralysis because the permutations are so great. Vendors of course, bundle many decisions into their software product, service etc. having some kind of resultant force vector that usually cuts too deep into the users' sovereignty or advantage. I have listed some of these "axes" of centralization/decentralization on my website... comments welcome, hope this is useful. http://www.gldialtone.com/P2PAxes.htm In summary, whenever a particular technical or functional requirement is served most economically by centralization, a transfer of business advantage (asymmetry of benefit) needs to be avoided by some means, TOdd
Argh. Lost my try at this to a mailer crash. :( Okay, let's first define transactions in the context of this discussion because people often mean different things. You do not mean transaction in the sense of requiring "a group of operations on (distributed) resources be treated as one unit of work. In a unit of work, all the participating operations should either succeed or fail and recover together." * http://www.subrahmanyam.com/articles/transactions/NutsAndBoltsOfTP.html Rather you mean transaction in the business sense, which is an agreement to exchange services, products or money. Now thinking about this from an XP perspective, I want to think about the simplest thing and see why it won't work. The simplest thing is for me to send you an "offer" message and you reply with "accept" or "decline". That's not good enough, however, because deciding whether to accept may take a long time. So it is necessary for the exchange to be broken into two parts: "request service" and then at some indeterminate time later, "provide response". In other words there are four messages: bhaugen32 wrote: > >... > > It's a two-party request-response interaction, with receipt > acknowledgements for both request and response. "Can we do business?" "I acknowledge that you want to do business. I will get back to you." "I agree/disagree we should do business." "I acknowledge your agreement/disagreement." >... > > There are time constraints on each step. If any timeout occurs, the > transaction fails with a Control Failure. Note that in the absence of reliable transport it is still possible for the businesses to end up misaligned. An HTTP-based solution needs to use HTTP in a manner that will ensure reliability. > In cases where the Response document says "Accept" but has an error, > and the error message from the requesting business service cannot be > delivered, the transaction model specifies a separate Notification of > Failure to be sent from the requesting business service via another > channel. Otherwise the responding activity may think incorrectly > that the transaction succeeded. I see, so otherwise it is to assume the transaction succeeded if it returns an Accept, whether it gets a receipt or not? >... > Replace the business service access points with resources > representing the business entity being offered, for example the > Order. (Alternatively, each transaction might become a sub-resource > under the Order.) > > RosettaNet and ebXML assume that a business service access point will > handle many transactions for many business activities, so each > message contains tags for dispatching to the business collaboration > (long conversation about the Order), business transaction, and > business activity. You'll have to describe why all of these levels of statefulness are necessary. And if you want to represent them in REST then you should give them all URIs and point to them. > If the resource is the Order, then only the business transaction and > business activity tags are required. > If the resource is the Transaction, then the business activity can be > assumed. Sounds stateful. Better to use references. > In either case, I think the REST style is functionally equivalent to > the EDI-mailbox style, but has at least two advantages: Before I feel comfortable that this has been expressed in a REST style, I'd like to see some URIs, XML and HTTP methods. ;) I propose that what you will need is at least two HTTP request/response pairs, one in each direction. To get reliability, though, you probably actually need four, as I discuss here: * http://www.prescod.net/reliable_http.html So you would -> POST: "I'd like to make an offer" <- OK, here's an offer-holder URI -> PUT the offer at offer-holder URI <- OK, I've received it and will get back to you The offer should have a callback address, unless you are using something like HTTP events. Either way, <- POST "I'd like to return a reliable offer-response" -> OK, here's an offer-response-holder URI <- PUT the offer-response at the holder-URI -> OK, I've got the offer-response Paul Prescod
You're both right ;) It's certainly possible to hide "applications" behind a single URI in SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses of cookies, query args, etc.) The trick is how you define "application" (or, more in tune with this list, "resource"); it's a design-time philosophical question of how much you want to expose. For example, my car could have a URI*. The resource is the car, and it has an identifier; http://www.mnot.net/2000/vw/golf/VIN1234567 How do I roll down the window? I could POST to the car with a body containing something like part=leftwindow&action=rolldown or I could expose a subresource http://www.mnot.net/2000/vw/golf/VIN1234567/window-left/ to POST a action=rolldown to. Then again, I could expose http://www.mnot.net/2000/vw/golf/VIN1234567/window/left/ and do the same; this would allow me to perform actions on all of the windows (such as "clean") by specifying "window", whilst still preserving the subresource relationship between "window" and "left". Being more specific, I could expose the position of the window as a resource; http://www.mnot.net/2000/vw/golf/VIN1234567/window/left/position which is quite RESTful. Now, what if I wanted to wash only part of the window, say the inside? Wait a minute, you say; if we reduce this argment to the absurd, every atom (and atomic particle) in the window is potentially a resource. I am very much reminded of my first year philosophy teacher; he introduced himself to the class by asking us what a chair was. We replied, after some hesitation, "that", accompanied by some pointing. Without repeating the progression above, we got down to the point where an atom was in an indeterminate state based on whether the chair was touching the floor or not. Back to SOAP (and hopefully a bit closer to reality), it's up to you as to what you expose in the URI interface. If you want it to be interoperable with applications that need to reference different subresources, that would indicate the use of separate URIs. You can do this in any Web Services environment; the only question is how much pain you have to put up with to give different services different URIs. If you're happy with the services that have to do with a car being available on the 'car' URI, so be it; that's your choice, and it's just as much on the Web as the other ones. * This is the subject of some debate elsewhere, but let's assume it's true ;) ----- Original Message ----- From: "Roger L. Costello" <costello@...> To: <rest-discuss@yahoogroups.com>; <costello@...> Sent: Friday, June 07, 2002 4:20 AM Subject: [rest-discuss] With SOAP the URI does not directly reference the resource, right? > I am having a debate with a colleague. I am arguing that when SOAP is > used you POST to the SOAP server, and it then looks inside the SOAP > message to determine which application to delegate to. Thus, when you > invoke a Web service the URI is to the SOAP server, not to the target > application (i.e., resource). For example, if a company has deployed > three Web services then despite which Web service a client wishes to > invoke, the URI will always be the same, for example: > > http://www.parts-depot.com/soap/server > > What differs, of course, is the contents of the SOAP message. I argue > that this hiding of the identity of the target resource in the SOAP > message is a disadvantage of SOAP (one of the key disadvantages of > SOAP). > > My colleague argues that this is not true. He says that a client can > provide the URI directly to the target Web service (resource), for > example: > > http://www.parts-depot.com/parts > http://www.parts-depot.com/parts/part/00345 > http://www.parts-depot.com/parts/purchase-order > > He claims that he has done this using WebLogic. Here's a quote from him: > > "We were able to have 2 web services on the same machines with different > URI, using WebLogic. > > I haven't used WebLogic, so I can't verify his statement. > > Can someone settle this debate please? /Roger > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
----- Original Message ----- From: "Roger L. Costello" <costello@...> > > My colleague argues that this is not true. He says that a client can > provide the URI directly to the target Web service (resource), for > example: > > http://www.parts-depot.com/parts > http://www.parts-depot.com/parts/part/00345 > http://www.parts-depot.com/parts/purchase-order > > He claims that he has done this using WebLogic. Here's a quote from him: > > "We were able to have 2 web services on the same machines with different > URI, using WebLogic. > > I haven't used WebLogic, so I can't verify his statement. > I haven't done this with WebLogic or any other toolkit, but my guess is that it is pretty easy to route HTTP requests to HTTP handlers based on a URI pattern. For example, in Java servlets, you can associate a single servlet with the pattern "/parts/part" and a different one to "/parts/purchase-order" - and the servlet you route to could be a SOAP aware thing. So, my guess is that it isn't that hard. If you did route this way - via common HTTP URI based handling - then the SOAP receiver probably won't be coded to know the HTTP URI - the info would have to be replicated within the SOAP body.
-----Original Message----- From: Mark Nottingham [mailto:mnot@...] Sent: Friday, June 07, 2002 3:38 PM To: rest-discuss@yahoogroups.com; costello@... Subject: Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right? You're both right ;) It's certainly possible to hide "applications" behind a single URI in SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses of cookies, query args, etc.) The trick is how you define "application" (or, more in tune with this list, "resource"); it's a design-time philosophical question of how much you want to expose. I think this points out subtle but important distinction. There are certain ramifications if we make what to expose and how to expose "applications", "resources", or "objects" a design-time decision. I think one of the fundamental advantages of RESTful thinking is that it allows you make closer to a run-time decision. In other words, you don't need to rewrite an application, you can simply choose to expose something later or hide something as your needs change or the needs of you partners change. You can only do this if the resource addressing mechanism is the same regardless of whether you choose to expose it at design time or not. Whereas SOAP forces you to choose your addressing scheme at design time depending on if the resource is to be hidden or exposed. There is certainly no inherent limit from SOAP as to what you can choose to expose or not. What is limiting is that once you decide what is to be accessed via URI and what is to be accessed via a method call, you are locked in. This gets back to what I was trying to say (maybe unsuccessfully), that the universality of URI as a pass-by-reference addressing scheme allows us one of the advantage of OOP programming where everything is an object and every object is addressable. Hiding and not hiding is simply a matter of whether you want to give someone the reference to that object or not. You don't need to redesign the whole thing. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Mark Nottingham wrote: > > You're both right ;) > > It's certainly possible to hide "applications" behind a single URI in > SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses > of cookies, query args, etc.) Actually, I don't think that PowerPoint hides anything at all. There is a URI representing the PowerPoint document. That is the level at which you can do network transactions. You can talk about individual slides using pointers into the slideshow, but that isn't a protocol/networking issue, because it has resolved completely on the "client side". > ... > Wait a minute, you say; if we reduce this argment to the absurd, every > atom (and atomic particle) in the window is potentially a resource. No. At some point you are no longer interested in sending messages to objects and I would say that that's the point you stop decomposing. It isn't a judgement call. If you need to address something in a network transaction then the thing needs a URI. >... > Back to SOAP (and hopefully a bit closer to reality), it's up to you as to > what you expose in the URI interface. If you want it to be interoperable > with applications that need to reference different subresources, that > would indicate the use of separate URIs. You can do this in any Web > Services environment; the only question is how much pain you have to put > up with to give different services different URIs. Could you describe how to do this in any web service environments you are familiar with? Remember that an important requirement is that new resources will be created all of the time with no human interaction. > ... If you're happy with > the services that have to do with a car being available on the 'car' URI, > so be it; that's your choice, and it's just as much on the Web as the > other ones. I think you've missed an important distinction. If the "car" has a representation that exposes all of the state of the window then yes, the window is "on the Web" despite the fact that it does not have its own URI. It can be addressed through a URI reference (e.g. URI+XPointer) But if you must POST a message to the car to ask *it* about the state of the window, then the window has neither a URI nor a URI refrence and it is not on the Web. If you cannot reference it with a Web address then I don't think it is on the Web. Paul Prescod
> Actually, I don't think that PowerPoint hides anything at all. There is > a URI representing the PowerPoint document. That is the level at which > you can do network transactions. You can talk about individual slides > using pointers into the slideshow, but that isn't a protocol/networking > issue, because it has resolved completely on the "client side". [...] > I think you've missed an important distinction. If the "car" has a > representation that exposes all of the state of the window then yes, the > window is "on the Web" despite the fact that it does not have its own > URI. It can be addressed through a URI reference (e.g. URI+XPointer) But > if you must POST a message to the car to ask *it* about the state of the > window, then the window has neither a URI nor a URI refrence and it is > not on the Web. If you cannot reference it with a Web address then I > don't think it is on the Web. I'm no Microsoft guru (Actually, I've started using Windows as my primary desktop for the first time, and I'm less than pleased), but from what I've seen there isn't a fragment identifier that can be used to identify a slide in a powerpoint show; the slides are not addressable. If we assume that's the case (PDF is another format that can be substituted for the purposes of this discussion if it's not), one can put a slide on the Web by making its parent slideshow available at a URI. I'd say that a reasonable interpretation of "on the Web" is "available on the Web"; certainly more accurate than "addressable on the Web." Addressability is a very important aspect of the Web, but let's not confuse it with availability. Remember that resources are abstract, while representations are concrete; when you use a URI reference, you're identifying something concrete in the representation, not in the resource. > No. At some point you are no longer interested in sending messages to > objects and I would say that that's the point you stop decomposing. It > isn't a judgement call. If you need to address something in a network > transaction then the thing needs a URI. Determining your level of interest in something isn't a judgement call? > > Back to SOAP (and hopefully a bit closer to reality), it's up to you as to > > what you expose in the URI interface. If you want it to be interoperable > > with applications that need to reference different subresources, that > > would indicate the use of separate URIs. You can do this in any Web > > Services environment; the only question is how much pain you have to put > > up with to give different services different URIs. > > Could you describe how to do this in any web service environments you > are familiar with? Remember that an important requirement is that new > resources will be created all of the time with no human interaction. I think it was noted before that this information is available in most environments; it's more a question of whether people will use it, and whether they'll be encouraged to use it. I'm somewhat hopeful that progress can be made here.
Paul, thanks for the well-reasoned reply. My followup comments interspersed. A little clarification on where I'm coming from first, though: I'm not trying to sell the REST gang on ebXML. Yes, I worked on ebXML, but I have been trying to solve the problem of freely-associating economic agents for years. Working with ebXML was just one learning experience. Working with REST is another. I do think the RosettaNet-ebXML transaction model is RESTifiable, though, which is why I suggest it. Database transaction models are clearly not appropriate. I also think the next direction that the UN/CEFACT business process gang went in is also RESTifiable. It could resolve to using published resource state as an orchestration mechanism, which I think was the same direction as you have been going in casting state machines into hypertext form. Paul Prescod wrote: > Okay, let's first define transactions in the context of this discussion > because people often mean different things. You do not mean transaction > in the sense of requiring "a group of operations on (distributed) > resources be treated as one unit of work. In a unit of work, all the > participating operations should either succeed or fail and recover > together." Oh, but I *do* mean a unit of work, in the sense of two trading partners coming to agreement on advancing a business deal to the next state. Each business transaction succeeds or fails as a whole. But they are only trying to agree on whether or not to advance to the next state. Any database transactions are each partner's purely private matter. I would not do my private database updates until the shared transaction completed, so no rollback or recovery would be necessary. For an Order, the transaction is Offer-Acceptance. At the end of the transaction, the order will be either accepted or not (it was either rejected or the transaction failed for technical reasons). To be accepted, both trading partners must agree explicitly and auditably. > Rather you mean transaction in the business sense, which is an agreement > to exchange services, products or money. In a typical order, there are at least three business stages: *order *delivery of goods or services *payment (not necessarily in that order, cd be prepay). If all three stages are performed electronically, there will be at least three business transactions: *Order - Offer-Acceptance, which we've been discussing. *Delivery and Payment - Notify-Confirm, where one partner notifies the other that the economic event happened, and the other partner confirms that yes it did happen as notified (or it doesn't agree, in which case they need to go into a problem resolution process, which could be another electronic transaction or a phone call or whatever). > Now thinking about this from an XP perspective, I want to think about > the simplest thing and see why it won't work. The simplest thing is for > me to send you an "offer" message and you reply with "accept" or > "decline". That's not good enough, however, because deciding whether to > accept may take a long time. So it is necessary for the exchange to be > broken into two parts: "request service" and then at some indeterminate > time later, "provide response". In other words there are four messages: Exactly. That's why I think this transaction model is about the simplest thing that will work in situations where there is a lag. > bhaugen32 wrote: > > It's a two-party request-response interaction, with receipt > > acknowledgements for both request and response. > > "Can we do business?" > "I acknowledge that you want to do business. I will get back to you." > "I agree/disagree we should do business." > "I acknowledge your agreement/disagreement." Beautiful recap, you nailed it! > > There are time constraints on each step. If any timeout occurs, the > > transaction fails with a Control Failure. > > Note that in the absence of reliable transport it is still possible for > the businesses to end up misaligned. An HTTP-based solution needs to use > HTTP in a manner that will ensure reliability. Yes. > > In cases where the Response document says "Accept" but has an error, > > and the error message from the requesting business service cannot be > > delivered, the transaction model specifies a separate Notification of > > Failure to be sent from the requesting business service via another > > channel. Otherwise the responding activity may think incorrectly > > that the transaction succeeded. > > I see, so otherwise it is to assume the transaction succeeded if it > returns an Accept, whether it gets a receipt or not? Well, it would be a bad assumption, but the end state is ambiguous, and ambiguities are what sometimes end up in court. > > RosettaNet and ebXML assume that a business service access point will > > handle many transactions for many business activities, so each > > message contains tags for dispatching to the business collaboration > > (long conversation about the Order), business transaction, and > > business activity. > > You'll have to describe why all of these levels of statefulness are > necessary. And if you want to represent them in REST then you should > give them all URIs and point to them. I'm describing the complex dispatching as a bad example, something I would prefer to avoid. (I hope that was clear...) > > If the resource is the Order, then only the business transaction and > > business activity tags are required. > > If the resource is the Transaction, then the business activity can be > > assumed. > > Sounds stateful. Better to use references. I agree. > > In either case, I think the REST style is functionally equivalent to > > the EDI-mailbox style, but has at least two advantages: > > Before I feel comfortable that this has been expressed in a REST style, > I'd like to see some URIs, XML and HTTP methods. ;) > > I propose that what you will need is at least two HTTP request/response > pairs, one in each direction. To get reliability, though, you probably > actually need four, as I discuss here: > > * http://www.prescod.net/reliable_http.html > > So you would > -> POST: "I'd like to make an offer" > <- OK, here's an offer-holder URI > -> PUT the offer at offer-holder URI > <- OK, I've received it and will get back to you Ok, I read your Reliable HTTP article and think I agree. > The offer should have a callback address, unless you are using something > like HTTP events. Either way, > > <- POST "I'd like to return a reliable offer-response" > -> OK, here's an offer-response-holder URI > <- PUT the offer-response at the holder-URI > -> OK, I've got the offer-response Couldn't you just send the offer-response-holder URI with the offer? So do you think this has promise as a REST transaction protocol? (Are you still having trouble thinking of it as a transaction?) Thanks again, Bob Haugen
Mark Nottingham wrote: > >... > > I'm no Microsoft guru (Actually, I've started using Windows as my primary > desktop for the first time, and I'm less than pleased), but from what I've > seen there isn't a fragment identifier that can be used to identify a > slide in a powerpoint show; the slides are not addressable. I believe that there is a fragment identifier syntax for both PowerPoint and PDF but it is neither here nor there. As long as the bits you want are sent across the network when you do an HTTP GET then the information is "on the web" and an appropriate fragment identifier *could be worked out* either globally or for a particular application. That means that it is no longer a protocol issue, it is an application software issue. A Web protocol has a responsibility to turn an address into bits and the rest is up to the client. > If we assume that's the case (PDF is another format that can be > substituted for the purposes of this discussion if it's not), one can put > a slide on the Web by making its parent slideshow available at a URI. I'd > say that a reasonable interpretation of "on the Web" is "available on the > Web"; certainly more accurate than "addressable on the Web." Let's presume that's true. What if I give you a URI to Java applet that implements the telnet or SSH protocols? Can I now declare that my /etc/passwd is "on the web" because all you need to do is send the right commands (machine name, username, password, cat /etc/passwd) to the Java applet? In my opinion, that definition is too vague to be useful. Using URI-addressability as the definition is crisp and helpful. If there exists a URI that addresses a resource that returns a representation that contains the bits then those bits are on the Web. Otherwise, not. > Addressability is a very important aspect of the Web, but let's not > confuse it with availability. Remember that resources are abstract, while > representations are concrete; when you use a URI reference, you're > identifying something concrete in the representation, not in the resource. I agree but don't understand the relevance. > > No. At some point you are no longer interested in sending messages to > > objects and I would say that that's the point you stop decomposing. It > > isn't a judgement call. If you need to address something in a network > > transaction then the thing needs a URI. > > Determining your level of interest in something isn't a judgement call? My point is that there is a simple rule of thumb for determining whether you've got the granularity right or not. If you need to send a message to something then that thing should have an address. This issue is not one that is particularly confusing in (e.g.) object oriented programming and it shouldn't be in networking either. >... > > Could you describe how to do this in any web service environments you > > are familiar with? Remember that an important requirement is that new > > resources will be created all of the time with no human interaction. > > I think it was noted before that this information is available in most > environments; it's more a question of whether people will use it, and > whether they'll be encouraged to use it. I'm somewhat hopeful that > progress can be made here. I may have missed this note. Here's what I remember: A few weeks ago Sam Ruby pointed me to a few Axis documents that I couldn't interpret. Yesterday, Mike Dierken said: "my guess is that it is pretty easy to route HTTP requests to HTTP handlers based on a URI pattern" and "If you did route this way - via common HTTP URI based handling - then the SOAP receiver probably won't be coded to know the HTTP URI - the info would have to be replicated within the SOAP body." Which in my mind defeats the whole purpose. The SOAP elements are still the canonical address for the referenced object, not the URI. The URI is more or less ignored. Paul Prescod
Joe Hsy wrote:
> I think one of the fundamental advantages of RESTful thinking
> is that it allows you make closer to a run-time decision. In
> other words, you don't need to rewrite an application, you can
> simply choose to expose something later or hide something
> as your needs change or the needs of you partners change.
Wow! This is a really interesting idea. Let me see if I understand
your idea. I work best with a concrete example, so let's consider the
fictitious company, Parts Depot, Inc. One of the services it has
deployed is a service to enable clients to get detailed info about a
specific part. For example, if the client is interested in part 00345
this is the URI that it would use:
http://www.parts-depot.com/parts/00345
Here's a representation for that Part 00345 resource:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>
This part is used within the frap assembly
</Description>
<Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>0</Quantity>
</p:Part>
As you can see, at the moment Parts Depot is out of Part 00345 [Note
that <Quantity> is 0].
In those cases where a part is out of stock Parts Depot may wish to
additionally provide a URL to a shipping schedule of that part as a
courtesy to its clients. For example, rather than sending the above
document, this one is sent:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>
This part is used within the frap assembly
</Description>
<Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>0</Quantity>
<ShippingSchedule
href="http://www.parts-depot/parts/00345/shipping-schedule"/>
</p:Part>
Note the new element, <ShippingSchedule href="..."/>
Thus, the shipping-schedule resource is exposed when the <Quantity> is
0, and hidden otherwise.
Is this the kind of scenario that you are envisioning? If so, I have
some questions:
1. In actuality, wouldn't Parts Depot need to deploy the
shipping-schedule resource at design time? Isn't the only run-time
aspect of this scenario the decision of whether or not the URL to the
shipping-schedule resource is to be provided within the Part document?
2. If the answer to (1) is "yes", then couldn't this also be done using
SOAP?
Interesting idea! I look forward to your thoughts (to everyone's
thoughts)! /Roger
"Roger L. Costello" wrote: > > I am having a debate with a colleague. I am arguing that when SOAP is > used you POST to the SOAP server, and it then looks inside the SOAP > message to determine which application to delegate to. http://radio.weblogs. com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html - Sam Ruby
Here is some reasoning in favor of a "unilateral submit" idea, and abandon the idea of scripting business processes. http://www.gldialtone.com/UEEN.htm That is, an assumption that the electronic environment is a completely cynical, untrusted game environment, but knowing that there are good, real businesses and people behind the crappy software, we try diligently to execute sales and purchases. Whatever Individuals and SMEs end up buying, will need to be *very* simple to deal P2P with other I/SMEs. Enterprises obviously are getting better functionality than that with EDI already. But E's will reap economic benefits with each electronic exchange by individuals if it can be understood. I am advocating that E's deliberately downshift from 4th gear and try to speak in plain, simple, horizontal messages to SMEs. There are at least 5 major problems with highly orderly Business Process choreography, for SMEs. 1. I/SMEs constantly change their behavior and kinds of terms more dynamically and flexibly than Enterprise and their cost of maintaining BP templates would be too high. The economic payoff from BP choreography (granular state alignment) is greatest when you have high volume of similar transactions. I/SMEs are often the opposite. 2. Individuals and SMEs have so much role compression that the same person often does most, or all, of customer service has no need for any explicit, realtime computer record of the business state of the collaboration or transaction. So, they're simply not going to sit and maintain granular diary of everything in a computer--Not now, not ever. 3. most of the Simple Examples, POCs, and implementations for ebXML BP are about supply chain for products or materials. The fraction of I/SMEs in services is so high that *no* BP solution can reach critical mass (viability) unless it wins adoption from services people. In other words, BP standards organizations should admit they have not much to offer services collaborations, and, perhaps start with a core functionality around simple communication, billing and reconciliation of AR and AP that is needed both by services as well as product businesses. (BP standards bodies are, instead, abandoning SMEs and sticking to their Enterprise spaces, afaics, which dooms their standard to niche status.) 4. Strategic. By cooperating in supply chains dominated by trillion-dollar corporations, the SME becomes truly a cog in a machine, bidding against workers in Bangladesh. Knowing this, many businesses deliberately misbehave and avoid adoption, especially since ebXML doesn't let them buy/sell from their own neighbors or other SMEs, at first. 5. The biggest problem with highly engineered, granular BP specifications is that they cannot succeed without a compliant application on each end. Even if the other party tells you their app is compliant it could be noncompliant or could fail. Particularly during the early adoption phase, the level of reliability will not be too impressive. So, the thinking behind my suggestion is forget about changing others behavior and just send them carbon copies of whatever recordkeeping we are actually posting in our own computer, about them. If they figure it out then fine. If not, then, fine. http://www.gldialtone.com/UEEN.htm I have deliberately written this in advocacy mode. I realize there are two sides to every story but feel these points are getting ignored by all the Business Process standards bodies and I'm "mad as hell and won't take it anymore"... I want something simple enough to be understood by 6 billion people, to be adopted, making millions of full-time bookkeeping positions as obsolete as telephone operators, and which doesn't transfer economic or strategic advantage to Giant Enterprises. Respectfully, Todd =====================Quote material follows At 05:16 AM 6/8/02, bhaugen32 wrote: .... > So you would > -> POST: "I'd like to make an offer" > <- OK, here's an offer-holder URI > -> PUT the offer at offer-holder URI > <- OK, I've received it and will get back to you Ok, I read your Reliable HTTP article and think I agree. > The offer should have a callback address, unless you are using something > like HTTP events. Either way, > > <- POST "I'd like to return a reliable offer-response" > -> OK, here's an offer-response-holder URI > <- PUT the offer-response at the holder-URI > -> OK, I've got the offer-response Couldn't you just send the offer-response-holder URI with the offer?
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Wow! This is a really interesting idea. Let me see if I understand
your idea. I work best with a concrete example, so let's consider the
fictitious company, Parts Depot, Inc. One of the services it has
deployed is a service to enable clients to get detailed info about a
specific part. For example, if the client is interested in part 00345
this is the URI that it would use:
http://www.parts-depot.com/parts/00345
<http://www.parts-depot.com/parts/00345>
< ...>
Is this the kind of scenario that you are envisioning? If so, I have
some questions:
1. In actuality, wouldn't Parts Depot need to deploy the
shipping-schedule resource at design time? Isn't the only run-time
aspect of this scenario the decision of whether or not the URL to the
shipping-schedule resource is to be provided within the Part document?
Yes, this is one example of what I was thinking. My basic thought is that
if we can design applications where every resource/object is intrinsically
URL-addressable, it makes it much easier to make changes later which
involves deciding what to hide and what to expose.
In order to make this feasible, we need a development environment where
URL-addressability for any object or resource is a built-in feature of the
system and not something that needs to be consciously decided by the
programmer. This is what I was thinking when I suggested that we create a
full-blown distributed OOP development environment that supports REST
intrinsically.
It also allows a business/operations to make decisions on what resources to
expose and what resources need additional security to be accessed without
needing to go back to the developer.
2. If the answer to (1) is "yes", then couldn't this also be done using
SOAP?
I actually think SOAP is in many ways tangential to this idea. SOAP is
concerned with defining methods of objects/resources and does not deal with
the addressaebility of objects/resource. In fact, URIs are what most
current SOAP implementations use for addressing. The fact that people talk
about SOAP over SMTP and leveraging email addresses shows that SOAP is not
concerned with this issue at all.
Where SOAP falls down is that it encourages what I call "passing by value".
When SOAP returns something, it typically returns the actual values as
defined by the method description. However, there is no reason that it
can't return the URIs of the desired resources (pass by reference) instead
of the value or in additional to the value. It is simply not enforced nor
encouraged.
This is where REST-oriented thinking helps. It encourages the developer to
think in terms of URIs and exposing them as the situation warrants. It also
implements the universal addressability method calls (GET, PUT, POST,
DELETE) for these URI-addressable objects.
I think what would make REST really concrete to most people as a development
methodology is to have an environment and tool set that is extended from a
well-understood development environment. I would like to suggest that java
and C++ can be extended to make URI-addressability an intrinsic part of
being an object and that this one simple capability would allow people to
program in a more RESTful way much more quickly.
On the other hand, I think SOAP is a more explicit way to define methods
calls of objects than the currently available set of REST tools. And if we
add "passing by reference" as a first level concept into SOAP, I believe it
can still play a useful role in such a REST-OOP system. What I mean by this
is that we can make it the default to return URIs for a method call unless
explicitly specified to be "pass by value". We can then return the object
value when we explicitly perform the "GET" call. By making URIs the core
result-passing (or when applicable, parameter passing) mechanism in the SOAP
protocol, I think it can become much more RESTful.
//Joe
This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
Joe Hsy wrote: > In order to make this feasible, we need a development environment > where URL-addressability for any object or resource is a built-in > feature of the system and not something that needs to be consciously > decided by the programmer. This is what I was thinking when I > suggested that we create a full-blown distributed OOP development > environment that supports REST intrinsically. Isn't the idea of REST that URIs identify "resources", i.e., logical entities? Whether the resource is implemented as an object or some other form is transparent. Consequently, the implementation of the resource can change without impacting clients. I don't really equate "objects" with "logical entities". There are many ways to implement a logical entity without the use of objects, e.g., a logical entitiy could be implemented simply as an XML document, or as the results of a database query. I see these two statements as being very different: Object-based: We need a development environment where URL-addressability for any **object** is a built-in feature of the system. Resource-based: We need a development environment where URL-addressability for any **resource** is a built-in feature of the system. I agree with the later, but not the former. /Roger
Joe, Roger, The RESTful toolkit that I recently announced I'm developing is designed to do the important parts of what both of you are saying. Joe, I think it's wrong to program every object in an application as URI-addressable. Only the ones that should be network-accessible. And I think Roger's resource-based classification is more suitable to REST than the object-based one, and it better represents what I have designed into my toolkit. For example, in addition to regular HTML content, core resources built into the toolkit are nodes, containers, components, methods, topics, and queues. I have implemented them as objects, but in essence they are better represented as resources. Since the toolkit is developed in C++, every object has the abiliity to subclass from a CObject class, which provides the built-in functionality you refer to below. It not only implements URI addressability, but also a facility for serializing a snapshot of the state of any resource into an XML stream to be transmitted in response to a GET request. Combine these features with environmental acquisition and you've got a great development environment to work in. This isn't a sales pitch....it will be free for developers, and I hope it helps make REST a better philosophy for programming distributed apps than RPCs. -Philip -----Original Message----- From: Roger L. Costello [mailto:costello@...] Sent: Monday, June 10, 2002 8:05 AM To: rest-discuss@yahoogroups.com; costello@... Subject: [rest-discuss] RE: Dynamic exposing/hiding of Web resources! Joe Hsy wrote: > In order to make this feasible, we need a development environment > where URL-addressability for any object or resource is a built-in > feature of the system and not something that needs to be consciously > decided by the programmer. This is what I was thinking when I > suggested that we create a full-blown distributed OOP development > environment that supports REST intrinsically. Isn't the idea of REST that URIs identify "resources", i.e., logical entities? Whether the resource is implemented as an object or some other form is transparent. Consequently, the implementation of the resource can change without impacting clients. I don't really equate "objects" with "logical entities". There are many ways to implement a logical entity without the use of objects, e.g., a logical entitiy could be implemented simply as an XML document, or as the results of a database query. I see these two statements as being very different: Object-based: We need a development environment where URL-addressability for any **object** is a built-in feature of the system. Resource-based: We need a development environment where URL-addressability for any **resource** is a built-in feature of the system. I agree with the later, but not the former. /Roger
Hi Roger, Philip, I agree with both your messages. I may have mistakenly given the impression that I was advocating a specific way of extending OOP as *the* model of implementing REST. There are certainly other equally fine ways and it isn't necessarily to treat resources as objects. I was merely suggesting that if I want to program in a OOP environment, having such extensions would make creating a RESTful application much easier. And I would have the benefit of pushing the hide/expose decisions to much later in the development cycle. From Philip's description of his toolkit, I think it is the very type of extension that would be very useful. I would love to see it! It may never be necessary to make all objects URI-addressible or to make URI-addressing a "first-class" concept in a language, but I think if we take it to that extreme, there may be some interesting ways to leverage this capability. Some additional challenges for such a environment include the concept of the life-span or pemanence of objects. There may also be issues regarding defining some standard form for URIs that are auto-generated in such a system. I've not fully thought this through but I think it could be an interesting exercise. 8-) //Joe -----Original Message----- From: Philip Eskelin To: rest-discuss@yahoogroups.com Cc: 'Roger L. Costello'; joe.hsy@... Sent: 6/10/2002 7:21 AM Subject: RE: [rest-discuss] RE: Dynamic exposing/hiding of Web resources! Joe, Roger, The RESTful toolkit that I recently announced I'm developing is designed to do the important parts of what both of you are saying. Joe, I think it's wrong to program every object in an application as URI-addressable. Only the ones that should be network-accessible. And I think Roger's resource-based classification is more suitable to REST than the object-based one, and it better represents what I have designed into my toolkit. For example, in addition to regular HTML content, core resources built into the toolkit are nodes, containers, components, methods, topics, and queues. I have implemented them as objects, but in essence they are better represented as resources. Since the toolkit is developed in C++, every object has the abiliity to subclass from a CObject class, which provides the built-in functionality you refer to below. It not only implements URI addressability, but also a facility for serializing a snapshot of the state of any resource into an XML stream to be transmitted in response to a GET request. Combine these features with environmental acquisition and you've got a great development environment to work in. This isn't a sales pitch....it will be free for developers, and I hope it helps make REST a better philosophy for programming distributed apps than RPCs. -Philip -----Original Message----- From: Roger L. Costello [mailto:costello@...] Sent: Monday, June 10, 2002 8:05 AM To: rest-discuss@yahoogroups.com; costello@... Subject: [rest-discuss] RE: Dynamic exposing/hiding of Web resources! Joe Hsy wrote: > In order to make this feasible, we need a development environment > where URL-addressability for any object or resource is a built-in > feature of the system and not something that needs to be consciously > decided by the programmer. This is what I was thinking when I > suggested that we create a full-blown distributed OOP development > environment that supports REST intrinsically. Isn't the idea of REST that URIs identify "resources", i.e., logical entities? Whether the resource is implemented as an object or some other form is transparent. Consequently, the implementation of the resource can change without impacting clients. I don't really equate "objects" with "logical entities". There are many ways to implement a logical entity without the use of objects, e.g., a logical entitiy could be implemented simply as an XML document, or as the results of a database query. I see these two statements as being very different: Object-based: We need a development environment where URL-addressability for any **object** is a built-in feature of the system. Resource-based: We need a development environment where URL-addressability for any **resource** is a built-in feature of the system. I agree with the later, but not the former. /Roger To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Paul Prescod wrote: > >>> Could you describe how to do this in any web service environments you >>> are familiar with? Remember that an important requirement is that new >>> resources will be created all of the time with no human interaction. >> >> I think it was noted before that this information is available in most >> environments; it's more a question of whether people will use it, and >> whether they'll be encouraged to use it. I'm somewhat hopeful that >> progress can be made here. > > I may have missed this note. > > Here's what I remember: A few weeks ago Sam Ruby pointed me to a few > Axis documents that I couldn't interpret. http://groups.yahoo.com/group/rest-discuss/message/1291 > Yesterday, Mike Dierken said: "my guess is that it is pretty easy to > route HTTP requests to HTTP handlers based on a URI pattern" and "If you > did route this way - via common HTTP URI based handling - then the SOAP > receiver probably won't be coded to know the HTTP URI - the info would > have to be replicated within the SOAP body." > > Which in my mind defeats the whole purpose. The SOAP elements are still > the canonical address for the referenced object, not the URI. The URI is > more or less ignored. I disagree. http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html - Sam Ruby
Sam Ruby wrote: > >... > > Here's what I remember: A few weeks ago Sam Ruby pointed me to a few > > Axis documents that I couldn't interpret. > > http://groups.yahoo.com/group/rest-discuss/message/1291 If I have to read the source code to figure out how to do it then I'd have to say it is "not really supported." >... > > I disagree. > > http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html You haven't addressed the real-world, concrete problem of building a web service where every purchase order has its own URI. What does that look like with an Axis client. What does it look like with an Axis server. What does the WSDL look like? Everybody is pointing out that this is possible in theory but nobody has sat down to document how to do this in practice. It isn't a matter of convincing REST advocates that SOAP is RESTful. It's more a matter of bolstering the claim of SOAP advocates that SOAP can use the Web as more than a transport pipe *in practice*. Paul Prescod
bhaugen32 wrote: > > Paul, thanks for the well-reasoned reply. > My followup comments interspersed. > > A little clarification on where I'm coming from first, though: > I'm not trying to sell the REST gang on ebXML. > Yes, I worked on ebXML, but I have been trying to solve the problem > of freely-associating economic agents for years. Working with ebXML > was just one learning experience. Working with REST is another. I think that it is very important to have people working from the top down, starting with business requirements. Really there should be more people working on that end rather than on the plumbing but it is easier to get your head around plumbing. >... > Oh, but I *do* mean a unit of work, in the sense of two trading > partners coming to agreement on advancing a business deal to the next > state. Each business transaction succeeds or fails as a whole. Okay, but people often mean transactions in this sense: "I want to be able to take an arbitrary number of state-changing operations and ensure that the succeed or fail as a single operation." For example: PUT X PUT Y POST Z PUT A POST B "But only do ANY of these things if you can guarantee ALL will succeed." This is tricky in distributed systems because it requires that the server trust that the client will not lock up too many resources and then disappear. >... > For an Order, the transaction is Offer-Acceptance. At the end of the > transaction, the order will be either accepted or not (it was either > rejected or the transaction failed for technical reasons). To be > accepted, both trading partners must agree explicitly and auditably. Agree. >... > > Couldn't you just send the offer-response-holder URI with the offer? Good idea! > So do you think this has promise as a REST transaction protocol? I see it as a REST offer-acceptance protocol. But in what sense is it "transactions in general" and what exact definition of "transactions" are you using? Is there a way we could avoid that word so as not to confuse people? Paul Prescod
Paul, I'm gonna switch the sequence of your comments around a little. Paul Prescod <paul@p...> wrote: > I see it as a REST offer-acceptance protocol. But in what sense is it > "transactions in general" and what exact definition of "transactions" > are you using? Is there a way we could avoid that word so as not to > confuse people? Actually, I like using the word "transaction" in this case. Database people took the word from business in the first place. And then narrowed the definition something awful. I think it's acceptable to consider other protocols besides 2-phase commit to be transactions. Even in business, the word has several meanings. The phrase I used is "state-alignment transaction". Which means that at the end of the transaction, both parties must agree on whether the transaction succeeded or not. I think that's all you can do with a simple Internet interaction, although I'm always ready to be proved wrong. The sense in which it is a transaction-in-general is that it is an atomic unit of work. The relationship between state-alignment transactions and database transactions is that the state-alignment transaction operates in the shared space of the Internet, but any database transactions are the private and protected business of each of the trading partners. More on database updates below. > > Oh, but I *do* mean a unit of work, in the sense of two trading > > partners coming to agreement on advancing a business deal to the next > > state. Each business transaction succeeds or fails as a whole. > Okay, but people often mean transactions in this sense: "I want to be > able to take an arbitrary number of state-changing operations and ensure > that the succeed or fail as a single operation." > > For example: > > PUT X > PUT Y > POST Z > PUT A > POST B > > "But only do ANY of these things if you can guarantee ALL will succeed." > This is tricky in distributed systems because it requires that the > server trust that the client will not lock up too many resources and > then disappear. Exactly. RosettaNet went through this same conversation we (and W3C) are having now in early 1999. They started out trying to do 2-phase commit over the Internet and found it was a very bad idea. Then they came up with the state-alignment transaction protocol by studying the UNECE and ABA requirements again. The idea is that all the tricky database updates listed above should be done in somebody's private and protected space. For example, in the offer-acceptance transaction, the responding party may need to do a lot operations before coming back with an acceptance. If any of those operations fail, the responding party must reject the offer. In other words, all you can do (and all you usually need to do) in the shared space is synchronize two parties at a time. If you have a situation like the travel agent, where many legs of a trip must be booked, you need something like a temporary hold. In fact, the travel industry provides such a feature. You can put reservations on hold for e.g. 24 hours and assemble the legs of the trip and ask the traveler to approve it, and then go back and book everything. They provided the feature for the same kinds of reasons it is useful in an Internet business conversation: you're crossing administrative boundaries. I mean, that is one of the limitations of this kind of transaction protocol. I think if you really need to synchronize more than two activities at the same time, you need something more complex. But you will pay for it. On the other hand, I have had conversations with accountants and lawyers who say that well-formed business contracts have the same characteristic: however many parties may be involved, all commitments can and should be broken down into two-parties. Thanks again for the dialog, Bob Haugen
> ----- Original Message ----- > From: Sam Ruby > > > > Which in my mind defeats the whole purpose. The SOAP elements are still > > the canonical address for the referenced object, not the URI. The URI is > > more or less ignored. > I disagree. > http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess .html The summary for those who like reliability through replication: -- Conclusion In order to correctly and interoperably access a SOAP service, a client must specify three pieces of information in order to identify the object to be accessed. Correspondingly, in order for a web service to be published, all three pieces should be specified. A given service implementation may chose to ignore or validate any of these data.
"S. Mike Dierken" wrote: > > > ----- Original Message ----- > > From: Sam Ruby > > > > > > > Which in my mind defeats the whole purpose. The SOAP elements are still > > > the canonical address for the referenced object, not the URI. The URI is > > > more or less ignored. > > > I disagree. Mike, I know you didn't write any of this but you did write the statement that started the whole debate was that you could use HTTP dispatching to dispatch based on URI and then have the addressing information redundantly stored in the SOAP message for a SOAP processor. I couldn't state clearly why I thought this was not helpful but now I can. Let's say you are trying to write "update bank account" and it takes a bank account number and an amount of money. The REST argument is that you should use standards as much as possible. So you want to use a standard addressing mechanism, standardized method names/semantics and, if possible, a standardized information representation. The reason we use standards is to minimize the amount of a priori knowledge necessary to invoke a service. Moving addressing information like "which account number" from the SOAP body to the URI reduces the amount you have to know to work with a bank account. Someone can just hand you a URI and you don't even need to know that bank accounts or numbered, or that savings accounts and chequing accounts form different namespaces or that the bank has two subsidiaries with their own numbering system or ... It's all one namespace. If you must put the information both in the SOAP body and the URI then we've *increased* the amount of a priori knowledge required. Now you have to know to do X *and* Y. Sam's URI demonstrates that even without this extra burden, SOAP already requires you to jump through many "a priori knowledge" hoops. To invoke the right operation you must know: * whether or not there is a SOAPAction. * if there is, what it's value is (there are a variety of conventions) * what namespace to use for the operation element * what element type to use for the operation * what endpoint URI to use And some of these are only applicable to the HTTP transport so if you are using another transport then you have other magic cookies to provide. I've never heard why SOAP needs so many magic incantations when XML-RPC gets away with URI and method name and you could move even the method name into the URI (whether or not you believe in REST). But if you moved the method name into the URI then SOAP would be a web-centric protocol instead of a protocol that uses the Web as a transport. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > Mike, I know you didn't write any of this but you did write the > statement that started the whole debate was that you could use HTTP > dispatching to dispatch based on URI and then have the addressing > information redundantly stored in the SOAP message for a SOAP processor. Actually it was RogerC that started the discussion. > For example, if a company has deployed three Web services then despite which Web service > a client wishes to invoke, the URI will always be the same, for example: [...] > My colleague argues that this is not true. He says that a client can > provide the URI directly to the target Web service (resource), [...] > "We were able to have 2 web services on the same machines with different > URI, using WebLogic." > I haven't used WebLogic, so I can't verify his statement. > Can someone settle this debate please? I was pointing out that most HTTP servers have configuration capabilities that make it easy to target the same internal HTTP handler for many different URI - which was the question of the original message. The question looked to me like "Can I have two SOAP listeners on the same web server at two different URI?" I also pointed out that replicating the URI to within the SOAP message (either header or body) would be necessary. I didn't say it was a good idea or that it should be done this way, but rather that it would be required to work at all. But what I should have said was that it would only be necessary if the URI were fine-grained and pointed to a resource to operate on rather than a service. If the URI referenced the soap service itself, then that particular URI wouldn't need to be part of the soap message. Any data needed for the operation would already be bundled in the message, but then we get into the whole non-addressable data issue.
----- Original Message ----- From: "Paul Prescod" <paul@...> > But if > you moved the method name into the URI then SOAP would be a web-centric > protocol instead of a protocol that uses the Web as a transport. I wouldn't go so far as to call it 'web-centric' - perhaps web-friendly because the URI is important, but it still doesn't use standardized/minimal methods. > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> > Will You Find True Love? > Will You Meet the One? > Free Love Reading by phone! And what's with all this Free Love stuff you keep sending me?
My boss just gave me the go-ahead to investigate REST as the architectural framework for our middle-tier. I was wondering if it would be OK to post some of my thoughts for how REST might be utilized in our domain (a hospital information system). After mostly lurking on the list for a few months, I think I have a good grasp of what makes an archiectecture RESTful or not but would love to get some input from those wiser than I. Thanks, Jason
"S. Mike Dierken" wrote: > >... > But what I should have said was that it would only be necessary if the URI > were fine-grained and pointed to a resource to operate on rather than a > service. If the URI referenced the soap service itself, then that particular > URI wouldn't need to be part of the soap message. Any data needed for the > operation would already be bundled in the message, but then we get into the > whole non-addressable data issue. Right. I think that we're in violent agreement. You can use any URI to talk to a SOAP service but unless your SOAP toolkit can extract information from the URI the way an HTTP toolkit can, then you haven't solved the addressability problem. You still need to encode the addressing data in the SOAP message in some service-specific fashion. Paul Prescod
Hmm. Would actually including the link to my notes help? http://www.injektilo.org/REST.html ----- Original Message ----- From: "Jason Diamond" <jason@...> To: <rest-discuss@yahoogroups.com> Sent: Tuesday, June 11, 2002 7:10 PM Subject: [rest-discuss] a RESTful architecture? > My boss just gave me the go-ahead to investigate REST as the architectural > framework for our middle-tier. I was wondering if it would be OK to post > some of my thoughts for how REST might be utilized in our domain (a hospital > information system). After mostly lurking on the list for a few months, I > think I have a good grasp of what makes an archiectecture RESTful or not but > would love to get some input from those wiser than I. > > Thanks, > Jason
----- Original Message ----- From: "Paul Prescod" <paul@...> > > Right. I think that we're in violent agreement. Hey - you may be violent, I'm only looking to Find True Love or get a Free Love Reading by phone! I suppose that would be reachable via: GET phone:FreeLoveReading HTTP/1.1 Host: sponsor.yahoo.com You know... putting non-http protocols in the Request-URI really has some amazing potentials... > ------------------------ Yahoo! Groups Sponsor ---------------------~--> > Will You Find True Love? > Will You Meet the One? > Free Love Reading by phone!
----- Original Message ----- From: "Jason Diamond" <jason@...> > Hmm. Would actually including the link to my notes help? > > http://www.injektilo.org/REST.html > Only if you think hypertext is the engine of application state.
----- Original Message ----- From: "Jason Diamond" <jason@...> > > http://www.injektilo.org/REST.html > > Each patient in these representations will link to an actual patient resource that might look like this: > http://server/CliniVision/MPC.aspx/patients/01234567-89AB-CDEF-0123-456789AB CDEF > (Yes, we use UUIDs to identify all of our objects.) If each object has a long-lived, persistent reference, then the URI doesn't have to be 'patients/UUID' it can just be 'UUID'. The trick with that is that you have to retrieve the object before knowing what type it is if you want to provide a representation. Another issue is what happens if a user replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient. (you are going to make doctors into numbers too, not just patients, right?) > The reason that the orders for each patient aren't located "beneath" each patient is for the reason that > patients can be merged. That would "move" each order from one patient to the other. > I didn't want the URIs to change. Good thinking. > What I really love about the idea is that each representation could contain an xml-stylesheet PI so that > we could easily traverse the model using IE6 Yeah - cool stuff. I haven't played with this much in the past few years, so I'm not sure what the best way to get 'device independence' - essentially user-agent detection. Should the URI of the XSL return different XSL for different devices? Should there be multiple PIs in the XML? Should the PI in the XML be different for different user-agents? etc...
S. Mike Dierken <mdierken@...> wrote: > If each object has a long-lived, persistent reference, then the URI doesn't > have to be 'patients/UUID' it can just be 'UUID'. The trick with that is > that you have to retrieve the object before knowing what type it is if you > want to provide a representation. You're right. The UUIDs are unique even across "types" of resources. So the patients/ or orders/ "prefixes" aren't really necessary. Since we have to have some URI to list all resources of a given type to start with, I guess I thought that it would make sense to use those URIs as "containers". Of course, since all of these URIs are retrieved via links in representations, it doesn't really matter what they look like as long as they're unique. With regards to your "trick" are you talking about the implementation of the service? I wasn't trying to think that far ahead yet but I think I see what you mean now. If all that's specified is the UUID in the URI, the code implementing the service would need to figure out what table to query into in the database before it can get the information to return a representation. That could be costly. So having the type in the URI makes it easier for the implementation to dispatch to different code for different types of resources (while still being opaque to the client). > Another issue is what happens if a user > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient. > (you are going to make doctors into numbers too, not just patients, right?) Shouldn't you get a 404? > > What I really love about the idea is that each representation could > contain an xml-stylesheet PI so that > > we could easily traverse the model using IE6 > Yeah - cool stuff. I haven't played with this much in the past few years, so > I'm not sure what the best way to get 'device independence' - essentially > user-agent detection. Should the URI of the XSL return different XSL for > different devices? Should there be multiple PIs in the XML? Should the PI in > the XML be different for different user-agents? etc... That's a good idea. Of course, working in a Microsoft-only shop makes this really easy. (But living in a fully standards-compliant world would make it even easier.) Jason
At 03:55 PM 12/06/2002, Jason Diamond wrote:
>http://server/CliniVision/MPC.aspx/patients/new
>When you POST to that URI, it returns the URI of the new patient in the Location header. It will probably look like the patient URI we've already seen
I'm not sure about the /new as it looks suspiciously like a verb and REST resources should be nouns. I'd be tempted to use /patients/schema or /patients/structure on which a GET will return the required fields list (alternatively the list returned from a GET to /patients could include a link to the patients required field structure, see also my ps below). You would then do a POST containing the appropriate data to /patients to create a new patient.
Similarly for /patients/uuid/orders/new and /orders/uuid/activities/new.
I'm a bit confused on the relationship between orders/activities and procedures, as you say :
>Each patient has a list of orders....Each order has a list of activities...
>There can be many different types of orders. Each different type requires different bits of information. We call an order type a procedure.
and later you say:
>This list of orders will contain a link to the page that lists all of the procedures that can be used to create a new order for this type of patient.
I don't understand this sentence at all.
I was thinking you might have the following resource structure:
/orders
on which a GET returns a list of all the available procedures( aka order types)
/orders/procedure1
/orders/procedure2
/orders/procedure3
...
A GET on /orders/procedureN would return the structure of that particular order type, including the activities, i.e.
<order type='procedureN'>
<activities>
<activity type='activity1' mandatory=true>
...add required activity info specification
</activity>
....
</activities>
</order>
Note that you could allow a POST to /orders/procedureN as long as the posted info contained a valid UUID of the patient to add the order to. This would allow you a bit of symmetry in the /orders and /patients URI's.
If activities are always subordinate to orders do you need the separate /activities URI's? Could you use /patients/uuid/orders/uuid or alternatively /patients/uuid/orders/procedureN/activityN to POST the data containing the required activity information?
Robert
PS One thing that has been bothering me in the REST examples I have seen - how are the required formats/structures discovered by the user? For example, in the case of REST-ifying the UserLand XML storage api (http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorageSystem) it says:
"xmlStorageSystem.registerUser()
This method creates a new user account, or updates an existing one on the server. This could quite easily have been done with either an XML document containing this information..."
How do I as a user or a system find out what structure the XML document should be?
Robert Leftwich <robert@...> wrote: > I'm not sure about the /new as it looks suspiciously like a verb and > REST resources should be nouns. I'd be tempted to use /patients/schema > or /patients/structure on which a GET will return the required fields > list (alternatively the list returned from a GET to /patients could > include a link to the patients required field structure, see also my ps > below). You would then do a POST containing the appropriate data to > /patients to create a new patient. Ah. Thanks for pointing that out! I like your approach much better. > I'm a bit confused on the relationship between orders/activities and procedures, as you say : > > >Each patient has a list of orders....Each order has a list of activities... > >There can be many different types of orders. Each different type requires different bits of information. We call an order type a procedure. > > and later you say: > > >This list of orders will contain a link to the page that lists all of the procedures that can be used to create a new order for this type of patient. > > I don't understand this sentence at all. Yeah, it's a little awkward. I probably shouldn't have mentioned the different types of patients since I left out the details about those earlier. A procedure (in our vocabulary) can just be thought of as the schema for an order. In our application, when you create a new order for a patient, you're presented with a list of procedures. The fields that you get to fill in for your new order differ depending on which procedure you chose. > I was thinking you might have the following resource structure: > > /orders > > on which a GET returns a list of all the available procedures( aka order types) > > /orders/procedure1 > /orders/procedure2 > /orders/procedure3 > ... > > A GET on /orders/procedureN would return the structure of that particular order type, including the activities, i.e. > > <order type='procedureN'> > <activities> > <activity type='activity1' mandatory=true> > ...add required activity info specification > </activity> > .... > </activities> > </order> > > Note that you could allow a POST to /orders/procedureN as long as the > posted info contained a valid UUID of the patient to add the order to. > This would allow you a bit of symmetry in the /orders and /patients URI's. Since I wasn't focusing on the vocabulary yet, it hadn't occurred to me that the patient UUID could be in the submitted XML to the generic procedure resources. The type of order (procedure) could also be indicated in the markup like you showed. That avoids the awkward URIs where every procedure has a path under every patient. > If activities are always subordinate to orders do you need the > separate /activities URI's? Could you use /patients/uuid/orders/uuid > or alternatively /patients/uuid/orders/procedureN/activityN to POST > the data containing the required activity information? It's possible that an activity can change it's parent order. This could happen during the merge patient process. If it's determined that two orders for the two patients are the same, the activities from one get moved to the other and the now empty order would get deleted. I know that it sounds a little odd but it occasionally happens that the same patient and/or order gets entered on different disconnected clients and this has to be resolved when the clients reconnect and upload their work back to the server. > PS One thing that has been bothering me in the REST examples I have > seen - how are the required formats/structures discovered by the user? > For example, in the case of REST-ifying the UserLand XML storage api > (http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorag eSystem) > it says: > "xmlStorageSystem.registerUser() > This method creates a new user account, or updates an existing one on > the server. This could quite easily have been done with either an XML > document containing this information..." > > How do I as a user or a system find out what structure the XML document > should be? Even if there was some standard way of obtaining the schema for a service, applications can never really "know" what those elements and attributes "mean". Some understanding between the two parties has to be achieved before you can start making use of it. RDF might change things but until then, I'm resigned to the fact that it's impossible to expect to use a web service (SOAP or REST) without some development effort. Thank you very much for your comments! Jason
I was talking with a colleague this morning and evangelizing REST to him. I was telling him that one of the disavantages of SOAP is that the identity of a target resource is hidden within the SOAP body, as opposed to being clearly shown in the URL [although this is not a requirement of SOAP it is common practice of vendors]. My colleague responded saying that many (if not most) Web applications today use this paradigm of funneling all requests though a single URL. For example, with CGI applications there is only one URL. The CGI code delegates the request to the appropriate application. Likewise, Cold Fusion applications all funnel to the same URL. He said, "go to amazon, you will see that all URLs funnel through obidos" (I checked, he's correct). He stipulated that the majority of the Web is non-RESTful. He also argued that if the REST model does not support this single-URL paradigm then it is not in tune with the "real Web" and therefore REST is merely a figment of Roy Fielding's imagination. Three (very naive) questions: 1. Are his statements about CGI and Cold Fusion correct? 2. Is it true that the majority of the Web is non-RESTful? 3. Should we (the REST evangelists) be arguing against CGI, Cold Fusion, as well as SOAP? /Roger
Hi
On Wed 12-Jun-2002 at 11:14:13AM -0400, Roger L. Costello wrote:
>
> My colleague responded saying that many (if not most) Web applications
> today use this paradigm of funneling all requests though a single URL.
> For example, with CGI applications there is only one URL.
The way the we [1] have got around this is by aliasing / to the CGI, for
example in a Apache httpd.conf file:
Alias / /usr/local/mkdoc/cgi/mkdoc.cgi/
<Directory /usr/local/mkdoc/cgi>
Options ExecCGI
AddHandler cgi-script .cgi
</Directory>
And then we use the PATH_INFO env var to get the /foo/bar/ bit of the URI and
then we can create web sites that appear to be based on a file system but in
reality its all served up from a database.
I don't see why Amazon couldn't alias obidos to / for nicer URIs, but I guess
they are stuck with it now.
Chris
[1] http://mkdoc.com/
--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
everything else http://chris.croome.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Roger L. Costello [mailto:costello@...] > Sent: 12 June 2002 16:14 > To: rest-discuss@yahoogroups.com; Costello,Roger L. > Subject: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web > today mostly non-RESTful? > > > I was talking with a colleague this morning and evangelizing > REST to him. I was telling him that one of the disavantages > of SOAP is that the identity of a target resource is hidden > within the SOAP body, as opposed to being clearly shown in > the URL [although this is not a requirement of SOAP it is > common practice of vendors]. > > My colleague responded saying that many (if not most) Web > applications today use this paradigm of funneling all > requests though a single URL. No, funnelling through a single process maybe. > For example, with CGI applications there is only one URL. > The CGI code delegates the request to the appropriate > application. That's not strictly true. > Likewise, Cold Fusion applications all funnel > to the same URL. He said, "go to amazon, you will see that > all URLs funnel through obidos" (I checked, he's correct). But that's different from using 1 URL to display many resources. Some sites do that, it's a pain (they're often the ones you can't bookmark). Your colleague forget to mention all the stuff appended after obidos. > He stipulated that the majority of the Web is non-RESTful. > He also argued that if the REST model does not support this > single-URL paradigm then it is not in tune with the "real > Web" and therefore REST is merely a figment of Roy Fielding's > imagination. > > Three (very naive) questions: > > 1. Are his statements about CGI and Cold Fusion correct? Partially. You can do CGI that way, but: http: //example.org/cgi-bin/cgi.cgi?resource1 http: //example.org/cgi-bin/cgi.cgi?resource2 go through the same CGI but use 2 URLs. As I understand it, there's nothing wrong with doing this, so long as each resources is addressable. What your colleague describes is sometimes called a front controller in J2EE land. The ultimate front controller is the web server dispatching on http: //example.org. By that line of argument, web servers are not restful. So it's not the funnelling but the addressing thast counts. But if I can get back representations for resources 1 and 2 via a single URL: http: //example.org/cgi-bin/cgi.cgi my understanding is that's not restful. > 2. Is it true that the majority of the Web is non-RESTful? Couldn't say and it depends on whether you're counting URLs or known resources. I doubt if there are more URLs that can return >1 resource representations that there those that return 1. Though it's quite possible that most resources are sharing URLs. > 3. Should we (the REST evangelists) be arguing against CGI, > Cold Fusion, as well as SOAP? I think only if they are used to hide >1 resources behind a single URL. Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPQdtH+aWiFwg2CH4EQJIugCg0aLlQJIzHHH9w3d70z4dKdX+dSkAn1JA MjAu1WM0K/PxxDK6YcY2JK72 =+i+l -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Chris Croome [mailto:chris@...] > > I don't see why Amazon couldn't alias obidos to / for nicer > URIs, but I guess they are stuck with it now. Perhaps it is because Amazon /is/ restful. They're stuck with the problem of throwing away all those resource names. Bill de hra -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPQdtLOaWiFwg2CH4EQLEHQCffprJg2OHV2lkClp+dlqeOI1ciLYAoIWJ US+Q2SQNhof/4pEHLyCUdj4k =SiVQ -----END PGP SIGNATURE-----
"Roger L. Costello" wrote: > >... > > My colleague responded saying that many (if not most) Web applications > today use this paradigm of funneling all requests though a single URL. > For example, with CGI applications there is only one URL. The CGI code > delegates the request to the appropriate application. Likewise, Cold > Fusion applications all funnel to the same URL. He said, "go to amazon, > you will see that all URLs funnel through obidos" (I checked, he's > correct). http://www.amazon.com/exec/obidos/ISBN%3D0136168221/104-7936033-9823945 "obidos" is an implementation detail. What does it matter to a client application that maybe somewhere in the URI is a trigger that launches a CGI or J2EE servlet or whatever? The difference with SOAP is that a typical SOAP service would *stop* at obdios: http://www.amazon.com/exec/obidos/ And then you would specify the rest of the information in SOAP elements like <ISBN>. This means that "obdios" goes from being a trick the server uses to keep track of how to dispatch URIs to something the *client* of the service needs to care about. Now the *client* needs to know to send the ISBN as an element. This means that there is no compact syntax (like a URI) for the resource identified. You have to say something like: "Go to http://www.amazon.com/exec/obidos/and send a message that looks like this: <ISBN>0136168221/104-7936033-9823945</ISBN>" You see the difference? With REST I can send someone to the particular book with a single declarative, globally understood statement. With SOAP I can only *describe* how to *configure* a SOAP client to send the right message to get at the information. One is an address. The other is a list of instructions of how to get to a place. > Three (very naive) questions: > > 1. Are his statements about CGI and Cold Fusion correct? No, Amazon is a wonderful example of CGI used right. > 2. Is it true that the majority of the Web is non-RESTful? There is a lot of the Web that violates REST design criteria in one way or another. Amazon's book URIs are not a good example but it would not take long to find some. That is only an indictment of REST if there is a good reason those people did things in a non-RESTful way. i.e. if REST didn't solve their problems. If it is just the case that they didn't *know* how to use REST right then REST is in the same position as OO programming when C++ was just beginning to become popular. People used OO constructs as structs with methods for years before the paradigm started to seep in. With no REST books, it is actually amazing how RESTful average Web sites are! People rediscovered and reinvented REST before it was named or documented! There is also a lot of the Web that uses REST beautifully. > 3. Should we (the REST evangelists) be arguing against CGI, Cold Fusion, > as well as SOAP? CGI and cold fusion are implementation techniques. SOAP is a protocol. CGI and Cold Fusion can be used to present *any* interface to the client you want. SOAP *defines* the syntax of the messages that the client and server must send. In other words, CGI and Cold Fusion are the languages you speak at home with your kids -- none of my business. SOAP is the language you demand I speak in order to communicate with you. That makes it my business. Paul Prescod
----- Original Message ----- From: "Jason Diamond" <jason@...> > > Another issue is what happens if a user > > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a > patient. > > (you are going to make doctors into numbers too, not just patients, > right?) > > Shouldn't you get a 404? Yes - but I can envision some implementations that do weird things. Your app may not be subject to this though. > > I'm not sure what the best way to get 'device independence' - essentially > > user-agent detection. Should the URI of the XSL return different XSL for > > different devices? Should there be multiple PIs in the XML? Should the PI > in > > the XML be different for different user-agents? etc... > > That's a good idea. Of course, working in a Microsoft-only shop makes this > really easy. (But living in a fully standards-compliant world would make it > even easier.) Even MS-land has different devices - PocketPC, small-screen PCs, the often-promised-never-shipped tablets, etc. Differences between IE4/5/6, etc...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Roger L. Costello [mailto:costello@...] > > I was talking with a colleague this morning and evangelizing > REST to him. I was telling him that one of the disavantages > of SOAP is that the identity of a target resource is hidden > within the SOAP body, as opposed to being clearly shown in > the URL [although this is not a requirement of SOAP it is > common practice of vendors]. Roger, Not unrelated: a doc on URIs and addressing [1] was announced by the tag today. The key bit is: [[[ 1. Relevant Principles of Web Architecture 1. All important resources SHOULD be identifiable by URI. ]]] Bill de hra [1] http://www.w3.org/2001/tag/doc/get7 -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPQd/iOaWiFwg2CH4EQJuwQCg2SYqg4CusP3/Ipxofnogv92bXtgAn2+p hxk5q25b9+aAA5ArbbS7PCaL =ZJrq -----END PGP SIGNATURE-----
----- Original Message ----- From: "Roger L. Costello" <costello@...> > > My colleague responded saying that many (if not most) Web applications > today use this paradigm of funneling all requests though a single URL. As others have pointed out, the single URL isn't that common, but a single request handler is. The query terms are part of the resource identifer. They are not 'parameters to the method' - even though that is a handy mental bridge between the procedural programming world and resource modelling. There might be many sites that DO use a single URL - if you see everything done with POST and other data in form fields - like the identifier in a form field - then that would be an example (and exactly analagous to many SOAP approaches). You wouldn't be able to hit 'refresh' on these pages or bookmark them, which is a pain for end-users, so site designers naturally avoid the 'one URL to rule them all' approach. mike
> Roger, > > Not unrelated: a doc on URIs and addressing [1] was announced by > the tag today. The key bit is: > > [[[ > 1. Relevant Principles of Web Architecture > > 1. All important resources SHOULD be identifiable by URI. > ]]] > > Bill de hra > > [1] http://www.w3.org/2001/tag/doc/get7 Excellent! Related, I just looked at Tim Berners-Lee Web Axioms [2] and it has as its first axioms: Axiom 0: Universality 1 Any resource anywhere can be given a URI Axiom 0a: Universality 2 Any resource of significance should be given a URI. /Roger [2] http://www.w3.org/DesignIssues/Axioms.html
Has anyone put together a set of Best Practices for creating REST
services? If not, how about getting started on one? Here's some that
come to mind:
1. Provide a URI for each resource that you want (or will want)
exposed. This is consistent with Tim Berners-Lee's axioms for the Web,
as well as the W3 TAG recomendations.
2. Prefer URIs that are logical over URIs that are physical. For
example:
Prefer:
http://www.boeing.com/airplanes/747
Over:
http://www.boeing.com/airplanes/747.html
Logical URIs allow the resource implementation to change without
impacting client applications.
3. As a corollary to (2) use nouns in the logical URI, not verbs.
Resources are "things" not "actions".
4. Make all HTTP GETs side-effect free. Doing so makes the request
"safe".
5. Use links in your responses to requests! Doing so connects your
response with other data. It enables client applications to be
"self-propelled". That is, the response itself contains info about
"what's the next step to take". Contrast this to responses that do not
contain links. Thus, the decision of "what's the next step to take"
must be made out-of-band.
6. Minimize the use of query strings. For example:
Prefer:
http://www.parts-depot.com/parts/00345
Over:
http://www.parts-depot.com/parts?part-id=00345
Rationale: it's easier for Web intermedaries such as proxy servers to
evaluate a request when it doesn't need to parse a query string.
What else? Do you agree with this list? /Roger
Dr. Fielding's take on the subject can be found at http://lists.w3. org/Archives/Public/www-tag/2002Apr/0181.html - Sam Ruby
> 6. Minimize the use of query strings. For example: > > Prefer: > http://www.parts-depot.com/parts/00345 > Over: > http://www.parts-depot.com/parts?part-id=00345 > > Rationale: it's easier for Web intermedaries such as proxy servers to > evaluate a request when it doesn't need to parse a query string. I think the rationale for this is more along the lines that it allows relative URIs to work; the relationship between 'parts' and '00345' is clear, and you can instantiate subresources of '00345' easily; this is not possibly if that information is tucked away in a query string. I was working on a 'n ways to abuse a URI' document somewhat on these lines, with real-life examples; I've been sidetracked, but would be happy to put it up for others to work with (once I clean it up a bit). Cheers,
Jason wrote: > You're right. The UUIDs are unique even across "types" of resources. So the > patients/ or orders/ "prefixes" aren't really necessary. Since we have to > have some URI to list all resources of a given type to start with, I guess I > thought that it would make sense to use those URIs as "containers". Of > course, since all of these URIs are retrieved via links in representations, > it doesn't really matter what they look like as long as they're unique. With environmental acquisition as a feature in your RESTful server, all your UUIDs could physically exist in the container http://server/CliniVision but be requested as existing in 'patients' or 'doctors' sub-containers. Therefore, the server receiving the HTTP request (e.g., let's say it's a POST) would know that UUIDs exist in the CliniVision container, but see that the client wishes to locate information in the context of specifically CliniVision patients or doctors. -Philip
Mark Nottingham wrote: > > I was working on a 'n ways to abuse a URI' document somewhat on these > lines, with real-life examples; I've been sidetracked, but would be > happy to put it up for others to work with (once I clean it up a bit). Yes! I'd like to see it. /Roger
"S. Mike Dierken" wrote: > >... > If each object has a long-lived, persistent reference, then the URI doesn't > have to be 'patients/UUID' it can just be 'UUID'. It seems to me that it is merely preference one way or the other. > ... The trick with that is > that you have to retrieve the object before knowing what type it is if you > want to provide a representation. In either case you retrieve the object using a URI someone gave you. The internal syntax of the URI is not important! > ... Another issue is what happens if a user > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient. > (you are going to make doctors into numbers too, not just patients, right?) 404. >... > Yeah - cool stuff. I haven't played with this much in the past few years, so > I'm not sure what the best way to get 'device independence' - essentially > user-agent detection. Should the URI of the XSL return different XSL for > different devices? Should there be multiple PIs in the XML? Should the PI in > the XML be different for different user-agents? etc... Good question. If he's just using it for debugging it doesn't matter much. The stylesheet PI is a little bit simplistic... Paul Prescod
Robert Leftwich wrote: > >... > > I'm not sure about the /new as it looks suspiciously like a verb > and REST resources should be nouns. I'd be tempted to > use /patients/schema or /patients/structure on which a GET will > return the required fields list (alternatively the list returned from > a GET to /patients could include a link to the patients > required field structure, see also my ps below). I'm not sure why both of your designs includes a link instead of just inlining the "schema" or "form". Think of it like an HTML page with a form at the bottom that says: "add a patient by clicking here." But the analogy breaks down because if there is no human being on the other end then who interprets the schema and figures out where to get the information to shove into each field? At best I can see the schema being useful as a filter over named fields that are known at design time. "I don't need that field right now so don't bother sending it." But then that's just a performance optimization to avoid sending extra information. >... > PS One thing that has been bothering me in the REST examples I > have seen - how are the required formats/structures discovered > by the user? For example, in the case of REST-ifying the > UserLand XML storage api (http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorageSystem) it says: > "xmlStorageSystem.registerUser() > This method creates a new user account, or updates an existing > one on the server. This could quite easily have been done with either > an XML document containing this information..." > > How do I as a user or a system find out what structure the XML document should be? How did you figure out the existing Userland API? Either through a prose document or perhaps through a design-time specification like WSDL. The same holds for REST. What REST changes is that it separates the globally standardized stuff (methods, URIs) from the must-be-negotiated stuff (representations) which simplifies the negotiations and improves partial understanding. For instance if you define a "UserLandUserML" you'll find you can much more easily reuse that across different content management systems and parts of the UserLand API than the "RegisterUserLandUser" operation. Paul Prescod
> > ... The trick with that is > > that you have to retrieve the object before knowing what type it is if you > > want to provide a representation. > > In either case you retrieve the object using a URI someone gave you. The > internal syntax of the URI is not important! It's not important to the client but it can make implementing the server a heck of a lot easier. Does http://server/01234567-89AB-CDEF-0123-456789ABCDEF identify a patient or an order or something else? The client knows what context they received that link in so most likely knows what it refers to but the server has lost that context (being stateless and all). Path information can really help the server out here while still not breaking the REST guidelines (I hope). Jason
Jason Diamond wrote: > >... > > It's not important to the client but it can make implementing the server a > heck of a lot easier. Does > http://server/01234567-89AB-CDEF-0123-456789ABCDEF identify a patient or an > order or something else? The client knows what context they received that > link in so most likely knows what it refers to but the server has lost that > context (being stateless and all). Path information can really help the > server out here while still not breaking the REST guidelines (I hope). I agree. I was defending your design. The server can and should stash whatever it wants in the URI to help it figure out how to find the state that goes with the referenced resource. Paul Prescod
Paul Prescod <paul@...> wrote: > > Robert Leftwich wrote: > > > > I'm not sure about the /new as it looks suspiciously like a verb > > and REST resources should be nouns. I'd be tempted to > > use /patients/schema or /patients/structure on which a GET will > > return the required fields list (alternatively the list returned from > > a GET to /patients could include a link to the patients > > required field structure, see also my ps below). > > I'm not sure why both of your designs includes a link instead of just > inlining the "schema" or "form". Think of it like an HTML page with a > form at the bottom that says: "add a patient by clicking here." That's a definite true but that means you'd have to fetch the list of patients just to get the information to create a new one. By extracting that information out into a separate resource you can fetch the required fields without listing any patients. If we're transforming the output for display in a browser, we can always use the document() function to fetch the required fields to display at the bottom of the patient list. > But the analogy breaks down because if there is no human being on the > other end then who interprets the schema and figures out where to get > the information to shove into each field? At best I can see the schema > being useful as a filter over named fields that are known at design > time. "I don't need that field right now so don't bother sending it." > But then that's just a performance optimization to avoid sending extra > information. I'm not sure I understand. In our system there is either a human entering the data into the fields for each resource or there is another automated interface that knows how to map fields from systems in other parts of the hospital into our fields. Either way, they need to know the basic structure of the objects including the field names, types, constraints, etc. I admit that having configurable resources makes my example a little more complex than others would be. But I really appreciate the comments you guys are giving me. I think I'm finally starting to understand the concept of resource modelling and hope to get to update my design soon. Thanks, Jason
Jason Diamond wrote: > >... > > That's a definite true but that means you'd have to fetch the list of > patients just to get the information to create a new one. Okay, fair enough. That's a performance concern. But I'm getting a little lost in the discussion. Don't you need to fetch the list of patients to get the link to the "runtime schema"? So you still have a performance issue. If you're thinking about performance then maybe the schema should be the parent object and the list should be the child. Or they could have a common parent (perhaps it summarizes information from the patient list). >... > I'm not sure I understand. In our system there is either a human entering > the data into the fields for each resource or there is another automated > interface that knows how to map fields from systems in other parts of the > hospital into our fields. Either way, they need to know the basic structure > of the objects including the field names, types, constraints, etc. Okay, but in the case where it is a machine doing the filling in, that information needs to be available at *design time* so making it also available at runtime is redundant extra work for the service designer (you). Nevertheless, if human beings will be filling it in then of course it IS useful because there may not be a "design time". You could use something like HTML forms or XForms. And come to think of it, if the same schema is used at runtime and design time then there is no extra effort providing a link to it at runtime. Maybe that's what you were thinking about. Paul Prescod
Jason Diamond wrote: > >... > > Even if there was some standard way of obtaining the schema for a service, > applications can never really "know" what those elements and attributes > "mean". You're right in general but don't forget that there *are* standardized vocabularies out there that are appropriate for some projects. That's why there is a benefit in separating the always-standadized bits (methods) from the sometimes standardized bits (representations). It will be much easier to convince the world to standardize on your patient record vocabulary than on an "API" with more operational (workflow, business model, ...) semantics. > ... Some understanding between the two parties has to be achieved before > you can start making use of it. RDF might change things but until then, I'm > resigned to the fact that it's impossible to expect to use a web service > (SOAP or REST) without some development effort. I agree. I'll be even more pessimistic and say that semantic web technologies will not change this basic situation. When I walk into a bank wanting some foreign money, I need to know what an "exchange rate" is. If I write a currency trading client application it will need to know that same thing. I.e. it needs to know the concept and it needs to know either what term you will use for the concept or be able to map your term into its concept. Here's what I hope the semantic web technologies will do: a) improve the extensibility of representations to allow protocol evolution b) raise the level of abstraction so that rather than working with "elements and attributes" we can more easily work with objects that reflect higher level concerns. c) allow declarative (rather than programmatic) ways of configuring clients and servers to talk to each other. "When the server says patient_height, it means what the client calls the person's height property" "if the server says the order is shipped that implies that the client cannot cancel any more." Paul Prescod
At 08:53 AM 13/06/2002, Paul Prescod wrote: >Robert Leftwich wrote: >> How do I as a user or a system find out what structure the XML document should be? > >How did you figure out the existing Userland API? Either through a prose >document or perhaps through a design-time specification like WSDL. The >same holds for REST. What REST changes is that it separates the globally >standardized stuff (methods, URIs) from the must-be-negotiated stuff >(representations) which simplifies the negotiations and improves partial >understanding. For instance if you define a "UserLandUserML" you'll find >you can much more easily reuse that across different content management >systems and parts of the UserLand API than the "RegisterUserLandUser" >operation. This is one area where I see SOAP as having an advantage - you don't need to invent a ???ML (where ??? is your representation/resource space) with the associated problems of deciding how and when do I use XSD, RELAX-NG, DTD's, RDF, DAML, Schematron, ... or do I wait for a standard from the relevant standards body in my domain and if so what do I do in the interim. There is a lot of appeal to the hard-pressed people in the trenches to running a few wizards and presto a nice standards compliant Web interface springs into existence. Robert
Robert Leftwich wrote:
>
>...
>
> This is one area where I see SOAP as having an advantage - you don't need to invent a
???ML (where ??? is your representation/resource space) with the
associated problems
WSDL depends on XML Schema for defining ???ML.
> ... of deciding how and when do I use XSD, RELAX-NG, DTD's, RDF, DAML,
> ... Schematron, ...
WSDL hard-codes the choice of XSD. If you want a hard-coded choice you
can pay my consulting fee and I'll write you a report telling you which
one to choose. ;)
> ... or do I wait for a standard from the relevant standards
> body in my domain and if so what do I do in the interim. There
> is a lot of appeal to the hard-pressed people in the trenches to
> running a few wizards and presto a nice standards compliant Web
> interface springs into existence.
REST doesn't require de jure standardization, it just allows it. If you
wanted to convert the Userland API with the least possible work, you can
have representations like:
<xmlrpcresponse>
<struct>
<string>...</string>
<int>...</int>
</struct>
</xmlrpcresponse>
This could be used across all web services in the world with no more de
jure standardization ever. And It doesn't violate any principles of REST
(as long as you manipulate these using GET, PUT, POST, DELETE).
I just think it is kind of ugly and verbose compared to:
<person>
<name>...</name>
<height>...</height>
</person>
And it is also harder to validate and describe.
But REST doesn't care much.
Paul Prescod
Paul Prescod <paul@...> wrote: > > > ... Some understanding between the two parties has to be achieved before > > you can start making use of it. RDF might change things but until then, I'm > > resigned to the fact that it's impossible to expect to use a web service > > (SOAP or REST) without some development effort. > > I agree. I'll be even more pessimistic and say that semantic web > technologies will not change this basic situation. When I walk into a > bank wanting some foreign money, I need to know what an "exchange rate" > is. If I write a currency trading client application it will need to > know that same thing. I.e. it needs to know the concept and it needs to > know either what term you will use for the concept or be able to map > your term into its concept. You're absolutely right. Since everything in RDF is identified using URIs, however, all you really need to know is the URIs for the classes and properties that you're interested in. The format (whether it be RDF in XML, N3, or arbitrary XML vocabularies augmented with RDF-aware attributes--a pet project of mine) isn't as important--you can just extract the assertions out of whatever representation you've requested and then process them accordingly. I'm probably simplifying thinks too much to be practical but it sure sounds nice, doesn't it? Jason
On Thu, Jun 13, 2002 at 09:29:04AM +1000, Robert Leftwich wrote: > >> How do I as a user or a system find out what structure the XML document should be? > > > >How did you figure out the existing Userland API? Either through a prose > >document or perhaps through a design-time specification like WSDL. The > >same holds for REST. What REST changes is that it separates the globally [snip] > This is one area where I see SOAP as having an advantage - you don't > need to invent a ???ML (where ??? is your representation/resource > space) with the associated problems of deciding how and when do I use > XSD, RELAX-NG, DTD's, RDF, DAML, Schematron, ... or do I wait for a > standard from the relevant standards body in my domain and if so what > do I do in the interim. There is a lot of appeal to the hard-pressed > people in the trenches to running a few wizards and presto a nice > standards compliant Web interface springs into existence. Do you necessarily need to invent a ???ML for a REST application? You might very well be able to use one of the ebXML specs for purchase orders, HIPAA-XML (or whatever the %#@&*$) for a health insurance application, DocBook &/or RDF for a knowledge base ... And if you do need to invent your language? I would argue that (depending on your background) it's no harder to invent an ad-hoc XML dialect than to write an ad-hoc Java program. And not necessarily harder to create a well-designed XML spec than a well-designed Java library ... though, since the XML community is more anal-retentive about standards, conventions and design principles than most programmer communities, it might seem that way. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
I've seen a number of discussions here that have touched on the 'structure' of URLs - especially the construction of a hierarchical namespace to represent relationships between various resources. I've noticed that some people prefer to use the query string to convey information while others prefer to use the hierarchical structure of the namespace. While I realize that the choice of one over the other is probably a matter of preference (or at least dependent on the circumstances), I was wondering if anyone had thoughts on general rules-of-thumb for deciding whether to embed information in a query string vs in the path info; i.e.: http://server.com/something?item=itemname vs http://server.com/something/itemname Might one form have different semantics than the other? --Chuck
Chuck Hinson wrote: > >... > While I realize that the choice of one over the other is probably a > matter of preference (or at least dependent on the circumstances), I > was wondering if anyone had thoughts on general rules-of-thumb for > deciding whether to embed information in a query string vs in the path > info; i.e.: > > http://server.com/something?item=itemname > > vs > > http://server.com/something/itemname > > Might one form have different semantics than the other? If the client is expected to fill in values, use a query. By default, use a hierarchy. So for instance: findstocks?minimum_price=10 // client fills in minimum price customers/UUID019880934802348032 // they'll just follow a link to this, so use hierarchy Debatable: stocks?name=msft stocks/msft If you use the latter but you DO expect the client to know stock names then you should define a mapping somewhere like: <stock name="MSFT" uri="stocks/msft"/> You might choose to have this extra level of indirection to allow for the circumstance where the MSFT stock is served elsewhere: <stock name="MSFT" uri="http://someothermachine/msft"/> Paul Prescod
Bill de h�ra wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>-----Original Message----- >>From: Chris Croome [mailto:chris@...] >> >>I don't see why Amazon couldn't alias obidos to / for nicer >>URIs, but I guess they are stuck with it now. > > > Perhaps it is because Amazon /is/ restful. They're stuck with the > problem of throwing away all those resource names. > Not that it's completely relevant to the discussion at hand, but I don't think amazon is completely RESTful. Try this: Go to the front page and do a search for REST (under All Products). You'll get a results page with a URL that is something like this: http://www.amazon.com/exec/obidos/search-handle-form/104-2883896-9858338 If Amazon were completely RESTful, I should be able to link to that page or bookmark it so that I can revisit my results. Interestingly, if I try to do this in a new/different browser session, Amazon tells me there must be a bug in my browser. --Chuck
> > ... The trick with that is > > that you have to retrieve the object before knowing what type it is if you > > want to provide a representation. > > In either case you retrieve the object using a URI someone gave you. The > internal syntax of the URI is not important! I was speaking about the internal implementation of the server interpreting that URI syntax. Bugs can happen here if too much dependence is on the URI being 'right'. Implementation detail, but without paying attention to detail, you don't get implementation. > > > ... Another issue is what happens if a user > > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient. > > (you are going to make doctors into numbers too, not just patients, right?) > > 404. Again, I was considering internal implementation - the correct visible result should be a "404 Not Found" response status.
I think that is because they used POST rather then GET from the home page. I put the query terms on the URI and that didn't work either. Whatever. <form method="post" action="/exec/obidos/search-handle-form/103-9378802-1912632" name="searchform"> My guess is the 'magic number' in the URI is some user tracking 'invasion of privacy' thingee. ----- Original Message ----- From: "Chuck Hinson" <Chuck.Hinson@...> > > Go to the front page and do a search for REST (under All Products). > > You'll get a results page with a URL that is something like this: > > http://www.amazon.com/exec/obidos/search-handle-form/104-2883896-9858338
I'm building a web-based admin GUI for an application we have and I'm having a difficult time applying REST principles to the design (or maybe I'm just making things harder than they need to be). My current dilemma revolves around different representations of the same resource. In other threads, I've seen reference to the idea of resources having multiple representations, but the examples always seem to assume that the choice of representation to serve is based on the type of user agent or some other kind of http header information. While this makes sense to me when I'm able to write my own user agent and set whatever headers I want, it doesnt help much when I have to use a browser as my UA. So my question is, is it reasonable to encode information in the URL that indicates the desired representation? For example, a GET of http://server.com/users/userid would return a page listing the attributes of the user identified by userid. I call this the 'default' view for this resource. I also have the need for an 'edit' view. The edit view is similar to the default view except that it is presented as a form so as to allow the values of the attributes to be edited (and then submitted for update). That I want to submit the update as a POST to http://server.com/users/userid seems obvious. However its not so obvious to me that a GET of http://server.com/users/userid?mode=edit is the way to implement my edit view. I'm not sure why I have a problem with this. A colleague suggested I might feel better about it if I was more consistent: For the default view: http://server.com/users/userid?mode=view For the edit view: http://server.com/users/userid?mode=edit This doesnt seem much better. I can't really say why - except to say that it feels wrong to be embedding that kind of information in the URL. Then again, maybe I'm making a mountain out of a mole-hill. --Chuck
This is the area where I have the most problem with REST and HTTP. It's not hard to take back-end information and expose it as a 'resource model'. It is hard to put a usable user interface on top of that model - usability is just a different domain than information structuring. <flames-go-here href='void' /> The general view I take is that the UI itself is composed of resources with their own URI. With full hyperlinking, it isn't necessary to make the UI be a query string off of the 'data' resource - possibly handy, but not required. This suggests that rather than thinking about the 'edit vs view' HTML as being different representations of the same 'data resource', that they are in fact two different 'user interface' resources. The 'view' one could be a representation of the data resource and use the user-agent and Accept: header information to come out as intended. > That I want to submit the update as a POST to > http://server.com/users/userid seems obvious. However its not so > obvious to me that a GET of http://server.com/users/userid?mode=edit > is the way to implement my edit view. Finding the URI for the 'edit mode' has to happen via a hyperlink from some starting point. It doesn't in fact have to be 'data-uri?mode=edit' it could be somewhere completely different. Its the tags/location within the 'starting point' that tells you. You can implement the editing page any way you want and don't have to worry about 'clean uri syntax'. There are implementation details that suggest you keep the URI on the same host and if you use HTTP Auth or cookies, that you 'root' those above both resources - you can just use '/' for the path of the cookie to do that. Its a tough problem, but I find it helps to think of the UI as a separate space with its own URI - which don't necessarily have to be textually similar to the 'data resources'. Hope this helps. mike
Roger,
I really appreciate your always pragmatic approach. A best practices
document would be very useful and your set is a very good start.
One of your points does bring up some recent thinking on my part:
> 3. As a corollary to (2) use nouns in the logical URI, not verbs.
> Resources are "things" not "actions".
I know this perspective has been talked about regarding REST, but recently
I've shifted my thinking to view the trade-offs between the nouns vs. verbs
as a tangential issue. To the extent that URIs should be view as an
universal resource addressing scheme, I really don't know if we need or want
to limit resources to be "nouns".
If we insist that URIs be nouns, we are basically saying that we should use
a different addressing scheme to implement "verbs". In some ways, we are
justifying the need for something like SOAP in that that SOAP is a way to
define "verbs" that act on the "nouns" addressable via URIs.
Why should we not expose method calls via URIs so that they can participate
in the network effects? If I want to publish a web service that allows
control of the AC in my building, why should I not provide individual links
for "On", "Off", and "Adjust Temperature"? E-commerce sites to this all the
time with buttons that "Add to cart" or "Submit transaction".
Maybe another way to look at this is to look at the core "GET, PUT, POST,
and DELETE" as basic "access" mechanisms of an addressing scheme, not really
"verbs" in the sense of actions we would like to perform on things. So,
REST isn't about reducing the "verbs" and making as many things "nouns" as
possible, but about having an universal addressing and access mechanism.
This also relates to the idea that it is preferable to avoid query strings.
This is certainly valid for accessing real "noun" type resources. But, in
many cases, query strings are used when we are really accessing "verb" type
resources. For example, I think it is a real stretch to say that a Google
search URI is pointing at a "noun" type resource. We are basically asking
Google's search ("verb") resource to do a search for us and we pass along
our search criteria as query strings.
//Joe
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Wednesday, June 12, 2002 12:06 PM
To: rest-discuss@yahoogroups.com; Costello,Roger L.
Subject: [rest-discuss] REST Best Practices
Has anyone put together a set of Best Practices for creating REST
services? If not, how about getting started on one? Here's some that
come to mind:
1. Provide a URI for each resource that you want (or will want)
exposed. This is consistent with Tim Berners-Lee's axioms for the Web,
as well as the W3 TAG recomendations.
2. Prefer URIs that are logical over URIs that are physical. For
example:
Prefer:
http://www.boeing.com/airplanes/747
Over:
http://www.boeing.com/airplanes/747.html
Logical URIs allow the resource implementation to change without
impacting client applications.
3. As a corollary to (2) use nouns in the logical URI, not verbs.
Resources are "things" not "actions".
4. Make all HTTP GETs side-effect free. Doing so makes the request
"safe".
5. Use links in your responses to requests! Doing so connects your
response with other data. It enables client applications to be
"self-propelled". That is, the response itself contains info about
"what's the next step to take". Contrast this to responses that do not
contain links. Thus, the decision of "what's the next step to take"
must be made out-of-band.
6. Minimize the use of query strings. For example:
Prefer:
http://www.parts-depot.com/parts/00345
Over:
http://www.parts-depot.com/parts?part-id=00345
Rationale: it's easier for Web intermedaries such as proxy servers to
evaluate a request when it doesn't need to parse a query string.
What else? Do you agree with this list? /Roger
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
Chuck Hinson <Chuck.Hinson@...> wrote: > That I want to submit the update as a POST to > http://server.com/users/userid seems obvious. However its not so > obvious to me that a GET of http://server.com/users/userid?mode=edit > is the way to implement my edit view. If you're using CSS/JavaScript-aware browsers, couldn't you include both modes in the same HTML representation and toggle between them by alternately setting the display property to none and back again for the <div>s that contain your two modes? Jason
----- Original Message -----
From: "Joe Hsy" <joe.hsy@...>
>
> Why should we not expose method calls via URIs so that they can
participate
> in the network effects? If I want to publish a web service that allows
> control of the AC in my building, why should I not provide individual
links
> for "On", "Off", and "Adjust Temperature"? E-commerce sites to this all
the
> time with buttons that "Add to cart" or "Submit transaction".
A network effect occurs when many participate in a limited arena - everybody
uses TCP/IP, rather than netbios, netbui, banyan, etc. By having many verbs,
there is no limited arena - no network effect.
Its an object+method approach rather than a function-only approach, and the
object+method are separately identifiable. If you don't separate
object+method, you get object1.invoke(), object2.invoke(), etc. It is a
/workable/ system, but with the slight change to object.method1(),
object.method2(), you get more benefit - but the benefit drops off if you
have object.method99(), object.mymethod99(), etc.
As for why not with the WWW, the reason is that there is already a slot in
the message for both id and method - use them. There are already a small set
of method defined - used them. The more that participate in this arena, the
more 'network effect' will happen.
>
> Maybe another way to look at this is to look at the core "GET, PUT, POST,
> and DELETE" as basic "access" mechanisms of an addressing scheme, not
really
> "verbs" in the sense of actions we would like to perform on things. So,
> REST isn't about reducing the "verbs" and making as many things "nouns" as
> possible, but about having an universal addressing and access mechanism.
This is unclear to me - what is different between 'access' and 'action'? The
internal implementation of the interface can have any number of custom
actions - but the public contract and observed behavior is a common/standard
one. Exposing internal action names and assumptions is not necessary and
fragments the total space of addressable things.
>
> This also relates to the idea that it is preferable to avoid query
strings.
> This is certainly valid for accessing real "noun" type resources. But, in
> many cases, query strings are used when we are really accessing "verb"
type
> resources. For example, I think it is a real stretch to say that a Google
> search URI is pointing at a "noun" type resource. We are basically asking
> Google's search ("verb") resource to do a search for us and we pass along
> our search criteria as query strings.
The fundamental shift of thinking 'Web' is that we aren't asking Google to
do a search - I bet you it's cached with some form of consistent hashing and
they /don't/ actually search anyway. What we are asking for are the
/results/ - and those results are just plain data blobs. You can think of it
as 'do search' - but that doesn't apply to all other systems, whereas the
'get results' /will/ apply to all other systems. The Google search URI
points to the results, not the query engine.
From: S. Mike Dierken [mailto:mdierken@...] > A network effect occurs when many participate in a limited arena - everybody > uses TCP/IP, rather than netbios, netbui, banyan, etc. By having many verbs, > there is no limited arena - no network effect. It is probably better to say that it is commonality that creates network effects as opposed to limitations, though limitation can have the side-effect of creating de facto commonality. Regardless, I think we're talking different verbs. I am not talking about adding more "verbs" to HTTP's GET, POST, PUT, DELETE, though there can be justifiable reasons for doing that. I'm talking about not getting hung up on what can be a resource. I see no reason why a resource can't represent an action as oppose to data. > Its an object+method approach rather than a function-only approach, and the > object+method are separately identifiable. If you don't separate > object+method, you get object1.invoke(), object2.invoke(), etc. It is a > /workable/ system, but with the slight change to object.method1(), > object.method2(), you get more benefit - but the benefit drops off if you > have object.method99(), object.mymethod99(), etc. I am actually not encouraging one programming approach over the other. As you said, there are trade-offs. I am merely saying that there isn't a good reason to unilaterally discourage making functions URI-accessible. In OOP, there are times when you want to pass a function as parameter. If URIs can point to actions, there are interesting applications that can be built on top of these URIs. > This is unclear to me - what is different between 'access' and 'action'? The > internal implementation of the interface can have any number of custom > actions - but the public contract and observed behavior is a common/standard > one. Exposing internal action names and assumptions is not necessary and > fragments the total space of addressable things. One way to view the current basic HTTP methods (GET, PUT, POST, DELETE) is as basic addressing mechanisms that are not much different than core OOP object get, deletes, assign. That is what I mean by access. Actions would be something like a car.drive() method invocation. Why do you think exposing action names would fragment the total space of addressable things? It is just another resource to be accessed using the same set of public contract methods. > The fundamental shift of thinking 'Web' is that we aren't asking Google to > do a search - I bet you it's cached with some form of consistent hashing and > they /don't/ actually search anyway. What we are asking for are the > /results/ - and those results are just plain data blobs. You can think of it > as 'do search' - but that doesn't apply to all other systems, whereas the > 'get results' /will/ apply to all other systems. The Google search URI > points to the results, not the query engine. There is no question some searches are cached, but surely you are not suggesting that all possible queries to Google are precached? 8-) Whether Google is doing a real search action may be debatable, but there is no doubt that there is a need for action invocation in certain types of applications. How would you advise that we think 'Web' on a post that purchases a stock? Is the URI pointing to a purchase result? That would be a rather awkward way to look at it, don't you think? If we insist that thinking 'Web' means we never think in terms of invoking actions, then we are severely limiting the potential of the web, and we force people to go "outside of the web" to write applications that are transaction oriented. Let's not forget that "the web" is only one application on the internet. SOAP does not need the web to be successful or to benefit from "network effect". The web may have fueled the build-out of the internet, but it isn't guaranteed to remain the dominant application that runs over the roads it helped build. The web needs to evolve to support the needs of the user community or they will turn to other means to accomplish what they need. I see problems with SOAP, but I also see that REST lacks clear guidelines and support for transactional applications and I sense many people struggling to write these types of applications in a RESTful way. The challenge is to provide a clear programming model and tools for developers as opposed to listing ways in which applications are not be RESTful or violate web principles. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Paul Prescod wrote: > > WSDL hard-codes the choice of XSD. False. http://www.w3.org/TR/wsdl#_types > If you want a hard-coded choice you > can pay my consulting fee and I'll write you a report telling you which > one to choose. ;) Robert - don't do it ;-) - Sam Ruby
Jason Diamond wrote: > Chuck Hinson <Chuck.Hinson@...> wrote: > > >>That I want to submit the update as a POST to >>http://server.com/users/userid seems obvious. However its not so >>obvious to me that a GET of http://server.com/users/userid?mode=edit >>is the way to implement my edit view. > > > If you're using CSS/JavaScript-aware browsers, couldn't you include both > modes in the same HTML representation and toggle between them by alternately > setting the display property to none and back again for the <div>s that > contain your two modes? > > Jason > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
Jason Diamond wrote: > Chuck Hinson <Chuck.Hinson@...> wrote: > > >>That I want to submit the update as a POST to >>http://server.com/users/userid seems obvious. However its not so >>obvious to me that a GET of http://server.com/users/userid?mode=edit >>is the way to implement my edit view. > > > If you're using CSS/JavaScript-aware browsers, couldn't you include both > modes in the same HTML representation and toggle between them by alternately > setting the display property to none and back again for the <div>s that > contain your two modes? > > Jason > But I still need to be able to indicate which <div> to initially display. If somehwere else in my GUI I click on a link labelled 'Edit User', then I expect the edit view to come up. If (somewhere else in my GUI) I click on a link labelled 'View User', then I expect the default view to come up. --Chuck
On Thu, Jun 13, 2002 at 01:14:05AM -0400, Joe Hsy wrote: > Maybe another way to look at this is to look at the core "GET, PUT, > POST, > and DELETE" as basic "access" mechanisms of an addressing scheme, not > really > "verbs" in the sense of actions we would like to perform on things. So, > REST isn't about reducing the "verbs" and making as many things "nouns" > as > possible, but about having an universal addressing and access mechanism. It's both. You can't have one and not the other; they come together. I strongly agree with Roger's point. > 6. Minimize the use of query strings. For example: > > Prefer: > http://www.parts-depot.com/parts/00345 > Over: > http://www.parts-depot.com/parts?part-id=00345 > > Rationale: it's easier for Web intermedaries such as proxy servers to > evaluate a request when it doesn't need to parse a query string. I'll comment on this point while I'm here ... I don't think you need to minimize the use of query strings. They're good and fine. What you might be trying to say is that non-transient resources should have a "principal" URI that does not include a query string. For example, a query returning multiple employees probably doesn't need one, but one for an individual employee probably does. The reason I think this is a good idea is that it allows for later decomposition of these resources (i.e. treat as containers for composite state). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > > It's both. You can't have one and not the other; they come together. > I strongly agree with Roger's point. > > >>6. Minimize the use of query strings. For example: >> >> Prefer: >> http://www.parts-depot.com/parts/00345 >> Over: >> http://www.parts-depot.com/parts?part-id=00345 >> >>Rationale: it's easier for Web intermedaries such as proxy servers to >>evaluate a request when it doesn't need to parse a query string. > > > I'll comment on this point while I'm here ... > > I don't think you need to minimize the use of query strings. They're > good and fine. What you might be trying to say is that non-transient > resources should have a "principal" URI that does not include a query > string. For example, a query returning multiple employees probably > doesn't need one, but one for an individual employee probably does. The Doesnt need one what? - a principal URI or a query string. --Chuck > reason I think this is a good idea is that it allows for later > decomposition of these resources (i.e. treat as containers for composite > state). > > MB
rubys@... wrote: > > Paul Prescod wrote: > > > > WSDL hard-codes the choice of XSD. > > False. Sorry. "WSDL implementations hard-code the choice of XSD." Paul Prescod
Paul Prescod wrote: > >>> WSDL hard-codes the choice of XSD. >> >> False. > > Sorry. "WSDL implementations hard-code the choice of XSD." There may exist a WSDL implementation that hard-codes the choice of XSD, but the reference implementation [1] of the Java APIs for WSDL [2] most decidedly does not. [1] http://www-124.ibm.com/developerworks/projects/wsdl4j/ [2] http://www.jcp.org/jsr/detail/110.jsp
On 6/12/02 7:54 PM, "Chuck Hinson" <Chuck.Hinson@...> wrote: > http://server.com/something?item=itemname > > vs > > http://server.com/something/itemname > > > Might one form have different semantics than the other? Hardcore purist's answer: they are semantically equivalent. In fact, all well-formed URI are identical except inasmuch as dereferencing different ones yields different representations. By this reasoning, http://12345 would be just as good, because the "information" carried in the hierarchical part cannot be considered in interpreting the URI (except by the server that has that very interpretation as its primary function.) Now, nobody believes all that, but that's the literal interpretation of the various axioms, etc. Moderate answer: They're equivalent, use whichever one tickles your fancy. Radical answer --- my own opinion. Wherever there's hierarchy in your resource model, it should be reflected in your URIs. If "something" is (a) a container for items, (b) an object of interest in its own right, and if items are objects of interest in their own rights that are contained by "something," then the strictly hierarchical form is preferable. In addition, it's worth noting that overuse of query strings to convey what could be represented as hierarchical structure causes proxies / caches and other intermediaries or agents to do more work or, at worst, to fail entirely. It should be possible to compare URIs for determination of equivalence (something that proxies, crawlers, and the like do all the time) by a simple lexical test. Use of nonordinal keyword-based query strings messes this up; it's impossible to determine the difference (or lack thereof) of http://server.com/container?item=itemname&color=red http://server.com/container?color=red&item=itemname Without requiring the proxy etc. to interpret the query string; and indeed, it's not possible for proxies to do that reliably, because the resource implementation could either require ordinality or not, and there's no way to tell. The safest thing for the proxy etc. to do is ignore all URIs with query strings and, indeed, some have in the past; .: use query strings sparingly if at all, and if you do try to discriminate based on only a single property / param / value. Jb
Sam Ruby wrote: > >... > > There may exist a WSDL implementation that hard-codes the choice of XSD, > but the reference implementation [1] of the Java APIs for WSDL [2] most > decidedly does not. Does there exist a WSDL implementation that allows me to generate programming language clients from any other schema language? Can I use RELAX with Axis? Schematron with the .NET Framework? Or let me back up a step and ask, could I, given a RELAX implementation for Java, plug it into Axis for use in my WSDLs for bidirectional conversions to Java types. Could I do that through existing hooks or only by changing Axis' implementation? But we're getting off the topic of the original question. REST does not require de jure standardization and can use either runtime types (like the SOAP encoding) or design time types (like WSDL+XML Schema) just as SOAP+WSDL systems can. If Axis allows me to plug in RELAX in a well-documented way, great! Paul Prescod
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > > It's both. You can't have one and not the other; they come together. > I strongly agree with Roger's point. Again, as I replied to Mike, I think we're talking about different levels of abstraction regarding "nouns" and "verbs". At the protocol level of abstractions, we can say that end points are nouns and the protocol is the verb. At this level, there is no question that a small well-defined set of verbs will optimize the network effect. Take the phone system as an example (a prime network effect system). Telephony devices are the nouns and there is one main verb - "to call". From this perspective, the many-noun-to-few-verbs ratio is desirable. However, from a telephony application perspective, there is no reason to prevent people from modeling a telephony end-point as an action. For example, we "page" a person by calling a pager. To some people it is a more natural way to think about the actual "action" of paging someone as opposed to "calling" a paging device. I don't see a problem with abstracting the phone number to a "paging" action as opposed to a paging device. Let's take a look at the sentence again: > 3. As a corollary to (2) use nouns in the logical URI, not verbs. > Resources are "things" not "actions". URIs are like phone numbers - both are universal addressing schemes. All I'm saying is that we shouldn't arbitrarily discourage people from modeling "actions" as resources for those applications that makes sense. Buying a book is a clearly an action. You can abstract the URI into a noun by calling it a "purchase transaction record", but to the end user pushing the "buy" button, it is still an action. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
At 09:24 AM 13/06/2002, Paul Prescod wrote: >Jason Diamond wrote: > > > >... > > > > That's a definite true but that means you'd have to fetch the list of > > patients just to get the information to create a new one. > >Okay, fair enough. That's a performance concern. > >But I'm getting a little lost in the discussion. Don't you need to fetch >the list of patients to get the link to the "runtime schema"? So you >still have a performance issue. If you're thinking about performance >then maybe the schema should be the parent object and the list should be >the child. Or they could have a common parent (perhaps it summarizes >information from the patient list). I don't agree with the notion that a resource model needs to be different due to performance concerns. What happens if the performance concerns change due to unforeseen circumstances and/or innovation? The representation might be different, but not the model. Could you (or should you) model the metadata as a separate resource? Something along the lines of /metadata/patient, /metadata/orders/procedure1, or /patients/metadata, /orders/procedure1/metadata. > >... > > I'm not sure I understand. In our system there is either a human entering > > the data into the fields for each resource or there is another automated > > interface that knows how to map fields from systems in other parts of the > > hospital into our fields. Either way, they need to know the basic structure > > of the objects including the field names, types, constraints, etc. Along these lines, when you do a POST to /orders (specifying the type in the posted data) and it responds with a location where to put the new order, i.e. /orders/new_uuid, doing a GET on this location could retrieve an empty order of the specified type along with a link to the schema/metadata, thus giving you all the structure information that is needed. Robert
> -----Original Message----- > From: Jason Diamond [mailto:jason@injektilo.org] > > Since everything in RDF is > identified using URIs, however, all you really need to know > is the URIs for the classes and properties that you're > interested in. After you agree on terms you have to agree on processing; there's more to know than resources. We can't declare behaviour away and just write down everything we know as RDF triples. RDF doesn't have a processing model so we have to assume that the semantics associated with the URIs are extremely clear as a boost to implementers. Bill de hra
> -----Original Message----- > From: Chuck Hinson [mailto:Chuck.Hinson@avercom.net] > > Not that it's completely relevant to the discussion at hand, but I > don't think amazon is completely RESTful. > > Try this: > > Go to the front page and do a search for REST (under All Products). Yep. I tried on amazon.co.uk, with the same outcome (and after with my own uid at the end). Weird that they gateway search like that. Is that for session tracking? Bill de hra
On Thu, Jun 13, 2002 at 11:38:23AM -0400, Chuck Hinson wrote: > > > > I don't think you need to minimize the use of query strings. They're > > good and fine. What you might be trying to say is that non-transient > > resources should have a "principal" URI that does not include a query > > string. For example, a query returning multiple employees probably > > doesn't need one, but one for an individual employee probably does. > The > > Doesnt need one what? - a principal URI or a query string. A principal URI. BTW, by "transient", I don't mean that it might return 404 at some point in the future, only that it's rarely (if ever) used outside of the context of a search. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
REST folk should find this interesting, imho...
---------- Forwarded message ----------
Date: Fri, 14 Jun 2002 06:33:27 -0400
From: Carl Lagoze <lagoze@...>
To: DC-GENERAL@...
Subject: Open Archives Initiative Releases Version 2.0 of the Protocol
for Metadata Harvesting
For immediate release June 14, 2002
Open Archives Initiative Releases Version 2.0 of the Protocol for
Metadata Harvesting
Ithaca, NY & Los Alamos NM-The Open Archives Initiative is pleased to
release version 2.0 of the Open Archives Initiative Protocol for
Metadata Harvesting (OAI-PMH). The release of OAI-PMH v.2.0 comes after
16 months of worldwide experimentation with version 1.x of the protocol,
an 8 month revision process by the OAI-tech group, and 4 months of
alpha/beta testing. Thanks to this rigid testing and revision, we feel
confident to release the OAI-PMH version 2.0 as a stable specification.
A full copy of this press release with information about the features of
OAI-PMH version 2 is available at
http://www.openarchives.org/news/oaiv2press020614.html.
The OAI-PMH version 2 specification is available at
http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm.
Visit the OAI web site at http://www.openarchives.org for more related
information.
Carl Lagoze and Herbert Van de Sompel
OAI Executive
This discussion on whether verbs should be used in URIs is excellent!
Thanks Joe for raising this issue. It has certainly stimulated new
ideas and questions in my mind. Let's not let this discussion stop
until we have fully explored all facets of this issue and have arrived
at consensus. I think that it is important that we (the REST community)
speak with a unified voice.
Let me try to first summarize the issue and both sides of the argument.
Then I will add my own thoughts on the topic.
The issue is this: should a URL be allowed to have verbs in it?
Example. Here's an example of a URL that contains a verb (add-to-cart)
http://www.parts-depot.com/parts/00345/add-to-cart
Let's now summarize both sides of this issue
The Nouns-Only Camp
This side of the argument says that URLs should only contain nouns.
They say that verbs should not be allowed in URLs. Here's why:
1. By definition, resources are "things" not "actions". URLs identify
resources, not functions.
2. Separation of concerns: keep the identification (i.e., the URL) of a
resource separate from the methods (HTTP GET, POST, PUT, DELETE) applied
to the resource. In OO terms we might think of the URL as providing the
name of the Object, and the HTTP methods as the generic set of methods
on the Object. For example:
{http://www.parts-depot.com/parts/00345}.GET()
3. Generic interface: keep the interface to resources generic - the HTTP
methods. When you allow verbs then you are essentially expanding the
interface. For example:
http://www.parts-depot.com/parts/00345/add-to-cart
is essentially a composition of methods:
{{http://www.parts-depot.com/parts/00345}.add-to-cart()}.GET()
Thus, the resource (part 00345) is exposing an implementation function,
add-to-cart.
The Verbs-Allowed Camp
This side of the argument says that URLs should be allowed to contain
verbs as well as nouns. Here's why:
1. It seems natural that you would want to identify a resource and tell
it to take an action. Some examples:
http://www.my-home.org/air-conditioning/on
http://www.google.com/search?topic="juice-machines"
2. Verb-oriented URLs are very program-friendly. For example, a program
to control devices in my house might look like this:
http://www.my-home.org/connect-to-central-computer
http://www.my-home.org/air-conditioning/on
http://www.my-home.org/air-conditioning/adjust-temp?value=68
http://www.my-home.org/stereo/on
http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity
3. Unilaterally prohibiting functions as URI-accessible makes the Web
less friendly and useable, as I will need to contort things to get
around this constraint. Imagine doing the above using just nouns.
Is this a fair summary of both sides? If not, please add/correct.
Now for my own comments:
As always, I think best with a concrete example in front of me. So,
let's consider Parts Depot. This company has deployed some Web services
to enable clients to:
1. Get a list of parts
2. Get detailed information about a part
3. Purchase parts
It is the third service (purchase parts) which is most relevant to this
discussion.
Let's suppose that the client has used the first service to get the
parts list, and then used the second service to drill down to get
detailed information about part 00345. Suppose that this is the
response:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>
This part is used within the frap assembly
</Description>
<Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>10</Quantity>
</p:Part>
Suppose that the client decides that he/she wants to "add this to
his/her shopping cart". To provide this capability Parts Depot may
provide another element <AddToCart> when it returns detailed part
information. Thus, instead of the above XML document the client would
receive this:
<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>
This part is used within the frap assembly
</Description>
<Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>10</Quantity>
<AddToCart href="http://parts-depot.com/parts/00345/add-to-cart"/>
</p:Part>
Note the last element, <AddToCart href="..."/>. The URL in the href
attribute:
http://parts-depot.com/parts/00345/add-to-cart
clearly contains a verb, add-to-cart.
I have a couple of thoughts about this design:
1. If the HTTP method for the above URL is GET then it is violating the
principle that all GETs should be side-effect free.
2. One of the principles of REST is that the client should maintain
his/her own state. The server should not do so. The above approach has
the server maintaining state about the client.
Here's an alternative solution. The client creates a Purchase Order
(PO) which identifies the parts he/she is interested in purchasing.
When the client finds a part that he/she is interested in, the client
will add that part number to the PO. When the client is ready he/she
submits the PO. Some things to note:
1. The PO represents the "shopping cart".
2. The PO is composed on the client side, not the server side.
This second design seems to be more in the spirit of REST.
Those are the two ways that I see for implementing the purchase parts
Web service. Are there other (better) ways? Any comments? /Roger
Here's an alternate view of purchasing that might make the resource view more clear (and more like nouns): There are at least two stages of purchasing on the Web: 1. making commitments to exchange money (via credit card) for goods. 2. delivering the goods and charging the credit card. Except in the case of downloadable electronic goods (e.g. music or software), we don't actually handle the goods and money online. So in stage 1, the Web resources are not actions, they are commitments: I promise to pay $30 via my credit card if Amazon promises to send me this book. At this same time, Amazon gets a credit charge authorization from the credit card handler, which should be but isn't usually a Web resource. In stage 2, the Web resources include documentation that Amazon shipped the book, maybe a shipment tracking ID that could link to a UPS Web resource representing the package in transit, and (should be, but isn't) a Web resource representing the credit card charge. So there are no "actions" except GETting, PUTting or POSTing Web resources. The resources themselves represent commitments or documentation of actions taken in the meat world. Even electronic funds transfer does not actually transfer money, it's just bits - money of account. Relevant Web resources would include Accounts and Transfer documents. Almost anything in business has already been represented by a document, which could become a Web resource. Downloading electronic goods is an action. Is there a common method? -Bob Haugen
Roger wrote:
> Those are the two ways that I see for implementing the purchase parts
> Web service. Are there other (better) ways? Any comments? /Roger
I'm not sure where my version of this verb/URI issue stands, but here is the way
I have designed it in my own efforts. As I mentioned before, I have a
pre-developed set of resource types, namely methods, components, topics, queues,
etc that are published in a node's hierarchical namespace. Each type is a
different type of abstraction, but all of them have methods that can be invoked.
Here is the way I see how each of the HTTP methods allow nodes to interact with
them:
------
HTTP GET - allows you to ask a node to return information about a resource at a
URI. In the case of a method resource, the results of a HTTP GET with
/Fruit/Apple/Washington/harvest might look like this:
<item key='harvest' type='method'>
<list>
<item key='baseName' value='harvest' />
<item key='baseName' value='cosecha' scope='/Language/ES />
<item key='optionalParam' type='boolean'>param5Name</item>
<item key='requiredParam' type='singleText'>param5Name</item>
<item key='requiredParam' type='multiText'>param4Name</item>
<item key='requiredParam' type='singleSelect'>param1Name</item>
<item key='optionalParam' type='multiSelect'>param2Name</item>
</list>
</item>
So a GET really only lets you to discover the resource. Obviously, if you had a
XSL converter, the above XML is easily converted into an HTML form that a
browser can use to can actually invoke the method.
HTTP PUT - instead of getting a pre-existing resource like the one above, it
allows you to effectively copy a resource in its current state to another node.
You are effectively publishing it on the destination node.
HTTP POST - in the case of method resources, like the one above, this is as
close as you get to the "verb" notion, where POST has optional/required
parameters that have been specified in the body and/or request line's query
string.
HTTP DELETE - deletes the published resource at the URI.
------
In essence, even though the URI provides you with the location of a method
resource on the network, it's not pointing to a verb per se. It is pointing to
the verb "as a noun". Once you POST to it, then that's when you submit
information to the resource being hosted by the server, and in this case, the
harvest method uses it to invoke behavior.
How far on or off base is this approach to REST? Do the REST purists out there
agree with it? Would this be more noun-like or verb-like?
Thanks,
Philip
Joe Hsy wrote: > >... > > However, from a telephony application perspective, there is no reason to > prevent people from modeling a telephony end-point as an action. For > example, we "page" a person by calling a pager. To some people it is a more > natural way to think about the actual "action" of paging someone as opposed > to "calling" a paging device. I don't see a problem with abstracting the > phone number to a "paging" action as opposed to a paging device. Okay, but let's take this analogy back to the Web. Wouldn't the best way to page someone be to POST a page so that the thing you've POSTed has a URI? Then the person doing the paging and the paged person both have a name for the page, the person doing the page could refer to it later (e.g. to ask to cancel it (DELETE), or extend it (sub-POST)) and so forth. But I do think that there is room for a layer of abstraction on the client side that allows a natural OO API rather than just HTTP methods. >... > Buying a book is a clearly an action. You can abstract the URI into a noun > by calling it a "purchase transaction record", but to the end user pushing > the "buy" button, it is still an action. Okay, but we might as well call it "submit purchase request" because we are going to make a new purchase request object and it will have a new URI. "Buy" might be more familiar but "submit purchase request" is more accurate. And you are going to want a way to navigate back to *all* of your purchase requests later, so somewhere there must be a list of them. So an even more accurate name for the service is "add new purchase request", i.e. "POST" to "your_purchase_requests". When I analyze these things I usually don't have a need for verbs as URIs *except* to work around implementation limitations. Paul Prescod
bhaugen32 wrote: > >... > > Downloading electronic goods is an action. Is there a common method? I don't think I understand the question. GET is how you download things using HTTP. Paul Prescod
Philip Eskelin wrote: > >... > > I'm not sure where my version of this verb/URI issue stands, but here is the way > I have designed it in my own efforts. As I mentioned before, I have a > pre-developed set of resource types, namely methods, components, topics, queues, > etc that are published in a node's hierarchical namespace. I guess the basic question is whether you *need* method objects. A REST-purist view would be that you should use methods as an implementation technique to implement a resource view of the world. Since I don't know what method objects you have, I can't resource-decompose them. But in most cases you will want an action to have a side-effect that creates a resource+URI, and you will want the newly created resource to be in some container. So you can instead use a POST on the container. >... > HTTP PUT - instead of getting a pre-existing resource like the one above, it > allows you to effectively copy a resource in its current state to another node. > You are effectively publishing it on the destination node. It's not clear to me how you can copy a method. After all, the real method is the programming code behind it. And that code will depend on a complex network of other state. So PUT-ting to a method resource doesn't make much sense to me. Paul Prescod
This is my rambling sense of the state of the debate between SOAP and REST. To their credit, the SOAP working group has responded to our criticism of the SOAP model and I think that there is a 50/50 chance that the most severe incompatibility between the two models can be fixed over the next while. In particular, I believe that they are coming to agree that the "single endpoint" model is architecturally unsound. I have two reasons to believe that this is the case. The first is that they have defined a "GET" binding for SOAP and agreed that it should be used for any HTTP SOAP service that has the semantics of HTTP's GET. The second is that I've gotten generally positive agreement that the SOAP primer should specifically say that an endpoint-per-resource model makes more . I haven't got MUCH feedback but the feedback I've gotten so far has been positive: * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jun/0036.html Here is the proposed text: "One of the principles of Web Architecture is that all important resources should be identified by URIs. This implies that many well-architected SOAP services will be embodied as large numbers or resources, each with its own URI. Indeed, many such resources are likely to be created dynamically during operation of the service, as new information becomes available. For example, a service offering stock prices might use a distinct URI for each stock tracked, and perhaps for each date and time for which quotes are provided." This is a non-normative change to the specification but it implies massive changes to SOAP toolkits and to WSDL. I believe that most existing SOAP toolkits do not allow easy implementation of this convention. This is especially true for toolkits for statically typed languages with "interface generators." But that's okay, because these toolkits take their lead from WSDL, and one of the WSDL requirements (that I proposed) also addresses this issue: "The description language SHOULD allow describing Messages that include references (URIs) to strongly-typed referents, both values and Services." In other words, it should be possible to have a SOAP message or HTTP message with a URI in it that points to a SOAP/HTTP endpoint described by another WSDL. This will at least make it possible to use WSDL in a system where "hypermedia is the engine of application state." We should work with the WSDL group to make sure that this happens and that HTTP-based services are strongly represented. We should also try and work with open source toolkit implementors to make sure that they do the right thing as examples for the closed-source vendors. My current hope for the future is that a single URI will commonly support both HTTP and SOAP methods. For instance, if you avoid the various optional SOAP features (SOAP encoding, SOAP headers), the only real difference between the new SOAP GET and a plain old HTTP GET is that the one returns a SOAP-wrapped body and the other does not. Content-negotiation could trigger which happens. (that should perhaps be added normatively to the SOAP specification!). In many situations, you could just accept that for marketing reasons you must wrap your XML in a SOAP:Envelope and SOAP:Body and move on. POST is similar to GET. You can probably just build your REST service and ignore the SOAP:Envelope and SOAP:Body. SOAP does not define PUT or DELETE, so the "HTTP side" of a service can use them without conflict. REST could be viewed as a sort of best-practices for SOAP usage -- even if we're not using much of SOAP. Hmmmm. There should probably be a TAG ruling on whether it is appropriate to use SOAP methods to do something that is logically equivalent to an HTTP PUT and DELETE or whether you should just use HTTP PUT and DELETE. It seems to me that it kind of follows naturally from the GET decision but it might be politically harder because PUT and DELETE are not as popular or architecturally important as GET. But all of this will only work if the toolkits allow it. If it is prohibitively expensive to assign URIs to objects, or to accept *both* HTTP and SOAP methods on the same object, we will find ourselves back at odds with SOAP again. I think that pushback is quite likely because SOAP has many tensions (I would go so far as to say contradictions) in its design. It's an RPC protocol but not really. It's a synchronous protocol but not really. The one that is dangerous to REST: it is a web protocol but it is also "transport agnostic". This latter means that it could be tricky to make a SOAP API or user interface that allows really good Web-based Web Services and then allows you to push a button and get the same features on MQSeries or SMTP. REST people could fantasize that this might result in the Web model leaking onto other transports but alternately it might mean that Web features (like SOAP GET and one-endpoint-per-resource) just don't get implemented. In addition, there are all of the SOAP add-ons which will come to the fore when SOAP is standardized. Someone will have to ensure that WS-Security, WS-Routing, transaction standards etc. interact properly with HTTP and Web architecture etc. Keeping up with this stuff is a full-time job! In other words, there is a fight on for the Soul of SOAP -- will it be COM for the Internet, or an XML wrapper for the Web, or something else entirely? And of course there remains the issue of pre-defined methods as in HTTP versus invent your own as in the traditional SOAP style. Nevertheless, the good news is that it if things go the right way, it will be increasingly possible to tell our customers and bosses (honestly!) that we are using SOAP and REST. Perhaps if we are vocal enough with that message the other standards and implementations will fall into place more easily. Paul Prescod
Hi Roger, I'm not sure that there is sufficient disagreement here to warrant "camps" in this discussion, but as usual, you've done a great job summarizing the salient points. I can't speak for others, but your points accurately reflected my general thinking. I espcially liked the www.my-home.org examples as an application where action verbs are a much more natural way of modeling the system. Regarding the parts-depot purchase example, I think having a URL that would model the "add-to-cart" action is fine. You can simply make it a POST to preserve the no-side-effect condition for GET (maybe GET of that URL will return the part availability?). In fact, a POST could provide an added opportunity to ask for additional authentication. I think having the action return a set of URLs that provides follow-on actions would be even more interesting. For example, you could have the add-to-cart action return URLs that allows you to remove from cart or go to checkout. Implementing a client-side shopping cart is certainly reasonable, but website have server-side shopping carts because they want to track customers as they actually add things to the carts even if they don't buy. It allows them to remind the shopper and also gather more customer behavior info. Again, your pragmatic examples are very useful illustrations of the issues. Thanks! //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: Paul Prescod > Okay, but let's take this analogy back to the Web. Wouldn't the best way > to page someone be to POST a page so that the thing you've POSTed has a > URI? Then the person doing the paging and the paged person both have a > name for the page, the person doing the page could refer to it later > (e.g. to ask to cancel it (DELETE), or extend it (sub-POST)) and so > forth. > > But I do think that there is room for a layer of abstraction on the > client side that allows a natural OO API rather than just HTTP methods. I agree on both points. I was merely using paging in the telephony domain to indicate that we're discussing different abstractions of the words verbs and nouns. Paging applications on the web could probably be modeled just as well using a "page" as document model v.s paging as action model. I've been looking for exactly this type of natural OOP API as an abstraction for implementing transactional applications within the REST mdoel. > Okay, but we might as well call it "submit purchase request" because we > are going to make a new purchase request object and it will have a new > URI. "Buy" might be more familiar but "submit purchase request" is more > accurate. And you are going to want a way to navigate back to *all* of > your purchase requests later, so somewhere there must be a list of them. > So an even more accurate name for the service is "add new purchase > request", i.e. "POST" to "your_purchase_requests". > > When I analyze these things I usually don't have a need for verbs as > URIs *except* to work around implementation limitations. I have no doubt that we can convert any action into a "noun" concept. As you said, purchasing something is conceptually similar to creating a purchase record. An action typically creates a state change that can be captured as an document record. This is fine for many actions, but for many other actions, this is very awkward thinking. Few people really thinking of turning on the air conditioning as changing the state of the AC into the "ON" state. Starting a race is an action that isn't naturally modeled as a "noun". I definitely agree that having a record created of an action as a consequence is often useful, but doesn't necessarily make that the natural mental model for programmers or ultimately, end-users. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Paul Prescod wrote: > bhaugen32 wrote: > > Downloading electronic goods is an action. Is there a common method? > > I don't think I understand the question. GET is how you download things > using HTTP. I know. I'm afraid I expressed my question very badly. I should have written "is there a pattern for how Web sites usually handle the sale of downloaded products, including URIs, methods, etc."? I haven't done it for a while, and didn't pay any attention when I did. The context was purchasing, where somebody wrote that purchasing was an action, and the URI should contain a verb. My response was that you seldom actually purchase something on the Web, in the sense that you purchase something from a store, where you take the goods and hand them the money or swipe your credit card. Instead you document your commitment to pay if they send you the goods, and then later they document that they shipped the goods, etc. The exception was where you downloaded some bits. The URI often says /download, which I interpret as a verb. If memory serves my right, if you're buying the stuff, there is usually a POST where you authorize payment from your credit card, and then they give you permission for the actual download resource. At that point, I know that HTTP says use GET, but I have no idea what Web sites actually use. There might also be a state change where they record the fact that you downloaded the stuff.
In the interest of promoting REST I have written an article[1] titled: Building Web Services the REST Way I am planning on submitting it to xml.com for publication. However, prior to doing I would like a sanity check (I don't want to embarrass myself nor the REST community). So, I have a favor to ask: would you take a look at the article and give me feedback? I can accept criticism, so if you think that it's not up to par please let me know. Thanks! /Roger [1] http://www.xfront.com/REST-Web-Services.html
> 1. It seems natural that you would want to identify a resource and tell
> it to take an action. Some examples:
>
> http://www.my-home.org/air-conditioning/on
> http://www.google.com/search?topic="juice-machines"
You've identified two resources - what part tells it to take an action? and
what action does it take?
http://www.my-home.org/air-conditioning/on could test whether the unit was
on or not. It could toggle the power. It could set the power on, lots of
things.
http://www.google.com/search?topic="juice-machines" - what is it you are
searching for within the 'juice-machines' topic? Or does it return
true/false if the topic exists?
>
> 2. Verb-oriented URLs are very program-friendly. For example, a program
> to control devices in my house might look like this:
>
> http://www.my-home.org/connect-to-central-computer
> http://www.my-home.org/air-conditioning/on
> http://www.my-home.org/air-conditioning/adjust-temp?value=68
> http://www.my-home.org/stereo/on
> http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity
What verb is this? It seems more like a 'closure' - binding action and data
into a single opaque 'invokable' object.
It looks more like these URI are reflections of procedural instructions.
They look to be dependent on the correct sequence to operate correctly. Can
you adjust the temp before visiting the 'on' URL? Having sequence dependency
is an issue in networked apps regardless of what paradigm you are taking.
>
For me it is more program friendly to have something like:
home.server = "http://www.my-home.org/";
home.put("air-conditioning/power,"on");
home.put("air-conditioning/temp","68");
home.put("stereo/power","on");
home.put("stereo/current-album","Timeless-Serenity");
If you wanted api based access, it wouldn't be hard to define objects with
named properties where each property maps to a URI. You could then have the
client do something like:
home.airConditioner.power = "on";
home.airConditioner.temp = "68";
home.stereo.power = "on";
home.stereo.album = "Timeless-Serenity";
The benefit would be that you could also query the current values with the
same object/property structures.
I wouldn't do the 'connect-to-central-computer' because I wouldn't trust
that my-home.org would maintain that connection, or that it wouldn't crash,
etc.
> 3. Unilaterally prohibiting functions as URI-accessible makes the Web
> less friendly and useable, as I will need to contort things to get
> around this constraint. Imagine doing the above using just nouns.
I always do - its easy, very simple and powerful.
...
> Note the last element, <AddToCart href="..."/>. The URL in the href
> attribute:
>
> http://parts-depot.com/parts/00345/add-to-cart
>
> clearly contains a verb, add-to-cart.
I thought it clearly contained the verb "parts". Or maybe it was verb 345. I
forget.
>
> I have a couple of thoughts about this design:
>
> 1. If the HTTP method for the above URL is GET then it is violating the
> principle that all GETs should be side-effect free.
>
> 2. One of the principles of REST is that the client should maintain
> his/her own state. The server should not do so. The above approach has
> the server maintaining state about the client.
Yes - it looks like the add-to-cart URI doesn't know which shopping cart to
add that part to. It'd be easier to have the client explicity ask for a
shopping cart and repeatedly add (POST) part references to it. You'd get
into the non-idempotent issue though - if you POST twice, did you really
mean to add two items or was it a transmission problem? It's probably better
to just transfer a complete representation of the clients PO.
>
> Here's an alternative solution. The client creates a Purchase Order
> (PO) which identifies the parts he/she is interested in purchasing.
> When the client finds a part that he/she is interested in, the client
> will add that part number to the PO. When the client is ready he/she
> submits the PO. Some things to note:
>
> 1. The PO represents the "shopping cart".
> 2. The PO is composed on the client side, not the server side.
>
> This second design seems to be more in the spirit of REST.
>
> Those are the two ways that I see for implementing the purchase parts
> Web service. Are there other (better) ways? Any comments? /Roger
The server can maintain the PO and the client can incrementally update this.
Provide a unique identifier for it & things will be fine (other than more
messages being exchanged & idempotency issues).
Having the client accumulate a single PO with multiple line items probably
makes more sense if you can code the client yourself though. Not all
financial systems make it easy to update POs directly.
>
> I can't speak for others, but your points accurately reflected my general
> thinking. I espcially liked the www.my-home.org examples as an
application
> where action verbs are a much more natural way of modeling the system.
For me, those example are not 'natural', they are merely 'procedural'. A
noun/object/resource based approach isn't any more natural either - it is
just a different way to doing things and it has different characteristics.
Let's follow this example through.
1 Verb-oriented URLs
> For example, a program to control devices in my house might look like
this:
>
> http://www.my-home.org/connect-to-central-computer
> http://www.my-home.org/air-conditioning/on
> http://www.my-home.org/air-conditioning/adjust-temp?value=68
> http://www.my-home.org/stereo/on
> http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity
Question: by 'adjust-temp' do you mean 'add 68 degrees' or do you mean 'set
equal to 68 degrees'?
Question: how do you get the current temperature or the current album?
Additional URLs might look like:
http://www.my-home.org/disconnect-from-the-central-computer
http://www.my-home.org/stereo/powerDown
http://www.my-home.org/stereo/play-cd?cd=none
http://www.my-home.org/air-conditioning/turnOffNow
http://www.my-home.org/air-conditioning/reportTemp
2 Noun-oriented URLs
> For me it is more program friendly to have something like:
> home.server = "http://www.my-home.org/";
> home.put("air-conditioning/power,"on");
> home.put("air-conditioning/temp","68");
> home.put("stereo/power","on");
> home.put("stereo/current-album","Timeless-Serenity");
> If you wanted api based access, it wouldn't be hard to define objects with
> named properties where each property maps to a URI. You could then have
the
> client do something like:
> home.airConditioner.power = "on";
> home.airConditioner.temp = "68";
> home.stereo.power = "on";
> home.stereo.album = "Timeless-Serenity";
> > This is fine for many actions, but for many other actions, this is very awkward thinking. Any time you start with 'foo' and convert to 'bar', it's easy to say that 'bar' is awkward from the point of view of 'foo'. Rather than converting 'action' into 'noun', convert 'action' into 'noun+action'. Then see how many actions you minimally need to get the job done. Lets list these many other actions, show the two approaches and see what everybody thinks. > Few people really thinking of turning on the air > conditioning as changing the state of the AC into the "ON" state. But what about software systems? How are they best described? > Starting a race is an action that isn't naturally modeled as a "noun". The state of a race is information that isn't naturally modelled as an 'action'. > > I definitely agree that having a record created of an action as a > consequence is often useful, but doesn't necessarily make that the natural > mental model for programmers or ultimately, end-users. True - but REST isn't about procedural programming or end-users mental models, it is about large scale networked systems. RDBMS and SQL isn't all that natural for programmers and don't even try to explain it to end-users, but they still have some value.
bhaugen32 wrote: > >... > > I know. I'm afraid I expressed my question very badly. I should > have written "is there a pattern for how Web sites usually handle the > sale of downloaded products, including URIs, methods, etc."? I think that they vary widely. I think that after you do all of the negotiation and credit card stuff you should just have a "click here to download your data" (i.e. a pointer to a GET URI). You might also have a link to "click here to download your license file." The former URI is probably shared by all downloaders and the latter is specific to a particular downloader. i.e. /downloads/ourproduct.exe /license/7439239473298749328.lic Paul Prescod
On Sun, Jun 16, 2002 at 03:51:41PM -0700, Paul Prescod wrote: > I think that they vary widely. I think that after you do all of the > negotiation and credit card stuff you should just have a "click here to > download your data" (i.e. a pointer to a GET URI). You might also have a > link to "click here to download your license file." The former URI is > probably shared by all downloaders That doesn't seem very smart from a business perspective. You're talking about an information product being sold for money, right? What's to stop me from e-mailing that download URI to all my friends? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Many people think of protocols in terms of state machines and state transitions. REST doesn't encourage this. I've written an article that discusses this: http://www.prescod.net/rest/state_transition.html Paul Prescod
Matt Gushee wrote: > > On Sun, Jun 16, 2002 at 03:51:41PM -0700, Paul Prescod wrote: > > > I think that they vary widely. I think that after you do all of the > > negotiation and credit card stuff you should just have a "click here to > > download your data" (i.e. a pointer to a GET URI). You might also have a > > link to "click here to download your license file." The former URI is > > probably shared by all downloaders > > That doesn't seem very smart from a business perspective. You're talking > about an information product being sold for money, right? What's to stop > me from e-mailing that download URI to all my friends? What's to stop you from e-mailing the information you downloaded to all of your friends? Paul Prescod
On Sun, Jun 16, 2002 at 09:03:41PM -0700, Paul Prescod wrote: > > > link to "click here to download your license file." The former URI is > > > probably shared by all downloaders > > > > That doesn't seem very smart from a business perspective. You're talking > > about an information product being sold for money, right? What's to stop > > me from e-mailing that download URI to all my friends? > > What's to stop you from e-mailing the information you downloaded to all > of your friends? Ah ... you're right. Nonetheless, I see a lot of businesses obfuscating URIs or creating them for each (business) transaction, presumably so that people can't easily remember or share them. How much they really benefit from that practice I can't say, but it seems to be considered a good idea. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Paul, You are to be applauded for your tireless efforts to inform and enlighten the SOAP community, as well as the REST community. I certainly appreciate all of the articles that you have written, as well as the hundreds of email messages on the topic. Thank you. It is certainly very good news that SOAP will provide a SOAP HTTP GET, and will stop funneling all requests through a single endpoint. These changes will have a tumultuous impact on the trio of Web service technologies - SOAP, WSDL, and UDDI. While things are being shaken up... I wonder (out loud) about the virtue of SOAP bothering to continue at all? Where do we, the Web community, want to go with regards to the Web? I believe that we want to go to a place where Web messages can be understood without prior coding (i.e., my robot can travel the Web, interact with services, dynamically understand how to use the services, and dynamically understand the information that it gets back from the services). From what I have read and heard, that's where we say that we want to go. Are the current protocols: - standard addressing/naming using URI, - generic application interface using HTTP, - standard MIME Types, - Standard Representations sufficient to take us there? I assert that they are. To get to where we say that we want to go is not a matter of creating a new protocol to tunnel within existing protocols. I believe that we can get to where we want to go in a two-step process: 1. Create standard XML vocabularies for Communities of Interest (COI). This is already happening. 2. Create XML vocabularies that facilitate inferencing and discovery. RDF and DAML are nicely guiding us to this direction. Will SOAP, in any of its forms, take us to where we want to go? I do not believe so. SOAP is a detracter. It is not helping us get to where we say that we want to go. I do not see the need for SOAP, in any form. We, the Web community, need to refocus. /Roger Paul Prescod wrote: > > This is my rambling sense of the state of the debate between SOAP and > REST. > > To their credit, the SOAP working group has responded to our criticism > of the SOAP model and I think that there is a 50/50 chance that the most > severe incompatibility between the two models can be fixed over the next > while. In particular, I believe that they are coming to agree that the > "single endpoint" model is architecturally unsound. I have two reasons > to believe that this is the case. The first is that they have defined a > "GET" binding for SOAP and agreed that it should be used for any HTTP > SOAP service that has the semantics of HTTP's GET. The second is that > I've gotten generally positive agreement that the SOAP primer should > specifically say that an endpoint-per-resource model makes more . I > haven't got MUCH feedback but the feedback I've gotten so far has been > positive: > > * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jun/0036.html > > Here is the proposed text: > > "One of the principles of Web Architecture is that all important > resources should be identified by URIs. This implies that many > well-architected SOAP services will be embodied as large > numbers or resources, each with its own URI. Indeed, many > such resources are likely to be created dynamically during > operation of the service, as new information becomes available. > For example, a service offering stock prices might use > a distinct URI for each stock tracked, and perhaps for > each date and time for which quotes are provided." > > This is a non-normative change to the specification but it implies > massive changes to SOAP toolkits and to WSDL. I believe that most > existing SOAP toolkits do not allow easy implementation of this > convention. This is especially true for toolkits for statically typed > languages with "interface generators." But that's okay, because these > toolkits take their lead from WSDL, and one of the WSDL requirements > (that I proposed) also addresses this issue: > > "The description language SHOULD allow describing Messages that include > references (URIs) to strongly-typed referents, both values and > Services." > > In other words, it should be possible to have a SOAP message or HTTP > message with a URI in it that points to a SOAP/HTTP endpoint described > by another WSDL. This will at least make it possible to use WSDL in a > system where "hypermedia is the engine of application state." We should > work with the WSDL group to make sure that this happens and that > HTTP-based services are strongly represented. We should also try and > work with open source toolkit implementors to make sure that they do the > right thing as examples for the closed-source vendors. > > My current hope for the future is that a single URI will commonly > support both HTTP and SOAP methods. For instance, if you avoid the > various optional SOAP features (SOAP encoding, SOAP headers), the only > real difference between the new SOAP GET and a plain old HTTP GET is > that the one returns a SOAP-wrapped body and the other does not. > Content-negotiation could trigger which happens. (that should perhaps be > added normatively to the SOAP specification!). In many situations, you > could just accept that for marketing reasons you must wrap your XML in a > SOAP:Envelope and SOAP:Body and move on. POST is similar to GET. You can > probably just build your REST service and ignore the SOAP:Envelope and > SOAP:Body. SOAP does not define PUT or DELETE, so the "HTTP side" of a > service can use them without conflict. REST could be viewed as a sort of > best-practices for SOAP usage -- even if we're not using much of SOAP. > > Hmmmm. There should probably be a TAG ruling on whether it is > appropriate to use SOAP methods to do something that is logically > equivalent to an HTTP PUT and DELETE or whether you should just use HTTP > PUT and DELETE. It seems to me that it kind of follows naturally from > the GET decision but it might be politically harder because PUT and > DELETE are not as popular or architecturally important as GET. > > But all of this will only work if the toolkits allow it. If it is > prohibitively expensive to assign URIs to objects, or to accept *both* > HTTP and SOAP methods on the same object, we will find ourselves back at > odds with SOAP again. > > I think that pushback is quite likely because SOAP has many tensions (I > would go so far as to say contradictions) in its design. It's an RPC > protocol but not really. It's a synchronous protocol but not really. The > one that is dangerous to REST: it is a web protocol but it is also > "transport agnostic". This latter means that it could be tricky to make > a SOAP API or user interface that allows really good Web-based Web > Services and then allows you to push a button and get the same features > on MQSeries or SMTP. REST people could fantasize that this might result > in the Web model leaking onto other transports but alternately it might > mean that Web features (like SOAP GET and one-endpoint-per-resource) > just don't get implemented. > > In addition, there are all of the SOAP add-ons which will come to the > fore when SOAP is standardized. Someone will have to ensure that > WS-Security, WS-Routing, transaction standards etc. interact properly > with HTTP and Web architecture etc. Keeping up with this stuff is a > full-time job! > > In other words, there is a fight on for the Soul of SOAP -- will it be > COM for the Internet, or an XML wrapper for the Web, or something else > entirely? > > And of course there remains the issue of pre-defined methods as in HTTP > versus invent your own as in the traditional SOAP style. > > Nevertheless, the good news is that it if things go the right way, it > will be increasingly possible to tell our customers and bosses > (honestly!) that we are using SOAP and REST. Perhaps if we are vocal > enough with that message the other standards and implementations will > fall into place more easily. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"S. Mike Dierken" wrote: > > I definitely agree that having a record created of an action as a > > consequence is often useful, but doesn't necessarily make that the natural > > mental model for programmers or ultimately, end-users. > True - but REST isn't about procedural programming or end-users mental > models, it is about large scale networked systems. > RDBMS and SQL isn't all that natural for programmers and don't even try to > explain it to end-users, but they still have some value. In addition: look at all the "actions" that are also modeled as documents in every day life: In business: * orders * shipping documents of all kinds - bills of lading, notifications, etc. * receipts * transactions * journal entries * procedures, recipes, formulas, etc. In the home: * recipes * shopping lists * todo lists In social relationships: * invitations * rsvp's * love letters That's just off the top of my head. Many of these documents arose from situations somewhat like the Web: boundary crossings (or the shared domain) between one private domain and another. In other words, I don't think the techniques are all that contrary to normal human experience.
Paul Prescod wrote: > Many people think of protocols in terms of state machines and state > transitions. REST doesn't encourage this. I've written an article that > discusses this: > > http://www.prescod.net/rest/state_transition.html Paul, it's a wonderful article, but I don't get the message that "REST doesn't encourage state machines". I get the message that "REST discourages *implicit* state machines" where states are not available as Web resources. Then you go on to describe RESTful techniques for implementing state machines. I think for example that business deals are state machines, it's inescapable. Moreover, I think that your techniques can be computationally equivalent to state machines hidden behind service access points. Do you think I am missing the point, that you do really mean to discourage state-machine-thinking more generally? If not, it may be tactically better to tell people that they can solve their problem RESTfully, rather than making statements that suggest they cannot solve their problem RESTfully, in which case they will stay with SOAP. That being said, for business problems, I think it is more accurate to model the state machines as states of resources rather than states of a conversation or a process anyway. In other words, I think the way you approach it - modeling states in terms of Web resources - is better on many dimensions for business problems than the usual "state of conversation" model. For example, a purchase order as a Web resource is a collection of business commitments, which themselves can be Web resources. A PO line item is a commitment from one party to deliver some goods or services, and from the other party to pay for them. The computation of completeness (or any other interesting state) is simple via Web resources. When all of the commitments are fulfilled, the PO is complete. Computation of completeness or any other interesting state in terms of a "state of conversation" model can be very difficult, and it is easy to construct state machines that deadlock or never terminate. In general, I really like the article. There are some statements that I don't understand, though: "Business rules can be expressed in terms of the state of the transaction at a particular moment rather than in terms of the current state of the transaction." -- What's the difference? "Another nice thing is that if it makes sense for the service, the client could go back and change its existing answers merely by PUT- ting to the appropriate URIs. If you change your mind about your quest, just go in and change the data! The server is always in control of data in its namespace, however, so it could also make that URI read-only." -- I understand what you mean there, unlike the previous example. But it drives me nuts if I am reading this article as a way to implement state-dependent conversations in a RESTful manner. Changing an answer that has already conditioned further state changes could have scarey consequences. I know, that's what's bad about state dependencies in the first place, but I don't know how to eliminate them from real problems - only ways to move the complexities around so as to be more manageable. In other words, if the article is about avoiding state-dependent behavior, it's a good statement. If the article is about implementing state-dependent behavior RESTfully, it boggles my mind. Question: Is the Stateless Example similar to, a variation of, or the same as continuation passing style? But to recap, I love the article! Thanks, Bob Haugen
"Roger L. Costello" wrote: > >... > > I do not see the need for SOAP, in any form. There is no use telling people to stop working on a technology they've already invested millions in. The most we can hope for is to ensure it isn't harmful to our goals. We may also find eventually that some of the extensions to SOAP are useful: security, routing? Paul Prescod
Matt Gushee wrote: > >... > > > > What's to stop you from e-mailing the information you downloaded to all > > of your friends? > > Ah ... you're right. Nonetheless, I see a lot of businesses obfuscating > URIs or creating them for each (business) transaction, presumably so > that people can't easily remember or share them. How much they really > benefit from that practice I can't say, but it seems to be considered a > good idea. Well I did say that the download URI and license URI would usually be separate. By license URI I meant a license key that makes the download work. That key could be at a URI that only lasts for ten minutes. You could have a red flag go up if it detects multiple downloads from different IP addresses. But in the end you can only make it marginally harder to share the data. Paul Prescod
Paul Prescod wrote: > Philip Eskelin wrote: > > > >... > > > > I'm not sure where my version of this verb/URI issue stands, but > > here is the way I have designed it in my own efforts. As I mentioned > > before, I have a pre-developed set of resource types, namely methods, > > components, topics, queues, etc that are published in a node's > > hierarchical namespace. > > I guess the basic question is whether you *need* method objects. A > REST-purist view would be that you should use methods as an > implementation technique to implement a resource view of the world. > Since I don't know what method objects you have, I can't > resource-decompose them. But in most cases you will want an action to > have a side-effect that creates a resource+URI, and you will want the > newly created resource to be in some container. So you can > instead use a POST on the container. My question was "what are you posting to?" and that's where I came up with the idea of creating method resources, which have URIs (if they are published), can be invoked via POST, and need to exist in a container. GETing, PUTing, and DELETEing methods act on the resource itself. > >... > > HTTP PUT - instead of getting a pre-existing resource like the one > > above, it allows you to effectively copy a resource in its current > > state to another node. You are effectively publishing it on the > > destination node. > > It's not clear to me how you can copy a method. After all, the real > method is the programming code behind it. And that code will > depend on a complex network of other state. So PUT-ting to a method > resource doesn't make much sense to me. Sorry about that - I'll clarify. One thing I forgot to write into my original method example was a "localHost" property that references the component where the implementation of the method is hosted. So if you merely copy the method resource, it then exists in a new container but references the same implementation. So if you wanted to do what you thought I meant in your response, you would also need to copy the component to a new location, update new method's localHost URI, and integrate the new component into its environment. If the destination node was identical to the source (code doesn't always depend on a complex network of state), then it might work without modification. I agree with you, PUTing to a method resource doesn't make sense. Instead, you would want to PUT the method to a container. Is that more clear? Like Roger, I want to make sure my work reflects resolve on these issues. -Philip
I'm struggling to catchup with rest-discuss, but found one point I wanted to respond to, only to lose the message. Basically, somebody was looking for an API that fit well with REST interactions. IMO, container based component based APIs such as Java Beans 1.2 (aka Glasgow) are a pretty good fit. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Thu, Jun 13, 2002 at 11:43:32AM -0700, Joe Hsy wrote: > > 3. As a corollary to (2) use nouns in the logical URI, not verbs. > > Resources are "things" not "actions". > > URIs are like phone numbers - both are universal addressing schemes. All > I'm saying is that we shouldn't arbitrarily discourage people from modeling > "actions" as resources for those applications that makes sense. > > Buying a book is a clearly an action. You can abstract the URI into a noun > by calling it a "purchase transaction record", but to the end user pushing > the "buy" button, it is still an action. Right, but GET on that URI does not initiate the action as you might expect if it was really a verb and not a noun. I really think it just confuses things immensely to try and validate the reasons for putting a method in a URI. If it's not used as a method, then why bother trying? Perhaps I've just been doing this long enough that I never need to consider doing so. Practice makes perfect, I suppose. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Sat, Jun 15, 2002 at 12:18:30PM -0400, bhaugen32 wrote: > Downloading electronic goods is an action. Is there a common method? The one I've seen used most often (mostly on contract agreements before downloading, not purchasing) is when a POST button is selected to agree, and then the file is returned as an application/octet-stream so you automatically get the "save to file" prompt. Obviously no Content-Location header is returned. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
-----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] > For me, those example are not 'natural', they are merely 'procedural'. A > noun/object/resource based approach isn't any more natural either - it is > just a different way to doing things and it has different characteristics. I agree that what is "natural" is often a matter of opinion. And I certainly don't view these as mutually exclusive. There is no reason to be able to see it both ways as human beings do all the time. We buy our groceries and we get a receipt of the transaction. There is not conflict in that and it is good to see it both ways at the same time. I do think that in our universe of human understanding, there are certain concepts that are that more naturally a resource/noun and others that are more naturally procedural/actions. There is a reason that we have a lot of nouns in our vocabulary as well as a lot of verbs. 8-) But, you are certainly welcomed to think otherwise. I just think that REST should allow both types of thinking and that they can coexist. You give a fine example of how the home AC can be viewed both ways and that the procedural URIs are only "more natural" to the extent that we the users are thinking procedurally at remotely setting our AC. On the other hand, I see no problem that we expose both the state-oriented URLs and the action-oriented URLs at the same time, which would support both types of thinking concurrently. Maybe a better example of a more naturally action-oriented task would be driving a car. If I am driving the car, I am certainly more focused on turning right and turning left and stepping on the gas or stepping on the break, as opposed to setting the direction of the car to the left or setting the car into accelerated state or decelerated state. One could argue that computers programs at its core are more state-representational, but that doesn't not mean that we as human beings and programmers need to think that way as well. The computer can translate "turn right" into changing the steering wheel setting for us. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] > > > > This is fine for many actions, but for many other actions, this is very > > awkward thinking. > > Any time you start with 'foo' and convert to 'bar', it's easy to say that > 'bar' is awkward from the point of view of 'foo'. > Rather than converting 'action' into 'noun', convert 'action' into > 'noun+action'. Then see how many actions you minimally need to get the job > done. Again, I am by no means trying to force people to change their thinking to a more verb-oriented procedural model if they are comfortable with resource and state model. I am simply proposing that we don't limit the programmers to thinking in a noun-centric way if it makes sense to allow verbs to be part of the picture. Maybe, we can just change the recommended best practice to say that it is usually a good practice to expose states and noun resources, even if one is also exposing verb resources. Encouraging one does not have to mean eliminating the other. > Lets list these many other actions, show the two approaches and see what > everybody thinks. A few things that are very procedural would again be driving a car, cooking a rack of lamb, or flying a kite, etc. > > Few people really thinking of turning on the air > > conditioning as changing the state of the AC into the "ON" state. > But what about software systems? How are they best described? As I mentioned in the previous email, at the program level, many programs do reduce to state management problems. But, it doesn't mean people have to think that way as well. > > > I definitely agree that having a record created of an action as a > > consequence is often useful, but doesn't necessarily make that the natural > > mental model for programmers or ultimately, end-users. > True - but REST isn't about procedural programming or end-users mental > models, it is about large scale networked systems. > RDBMS and SQL isn't all that natural for programmers and don't even try to > explain it to end-users, but they still have some value. I never said that resource-modeling isn't valuable - on the contrary. I'm only saying that resource modeling isn't the *only* valuable way to do things. RDBMS and SQL is certain useful, but so are spreadsheets and web logs. If you are saying REST is not meant to support a procedural model, I will defer that question to the people defined REST and are refining REST. But if that is true, we will need an alternative architecture for the web to support the procedural programming model. On the other hand, if you are saying that large scale network systems should not support procedural programming, I have to ask why you think that is the case? I for one would still want to be able to program procedurally for large scale network applications as a complement to the resource model. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
At 03:43 AM 18/06/2002, Mark Baker wrote: >I'm struggling to catchup with rest-discuss, but found one point I >wanted to respond to, only to lose the message. Basically, somebody >was looking for an API that fit well with REST interactions. > >IMO, container based component based APIs such as Java Beans 1.2 (aka >Glasgow) are a pretty good fit. I would love to hear more detail on your experiences using this API wrt REST I have been keeping tabs on Cocoon (http://xml.apache.org/cocoon/) as a possible framework with which to build my next app. Has anyone any experience with how well Cocoon and REST fit together in real life? TIA Robert
On Mon, Jun 17, 2002 at 04:53:31PM -0700, Joe Hsy wrote: > > Lets list these many other actions, show the two approaches and see what > > everybody thinks. > > A few things that are very procedural would again be driving a car, cooking > a rack of lamb, or flying a kite, etc. Granted. But it is hard to imagine people using the web for any of these activities, literally. Do you have examples of analogous activities that would make sense as web applications? > I never said that resource-modeling isn't valuable - on the contrary. I'm > only saying that resource modeling isn't the *only* valuable way to do > things. RDBMS and SQL is certain useful, but so are spreadsheets and web > logs. I don't see how spreadsheets or weblogs demand a procedural approach. What's wrong with, e.g., PUTting an entry to http://myweblog.net/2002-06-17/mcg12 or GETting the value of http://mymoney.com/expense_record/D:22 or, for that matter, PUTting something like <add>129.95</add> to http://mymoney.com/expense_record/D:next_row Or, if being able to PUT to an arbitrary cell in a spreadsheet gives you the willies, POST to the whole spreadsheet and give the server more control over exactly where the entry goes. How would verbs in URIs simplify this? > If you are saying REST is not meant to support a procedural model, I will > defer that question to the people defined REST and are refining REST. But > if that is true, we will need an alternative architecture for the web to > support the procedural programming model. > > On the other hand, if you are saying that large scale network systems should > not support procedural programming, I have to ask why you think that is the > case? I for one would still want to be able to program procedurally for > large scale network applications as a complement to the resource model. For an authoritative answer, I will also defer to the people who defined and are refining REST. But my sense is that procedural programs tend to be fragile in a loosely-coupled distributed environment, which is what the Web has been and most people expect Web Services to be. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
-----Original Message----- From: Matt Gushee [mailto:mgushee@...] > > A few things that are very procedural would again be driving a car, cooking > > a rack of lamb, or flying a kite, etc. > > Granted. But it is hard to imagine people using the web for any of these > activities, literally. Do you have examples of analogous activities that > would make sense as web applications? By no means am I suggesting that people use the web for driving a car. 8-) No, I am simply abstracting the argument that conceptually, people think both in terms of actions and resources, and that certain concepts are better thought of as actions. Ok, let me see if I can come up with a example of a distributed application that is more naturally thought of procedurally. How about a distributed fantasy role-playing game? The players perform actions in a simulated world. This world is certainly full of noun resources and there can be URLs that refers to each player, each castle, each river, etc. But, I can also see the advantage of exposing verb URLs can be used to perform actions such as crossing a river, kill an daemon, etc. Again, I'm not saying we get rid of noun-URLs, by God we know we need them. But, let's allow the programmers to add a few verb URLs in there when it makes sense. > > I never said that resource-modeling isn't valuable - on the contrary. I'm > > only saying that resource modeling isn't the *only* valuable way to do > > things. RDBMS and SQL is certain useful, but so are spreadsheets and web > > logs. > > I don't see how spreadsheets or weblogs demand a procedural approach. I would be that last person to say that spreadsheets and weblogs represent procedural approaches. 8-) If you would reread what I wrote, I am simply replying to Mike's analogy. I was saying that that I am not arguing *against* noun-oriented URLs, but rather that we should not eliminate verb-oriented URLs. This is analogous in the same way that I would not argue against the usefulness of RDBMS, but I still think spreadsheets are useful. > For an authoritative answer, I will also defer to the people who defined > and are refining REST. But my sense is that procedural programs tend to > be fragile in a loosely-coupled distributed environment, which is what > the Web has been and most people expect Web Services to be. Procedural programming *can* be fragile, but I don't think that they necessarily have to be. Creating properties and modes that is then set by the client can also be very fragile. Fragility has less to do with being procedural or representational than whether the design is good or whether the model accurately reflects the nature of the application. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: Mark Baker [mailto:distobj@...] > Right, but GET on that URI does not initiate the action as you might > expect if it was really a verb and not a noun. I agree, and I would suggest that a GET on a verb URI should return a state as oppose to performing the action. > I really think it just confuses things immensely to try and validate > the reasons for putting a method in a URI. If it's not used as a > method, then why bother trying? Perhaps I've just been doing this long > enough that I never need to consider doing so. Practice makes perfect, > I suppose. With the recent discussion, maybe people are so used to treating URIs as representing only nouns that it isn't worth generalizing URIs as an universal addressing scheme for *anything*. I just feel that we are losing some potential interesting applications if we make this restriction and not getting much in return. Maybe at the root of what I'm trying to get at is that a method should have a URI. Why should objects get all the benefits of universal addressability and not methods? //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Joe Hsy <joe.hsy@...> wrote: > But, I can also see the advantage of exposing verb URLs can be used to > perform actions such as crossing a river, kill an daemon, etc. Again, I'm > not saying we get rid of noun-URLs, by God we know we need them. But, let's > allow the programmers to add a few verb URLs in there when it makes sense. Why wouldn't you POST what verb you're performing to the nouns? POST /daemon HTTP/1.1 Content-Type: application/rpg+xml <kill using='sword' /> This way new verbs can be created without having to add sub-resources to every noun on the server that can be affected by those verbs. Or is this too RPC-ish? Jason
-----Original Message----- From: Philip Eskelin [mailto:philip@...] > My question was "what are you posting to?" and that's where I came up with the > idea of creating method resources, which have URIs (if they are published), can > be invoked via POST, and need to exist in a container. GETing, PUTing, and > DELETEing methods act on the resource itself. This is very cool and is very much what I was getting at. I can't wait to see it. > > It's not clear to me how you can copy a method. After all, the real > > method is the programming code behind it. And that code will > > depend on a complex network of other state. So PUT-ting to a method > > resource doesn't make much sense to me. > > Sorry about that - I'll clarify. One thing I forgot to write into my original > method example was a "localHost" property that references the component where > the implementation of the method is hosted. So if you merely copy the method > resource, it then exists in a new container but references the same > implementation. > ... > I agree with you, PUTing to a method resource doesn't make sense. Instead, you > would want to PUT the method to a container. Is that more clear? Like Roger, I > want to make sure my work reflects resolve on these issues. This is an interesting concept. And I also agree that if you are trying to make "copy" the semantics of PUTing to a URI, that URI should represent a container of object for which the method would act. However, I think this creates a conflict with a normal semantics of PUTing to a noun resource. Not being certain how often one would want to copy method code to another node in this way, I would say that it might not be worth the trouble to support this semantic for PUTing to a verb/method URI. A nice idea, though. Again, please let us know when you're ready to reveal your toolkit as I am quite interested in how it works. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
>>I do not see the need for SOAP, in any form. > > > There is no use telling people to stop working on a technology they've > already invested millions in. The most we can hope for is to ensure it > isn't harmful to our goals. We may also find eventually that some of the > extensions to SOAP are useful: security, routing? I'd like to add some real world thoughts on this subject. We are developing an asynchronous communication system between a central system and many remote devices. We have to deliver this product in an almost unreal timeline. So we need to use technologies that can help us meet our goal quickly. I have, luckily, convinced everyone that using REST is the way to go. We are transporting the state of objects across the network. You won't see a single method call in the communications. (This has actually been a huge blessing, I am a 100% believer in REST for distributed systems now) Our central system is written in Java, and the remote devices are all running a C++ application. Our problem became, how do we efficiently deal with parsing and unparsing these objects for both systems? In Java, there are many XML mapping tools. In C++, we had a hard time finding libraries that would make the job of taking XML and making a C++ object out of it. I guess people just don't build distributed systems in C++ anymore. :) Anyway, I'm getting to my point. We needed some libraries to do automatic marshalling of objects from the XML. Guess what libraries do that? You got it: SOAP. SOAP libraries will take objects in your language and serialize to XML, and back again. And there are SOAP libraries for C++ (we are using gSOAP with pretty good results). We have a single method call invoked via SOAP, sync(), that exchanges objects wrapped in either a GET, PUT, or DELETE. We are essentially emulating HTTP inside our objects being passed around with SOAP. So Paul is right here. Don't go around bashing SOAP because many people use it in a IMHO doomed fashion. SOAP libraries are very useful for object marshalling/unmarshalling. It has helped us connect two very different systems, while remaining true to REST ideas. Until we can find a robust XML data binding library for C++ w/ network capabilities, we'll stick with using SOAP for that. I agree with Paul in that our job now is to show people how to use SOAP in a RESTful way. It can be done, as our product has shown how SOAP can be very useful and not harmful. Seth
Joe Hsy wrote:
> This is an interesting concept. And I also agree that if you are trying to
> make "copy" the semantics of PUTing to a URI, that URI should represent a
> container of object for which the method would act. However, I think this
> creates a conflict with a normal semantics of PUTing to a noun resource.
Yes, I agree with you. This is a concern of mine, and one of the reasons I've
asked the group about their thoughts on it. What I really wanted to do was
create a way for people to easily invoke behavior on any node accessible to
them. So here would be some example code on how that is done:
CMethod order_parts("http://www.parts-depot.com/parts/order");
CStringTable params;
params.addItem("partNumber", "01234");
order_parts.execute(params);
The above URI is clearly *not* a noun resource, unless you see the method as a
noun resource that can be invoked like a verb. Bit of a stretch. In general,
my aim is to make it easy as possible for programmers to invoke behavior in
their distributed while being as RESTful as possible. I guess what people are
advocating is something more like this:
CMethod order_parts("http://www.parts-depot.com/parts/01234");
CStringTable params;
params.addItem("action", "order")
order_parts.doPost(params);
If this is more RESTful, then it would be easy to refactor my method concept to
work this way. Is there a more RESTful way to approach this example?
> Not being certain how often one would want to copy method code to another
> node in this way, I would say that it might not be worth the trouble to
> support this semantic for PUTing to a verb/method URI. A nice idea, though.
True. It seems that the concept is more relevant to resources (nouns).
> Again, please let us know when you're ready to reveal your toolkit as I am
> quite interested in how it works.
The only thing holding me back is making sure it's coherent enough for us to
work with. Then I hope we can really sit down and hash through these concepts.
-Philip
For this example, and to make it more RESTful, I would change it to this...
OLD:
> CMethod order_parts("http://www.parts-depot.com/parts/order");
> CStringTable params;
> params.addItem("partNumber", "01234");
> order_parts.execute(params);
NEW:
Order order = new Order("http://www.parts-depot.com/orders/32432");
order.addPart( new PartNumber(01234));
// RESTful magic setting state, /NOT/ calling method
order.complete();
// The Transfer part of Representational State Transfer
transfer(order.toXML());
Notice how we just manipulate the state of the object. We do it twice,
once when we add Parts and once when we declare this order as complete.
The server does not get the new state of the order until we transfer
it (by PUTing the order on top of the old one, using the same URI).
How does the server know when to process orders? By checking the state
of the objects PUT to the server. The server has a state machine
looking for particular states of objects.
Remember, in REST you are not calling methods. You are merely
transfering the state of objects. Leave it up to the handler of the
resource to do something smart with it. It's only the client's job to
manipulate that object's state and PUT it back.
> The above URI is clearly *not* a noun resource, unless you see the method as a
> noun resource that can be invoked like a verb. Bit of a stretch. In general,
> my aim is to make it easy as possible for programmers to invoke behavior in
> their distributed while being as RESTful as possible. I guess what people are
> advocating is something more like this:
Actually, I would argue that the above URI
("http://www.parts-depot.com/parts/order/34254") *is* a noun, it's
identifying a particular order. If your aim is to make it easy for
programmers, take away method calls and actions all together. That way,
there is no API to show them or have them mess up. All they have to do
is unstand the object hierarchy of your business domain.
> CMethod order_parts("http://www.parts-depot.com/parts/01234");
> CStringTable params;
> params.addItem("action", "order")
> order_parts.doPost(params);
>
> If this is more RESTful, then it would be easy to refactor my method concept to
> work this way. Is there a more RESTful way to approach this example?
I believe my example above is more RESTful. Here you are declaring an
action to be performed on that order object. All you really want to do
is set the state of the object order to something that means "Done".
Then let the server do to it whatever it wants to.
> The only thing holding me back is making sure it's coherent enough for us to
> work with. Then I hope we can really sit down and hash through these concepts.
I think one of the key things to remember here is that you are just
transfering objects around the network. Don't try to send programatic
instructions along with the object. Let the server's state machine
handle what to do. Let your programmers just manipulate objects and
transfer them around. It greatly simplifies your API to nothing but the
object tree.
Please let me know if that makes sense, or helps you out. I believe the
only verbs you want are PUT, DELETE, and GET.
Seth
On Tue, Jun 18, 2002 at 11:55:55AM -0400, Philip Eskelin wrote:
> CMethod order_parts("http://www.parts-depot.com/parts/01234");
> CStringTable params;
> params.addItem("action", "order")
> order_parts.doPost(params);
>
> If this is more RESTful, then it would be easy to refactor my method
> concept to
> work this way. Is there a more RESTful way to approach this example?
Yes. What you and Joe have been discussing is not REST, it's RPC
with the method in the URI rather than in the body.
With REST, a common way of ordering a part would be by POSTing a
representation of that part to an order-taking container resource
that has previously advertised its role as an order-taker. Your
approach misses some critically important steps, such as the
aforementioned advertising of roles (the "offer" in "offer-
acceptance").
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
As a side note, in HTTP you can provide a header like : content-disposition: attachment; filename=suggested_name.ext for content-types other than octet-stream - this way you can indicate that the response entity body should be saved rather than rendered if it is a known content-type. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "bhaugen32" <bhaugen32@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, June 17, 2002 11:48 AM Subject: Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices] > On Sat, Jun 15, 2002 at 12:18:30PM -0400, bhaugen32 wrote: > > Downloading electronic goods is an action. Is there a common method? > > The one I've seen used most often (mostly on contract agreements > before downloading, not purchasing) is when a POST button is selected > to agree, and then the file is returned as an application/octet-stream > so you automatically get the "save to file" prompt. Obviously no > Content-Location header is returned. 8-) > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
----- Original Message ----- From: "Jason Diamond" <jason@...> > > POST /daemon HTTP/1.1 > Content-Type: application/rpg+xml > > <kill using='sword' /> > > This way new verbs can be created without having to add sub-resources to > every noun on the server that can be affected by those verbs. Or is this too > RPC-ish? This isn't RPC-ish at the 'network application' level - you are following the meaning of HTTP POST. The resource '/daemon' can represent a message queue and you are adding a message to it. This works fine, but it'll probably end up hiding some interesting things that might deserve to have URIs themselves. For example you could alternatively have: POST /world-o-hacks/region27/combatant99/ HTTP/1.1 Content-Type: application/rpg+xml <strike using='sword' />
Seth Ladd wrote:
> Order order = new Order("http://www.parts-depot.com/orders/32432");
> order.addPart( new PartNumber(01234));
>
> // RESTful magic setting state, /NOT/ calling method
> order.complete();
>
> // The Transfer part of Representational State Transfer
> transfer(order.toXML());
>
> Notice how we just manipulate the state of the object. We do it twice,
> once when we add Parts and once when we declare this order as complete.
> The server does not get the new state of the order until we transfer
> it (by PUTing the order on top of the old one, using the same URI).
Got it. I see the difference.
> How does the server know when to process orders? By checking the state
> of the objects PUT to the server. The server has a state machine
> looking for particular states of objects.
This is something that will also apply to my topic and queue abstractions. For
example, when you publish to a topic, rather than calling a "publish" method
(which was my original approach) you either PUT a representation if it's the
entire resource, or POST if the event only includes a delta of change in the
resource. GET would allow a subscriber to get a snapshot of the topic's state
upon initialization.
> The above URI is clearly *not* a noun resource, unless you see the method as a
> noun resource that can be invoked like a verb. Bit of a stretch. In general,
> my aim is to make it easy as possible for programmers to invoke behavior in
> their distributed while being as RESTful as possible. I guess what people are
> advocating is something more like this:
>
> Actually, I would argue that the above URI
> ("http://www.parts-depot.com/parts/order/34254") *is* a noun, it's
> identifying a particular order. If your aim is to make it easy for
> programmers, take away method calls and actions all together. That way,
> there is no API to show them or have them mess up. All they have to do
> is unstand the object hierarchy of your business domain.
Well, both of us are right. The original URI I specified as being a verb was
http://www.parts-depot.com/parts/order. In actuality, whether it is a noun or
verb is ambiguous. I read it as a verb, you read it as a noun. What REST does
by enforcing that you only do state transfer of noun-based objects is remove
that ambiguity. I like that - it's simpler, which is why we are here.
> > CMethod order_parts("http://www.parts-depot.com/parts/01234");
> > CStringTable params;
> > params.addItem("action", "order")
> > order_parts.doPost(params);
> >
> > If this is more RESTful, then it would be easy to refactor my method concept
to
> > work this way. Is there a more RESTful way to approach this example?
>
> I believe my example above is more RESTful. Here you are declaring an
> action to be performed on that order object. All you really want to do
> is set the state of the object order to something that means "Done".
> Then let the server do to it whatever it wants to.
Now that we've got a concrete example, I see what you mean and see what I need
to change in terms of my own thinking and how it is realized in my framework.
Wouldn't it be a tragedy if some toolkits finally emerged, only to suffer from
the *same* problems that RPC-related initiatives have.
> > The only thing holding me back is making sure it's coherent enough for us to
> > work with. Then I hope we can really sit down and hash through these
concepts.
>
> I think one of the key things to remember here is that you are just
> transfering objects around the network. Don't try to send programatic
> instructions along with the object. Let the server's state machine
> handle what to do. Let your programmers just manipulate objects and
> transfer them around. It greatly simplifies your API to nothing but the
> object tree.
>
> Please let me know if that makes sense, or helps you out. I believe the
> only verbs you want are PUT, DELETE, and GET.
Yes, it makes sense. Believe it or not, state transfer of objects around the
network is something I remember, because it was a core theme when I began
building this toolkit a few years ago. What happened to me - and I'm sure this
will be a recurring issue as REST takes hold - is that even when you have the
intention of going REST, there is a tendency to get sucked back into thinking
procedurally.
Thanks,
Philip
----- Original Message ----- From: "Joe Hsy" <joe.hsy@...> > > If you are saying REST is not meant to support a procedural model, I will > defer that question to the people defined REST and are refining REST. But > if that is true, we will need an alternative architecture for the web to > support the procedural programming model. This might be a circular argument, but the Web uses/should-use/is-defined-by REST principles. The term 'REST' explicitly means 'transfer state' - and if you use an approach to invoke arbitrary functions then it is not a 'transfer state' approach - it isn't REST. (of course, this is only my opinion). There can be value in invoking functions over a network, and there are a lot of technologies to do it (rpc, corba, dcom, xml-rpc, soap-rpc, etc.), and many make it easy to use in many languages. However, the whole REST position is that transfering state via a small number of functions is a different but fully functional approach and many believe it is better at large scales. Building more/better toolkits for invoking functions over a network is fine and there are interesting things that can be done, but that approach is fundamentally different than one where your primary goals are to transfer state and identify resources. It may be that there are some problems that are hard to cast into a resource-modelling/state-transfer approach, and I've got no problem shifting to an 'invoke function' approach for those problems, but I do have a problem with calling that approach 'web compatible' or 'part of REST' or whatever. There's nothing wrong with having networked applications 'outside the Web' or not using REST when its too hard to make a particular problem fit into the Web architecture.
----- Original Message ----- From: "Philip Eskelin" <philip@...> > > This is something that will also apply to my topic and queue abstractions. For > example, when you publish to a topic, rather than calling a "publish" method > (which was my original approach) you either PUT a representation if it's the > entire resource, or POST if the event only includes a delta of change in the > resource. GET would allow a subscriber to get a snapshot of the topic's state > upon initialization. If you are modelling messaging with resources, and the URI identifies the topic or queue, I'd use POST to 'add' a message. Doing a PUT on the topic itself would specify the complete state of the topic. If you have the URI of an individual message, then you could PUT the content of the message directly. You may want to take a look at http://www.sourceforge.net/projects/destiny/ - it was an early experiment to expose JMS via HTTP resources. An interesting issue I have with modelling queues/topics is whether you actually /can/ model a 'Queue' with HTTP. If a Queue implies only one consumer of the message at the head of the queue, how do you ensure one and only one consumer? If you made the Queue a collection, and let every consumer get a list of pending messages (a queue browser) then each consumer can directly access individual messages and perhaps use some features of HTTP to sort of lock the message. Perhaps a 'PUT' to a "message-id/lock" sub-resource, or perhaps a GET with an "if-none-match" header and using etags. I haven't had the spare time to chase this one down.
> This works fine, but it'll probably end up hiding some interesting things
> that might deserve to have URIs themselves.
> For example you could alternatively have:
>
> POST /world-o-hacks/region27/combatant99/ HTTP/1.1
> Content-Type: application/rpg+xml
>
> <strike using='sword' />
How is this different? You're just posting a different verb to a different
noun. If you wanted to give the verbs URIs (is that what you referring to?)
could you do something like this:
POST /world-o-hacks/region27/combatant99/ HTTP/1.1
Content-Type: application/rpg+xml
<action href='http://word-o-hacks/actions/strike'>
<param name='weapon' value='sword' />
</action>
That gives URIs to verbs though they don't seem all that verb-y anymore.
Jason
----- Original Message ----- > > This works fine, but it'll probably end up hiding some interesting things > > that might deserve to have URIs themselves. > > For example you could alternatively have: > > > > POST /world-o-hacks/region27/combatant99/ HTTP/1.1 > > Content-Type: application/rpg+xml > > > > <strike using='sword' /> > > How is this different? You're just posting a different verb to a different > noun. If you wanted to give the verbs URIs (is that what you referring to?) > could you do something like this: I was just contrasting the modeling the resources as a single URI that is a Queue which accepts 'command' documents, against a resource model with more fine grained resources - like individual participants. It was meant to highlight what happens when you model a system as a single queue - potentially interesting things are not accessed directly via their own URI. Not a big deal.
I would have to agree that an application to support parts inventory should
implement a whole set of noun-type resources including parts, orders,
order-takers.
I guess my question is whether we are in fact violating REST if we also
complement these resources with certain verb-resources that are in effect
"short-cuts". For example, instead of having the client create an order and
POSTing it to the order container, the URI represents a resource that in
fact creates the order and automatically sends it to the order-taker.
I am starting to realize that this may be too much of a conceptual shift to
keep clean because people automatically think RPC when it comes to verbs.
There is a subtle but fine distinction between giving "verbs" URIs and doing
RPC. RPC requires a explicit binding process to work requiring that the
parties agree on the parameters and procedure call. Verb URIs do not
require this type of tight coupling.
Giving verbs URIs is still loose coupling. It is as loose in coupling as
creating properties which has a set of acceptable values that you must set.
Ultimately, the two parties will still need to "understand" each other for
this to work, but this need for understanding is pushed out from the
protocol. And it allows certain other types of application to manipulate
these URIs without that understanding (which RPC does not support). This
loose coupling will allow verb URIs to scale in ways that RPC can not.
//Joe
-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Tuesday, June 18, 2002 10:10 AM
To: Philip Eskelin
Cc: Roger L. Costello; Joe Hsy; Paul Prescod;
rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Use verbs in URIs? [was: REST Best
Practices]
On Tue, Jun 18, 2002 at 11:55:55AM -0400, Philip Eskelin wrote:
> CMethod order_parts("http://www.parts-depot.com/parts/01234");
> CStringTable params;
> params.addItem("action", "order")
> order_parts.doPost(params);
>
> If this is more RESTful, then it would be easy to refactor my method
> concept to
> work this way. Is there a more RESTful way to approach this example?
Yes. What you and Joe have been discussing is not REST, it's RPC
with the method in the URI rather than in the body.
With REST, a common way of ordering a part would be by POSTing a
representation of that part to an order-taking container resource
that has previously advertised its role as an order-taker. Your
approach misses some critically important steps, such as the
aforementioned advertising of roles (the "offer" in "offer-
acceptance").
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
> I was just contrasting the modeling the resources as a single URI that is a > Queue which accepts 'command' documents, against a resource model with more > fine grained resources - like individual participants. > It was meant to highlight what happens when you model a system as a single > queue - potentially interesting things are not accessed directly via their > own URI. Oh. When I typed in /daemon in my previous example I was referring to Joe's example of "killing a daemon" which I took to mean some sort of malevolent creature. I see now that it could also be interpreted as some sort of server process or queue. Your example using combatant99 was much clearer in getting across what I was trying to. > Not a big deal. :-) Jason
Jason Diamond wrote:
>>This works fine, but it'll probably end up hiding some interesting things
>>that might deserve to have URIs themselves.
>>For example you could alternatively have:
>>
>>POST /world-o-hacks/region27/combatant99/ HTTP/1.1
>>Content-Type: application/rpg+xml
>>
>><strike using='sword' />
Just for the sake of illustration, here are my thoughts:
The statement we want to convey is "Seth is attacking an ogre". I can't
say "Seth is striking an ogre" because that is up to the DM (or, the
server's logic) to determine the outcome of "Seth is attacking an ogre".
In fact, in rollplaying, this is pretty much what would happen.
Anyway, the state I am in is Attacking. If the URI
http://example.org/world-o-hacks/region27/combatant99 points to Seth
(The Mighty), then I might PUT myself there, therefor updating my state:
PUT /world-o-hacks/region27/combatant99 HTTP/1.0
Content-Type: application/rpg-character+xml
<character>
<!-- what is Seth doing now? could be walking, talking, etc -->
<performing>
<attack using="sword">
<against xlink:href="http://world-o-hacks/region27/ogre/33553"
xmlns:xlink="whatever-it-is" />
</attack>
</performing>
</character
What's nice about that is the server can send back a representation of
both my character AND the ogre. I would look into the representation of
the ogre to see if damage had been done, if it is fleeing, etc.
It's all about state transfer. Kinda cool.
Seth
-----Original Message----- From: Seth Ladd [mailto:seth@...] > Remember, in REST you are not calling methods. You are merely > transferring the state of objects. Leave it up to the handler of the > resource to do something smart with it. It's only the client's job to > manipulate that object's state and PUT it back. I don't think calling methods and transferring state are necessarily mutually exclusive. Calling a method is a perfectly fine way to transfer state. If we define a URI for turning the lamp on, the "on" method transfers to the client the state of success-on or failure-off. It is really no different than POSTing "on" to the lamp's "on-or-off" property. I certainly agree that transferring state is a must for REST and have URIs for all important noun resources is a very good thing. However, to the extent that loose coupling is respected, having verb URIs (*not* RPC) to represent important actions that are stable and meaningful can also be useful as long as the state modeling and transfer is maintained. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: Seth Ladd [mailto:seth@...] > Anyway, the state I am in is Attacking. If the URI > http://example.org/world-o-hacks/region27/combatant99 points to Seth > (The Mighty), then I might PUT myself there, therefor updating my state: > > PUT /world-o-hacks/region27/combatant99 HTTP/1.0 > Content-Type: application/rpg-character+xml > > <character> > <!-- what is Seth doing now? could be walking, talking, etc --> > <performing> > <attack using="sword"> > <against xlink:href="http://world-o-hacks/region27/ogre/33553" > xmlns:xlink="whatever-it-is" /> > </attack> > </performing> > /character > > What's nice about that is the server can send back a representation of > both my character AND the ogre. I would look into the representation of > the ogre to see if damage had been done, if it is fleeing, etc. > > It's all about state transfer. Kinda cool. Excellent example! This is certainly a good way to write a RPG application in REST. However, I think we can enhance this system by judiciously adding action oriented verb URIs. Let say Seth the Mighty wants to "mental blast" all ogres within 1/2 mile. We can create an order for each ogre in the 1/2 mile radius, or we can create a temporary Ogre container that represents all ogres in 1/2 mile and send the order to that container. Both seems like a bit of work. But, if the game hoster provided a URI for Seth the Mighty that allows: http://example.org/world-o-hacks/region27/combatant99/mental-blast?radius=.5 This would be pretty convenient. The returned results could still be individual states of all the ogres in the 1/2 mile radius (as well as the current state of Seth). Of course, you can also create a "noun" URI for Seth's mental blast capability: http://example.org/world-o-hacks/region27/combatant99/mental-blast-capabilit y And then create an order with the radius property set to .5 miles and POST that order to the mental-blast-capability. But, why bother defining a mental blast order format? Not much value there. And if mental-blast-capability has state (e.g. power-level), then having a URI that point to it would make sense, otherwise we may not need that URI at all. Ultimately, for concepts for which the act is the most important (as opposed to the actor or the actee), a verb resource may be more convenient. Again it is a matter of convenience and readability - ultimately, they do still result in state changes and transfers. A few other examples may be "meditate" which could increase strength or "bathe" to increase cleanliness. 8-) //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] > This might be a circular argument, but the Web uses/should-use/is-defined-by > REST principles. > The term 'REST' explicitly means 'transfer state' - and if you use an > approach to invoke > arbitrary functions then it is not a 'transfer state' approach - it isn't > REST. (of course, this is only my opinion). Whether web and REST is synonymous is a difficult question. Even Roy admits that there are many websites that use URIs and implementations that are not RESTful. We can encourage REST, but the web is what it is warts and all. And as I replied to Seth, I don't think invoking a function or method is not mutually exclusive with transfer of state. > There can be value in invoking functions over a network, and there are a lot > of technologies to do it (rpc, corba, dcom, xml-rpc, soap-rpc, etc.), and > many make it easy to use in many languages. However, the whole REST position > is that transfering state via a small number of functions is a different but > fully functional approach and many believe it is better at large scales. I don't know if it is "fully functional" if it precludes the creation of procedural applications. And as for whether procedural applications can work at the large scale, I think that has more to do with loose coupling vs. tight coupling as opposed to procedural vs. representational. > Building more/better toolkits for invoking functions over a network is fine > and there are interesting things that can be done, but that approach is > fundamentally different than one where your primary goals are to transfer > state and identify resources. It may be that there are some problems that > are hard to cast into a resource-modeling/state-transfer approach, and I've > got no problem shifting to an 'invoke function' approach for those problems, > but I do have a problem with calling that approach 'web compatible' or 'part > of REST' or whatever. There's nothing wrong with having networked > applications 'outside the Web' or not using REST when its too hard to make a > particular problem fit into the Web architecture. This is fair enough. But where we run into problems is if want to promote REST as a better way to do web services, but then we tell people that they can't write procedural web services in REST and they must go else where if they want to write procedural web services. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Let me try reframe this discussion differently to see if we can shed a little more light on it. Many examples of RESTful application use the concept of an "order" which is posted to an "order-taker". The parts-depot accepts parts orders. The RPG game server accepts "action" orders. I submit that this is not much different than invoking a method of an object. The method is encapsulated in the XML order document which requires that the order taker understand what the methods mean for this to work. The reason this is better than RPC is that this mechanism is loosely coupled at the protocol layer, whereas RPC requires explicit bindings at the protocol layer. But, let's not deceive ourselves about the extent of the loose-coupling. It is only loosely coupled as far as generic URI manipulation is concerned (passing a link, sorting links, ranking, etc). If the RPG server stops understanding the action "attack", the clients still break. We simply moved the brittleness or fragility up to the application level where it belongs. Certain applications will remain brittle whether it is RESTful at the protocol level or not - only good design will ameliorate brittleness. REST works wonderfully in a document/data retrieval and hyperlinking application because the methods for documents and data are essentially GET, PUT, POST, and DELETE. For this specific application, those are the most important verbs. Unfortunately, this is not true for action-oriented services. Encapsulating what we want the server to *do* into an order is again simply pushing the difficulties of application-specific verbs into the application level (where I agree it belongs). However, we won't get same complete benefit that the document/data web enjoys with having the real semantics of GET, PUT, POST, DELETE be totally applicable and sufficient for that application. Let's get back to verb URIs. I think the insistence on not having verbs in URIs makes total sense for a document/data web. It doesn't make as much sense for a services-oriented web. We are already creating fragility by using verbs in the orders but we are not getting the benefit of having the verbs be addressable directly. Ultimately, if we want to push REST as a way to implement action-oriented web services, we need to extend REST to support method invocation in a consistent and convenient way. If not, we will need to have some other defining architecture which leverages URIs and loose-coupling as an alternative to RPC. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Seth Ladd wrote: > >... > > I have, luckily, convinced everyone that using REST is the way to go. Great! Keep us informed about progress and remember to use us as a resource if you need ideas. >... > Anyway, I'm getting to my point. We needed some libraries to do > automatic marshalling of objects from the XML. Guess what libraries do > that? You got it: SOAP. SOAP libraries will take objects in your > language and serialize to XML, and back again. And there are SOAP > libraries for C++ (we are using gSOAP with pretty good results). The ironic thing is that the SOAP world is moving away from the SOAP serialization and moving to XML Schema-based mappings. But you are right to use what works today and SOAP serialization works in many languages today. > ... We > have a single method call invoked via SOAP, sync(), that exchanges > objects wrapped in either a GET, PUT, or DELETE. We are essentially > emulating HTTP inside our objects being passed around with SOAP. Interesting. It's too bad you have to emulate HTTP though. One of the things we have to push SOAP, WSDL and XML Schema implementors on is modularity of implementations. You should be able to send the data over HTTP and then just hand the string to an object that deserializes it. The SOAP serialization should never have been bound (either in the specifications nor in the implementation) to the SOAP *protocol*. Paul Prescod
Joe Hsy wrote: > Many examples of RESTful application use the concept of an "order" which is > posted to an "order-taker". The parts-depot accepts parts orders. The RPG > game server accepts "action" orders. > > I submit that this is not much different than invoking a method of an > object. I'll only speak to the parts-order example. I really have no absolute objection to verbs in URIs, but an order is not the same as invoking a method on an object. There is a reason that purchase orders are documents and not remote procedure calls, and that the business protocol is called "offer- acceptance" and not "download the goods". The purchase order is an offer to buy. The seller is not required to accept it. Your credit might be bad, the seller might not have enough goods, you may want it faster than the seller can deliver, or whatever. You do not have any control over the seller. All you can do is transfer the state of your offer. I suspect this is similar to some of the other instances of verbs in URIs. A verb is not really the most accurate way to describe the situation. -Bob Haugen
-----Original Message----- From: bhaugen32 [mailto:bhaugen32@...] > The purchase order is an offer to buy. The seller is not required to > accept it. Your credit might be bad, the seller might not have enough > goods, you may want it faster than the seller can deliver, or > whatever. > > You do not have any control over the seller. All you can do is > transfer the state of your offer. > > I suspect this is similar to some of the other instances of verbs in > URIs. A verb is not really the most accurate way to describe the > situation. A good point. In this case the "verb" of this application is "offer". You are essentially invoking the "make offer" method for the offer taker. The order document is certainly essential, but it is part of the transaction. Again, I am suggesting that documents/data are important in services, but so are verbs/actions. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Joe Hsy wrote: > >... > > Many examples of RESTful application use the concept of an "order" which is > posted to an "order-taker". The parts-depot accepts parts orders. The RPG > game server accepts "action" orders. > > I submit that this is not much different than invoking a method of an > object. The method is encapsulated in the XML order document which requires > that the order taker understand what the methods mean for this to work. There are reasons that I feel that posting an proprietaryNamespace:Order this is different than calling a proprietyNamespace:method. It is because these differences are subtle that REST is NOT a no-brainer. There are kind of two phases of REST enlightenment. First you say: "we all use the same the methods so everything will just work with everything." Then you say: "No, that won't really work because some kinds of resources and representations will only work with particular other kinds of resources and representations." Then you are ready for the second phase. In the second phase we acknowledge that the world is a complicated place and total interoperability will never come for free. REST isn't going to repeal the laws of the universe and physics. We are shifting interoperability hassles from the protocol down into the representation. But this is MUCH BETTER because the representation is *already* necessarily an interoperability headache. People will quote prices in Yen, Dollars, Euros. They will use different date formats. They will use different element type names for the same thing. Adding the "operational" interoperability issues to all of these "representational" interoperability issues is a small change. Once we push all of the interoperability down into one layer (you call it the application layer but I call it the representation layer) we can use one set of tools. And the tools we have available are MUCH BETTER than the tools we have available for mapping between protocols. There is no XSLT for mapping HTTP to SMTP or vice versa. There is no RDF or DAML for protocols. The other reason it is much better to move interoperability into the representation is because it enables a wide variety of tools that don't care about the representation. URI-Browsers, caching proxies, encrypting proxies, method-triggered filters, mirroring tools, etc. You can just point these things at a set of URIs and they can do something useful without knowing anything about the XML vocabulary used. > The reason this is better than RPC is that this mechanism is loosely coupled > at the protocol layer, whereas RPC requires explicit bindings at the > protocol layer. Different people use different definitions of RPC. I think that Mark's definition is that a protocol is an RPC protocol if the definition of new methods is something routinely done by the application, rather than in a networking-specific layer. > But, let's not deceive ourselves about the extent of the loose-coupling. It > is only loosely coupled as far as generic URI manipulation is concerned > (passing a link, sorting links, ranking, etc). If the RPG server stops > understanding the action "attack", the clients still break. Okay, but in REST, the action will almost always result in a new resource that can be referenced and discussed. So you might as well call it the "submit attack request" action. i.e. POST > We simply moved the brittleness or fragility up to the application level > where it belongs. Certain applications will remain brittle whether it is > RESTful at the protocol level or not - only good design will ameliorate > brittleness. Agreed, but we have much better tools for working with brittleness in the representation layer than we do at the protocol layer. > REST works wonderfully in a document/data retrieval and hyperlinking > application because the methods for documents and data are essentially GET, > PUT, POST, and DELETE. For this specific application, those are the most > important verbs. REST is about recasting applications *into* document/data retrieval and hyperlinking applications! > Unfortunately, this is not true for action-oriented services. Encapsulating > what we want the server to *do* into an order is again simply pushing the > difficulties of application-specific verbs into the application level (where > I agree it belongs). However, we won't get same complete benefit that the > document/data web enjoys with having the real semantics of GET, PUT, POST, > DELETE be totally applicable and sufficient for that application. *Except* for performance requirements, I think you'll have a hard time demonstrating that GET/PUT/POST/DELETE are insufficient for let's say a video game. All of the same benefits accrue as with any other application of REST. Thinking about your problem in terms of document/data forces you to make URIs for objects. Doing that makes things addressable. Other benefits follow naturally. > Let's get back to verb URIs. One reason to keep verbs out of the URIs is that it then becomes implicit what object is being acted *upon*. With REST it is explicit: DELETE /foo/bar/baz I can (for example) use ACLs to turn off DELETE permission to that URI or URIs of that resource type. Now compare to: POST /foo/bar/baz?action=DELETE Now you've moved the method up into the application level and a pure-HTTP tool can't be used to secure it anymore. Now it needs to know your application semantics. That's a big part of what REST is trying to get away from. > ... I think the insistence on not having verbs in > URIs makes total sense for a document/data web. It doesn't make as much > sense for a services-oriented web. We are already creating fragility by > using verbs in the orders but we are not getting the benefit of having the > verbs be addressable directly. Who said we should use verbs in the order? Yes, the order has a vocabulary that must be negotiated, as verbs must be negotiated in an RPC system. But that doesn't mean there are verbs in the actual order. > Ultimately, if we want to push REST as a way to implement action-oriented > web services, we need to extend REST to support method invocation in a > consistent and convenient way. If not, we will need to have some other > defining architecture which leverages URIs and loose-coupling as an > alternative to RPC. Well, SOAP is moving in that direction. If all you want is to send XML to URIs, you can just send POSTs of XML. The standardization of the verbs is a big part of what makes REST REST. Paul Prescod
Joe Hsy wrote: > > In this case the "verb" of this application is "offer". You > are essentially invoking the "make offer" method for the offer taker. The > order document is certainly essential, but it is part of the transaction. No, you're POSTing the offer. The verb is POST.
-----Original Message----- From: Paul Prescod [mailto:paul@...] > In the second phase we acknowledge that the world is a complicated place > and total interoperability will never come for free. REST isn't going to > repeal the laws of the universe and physics. We are shifting > interoperability hassles from the protocol down into the representation. > ... > The other reason it is much better to move interoperability into the > representation is because it enables a wide variety of tools that don't > care about the representation. URI-Browsers, caching proxies, encrypting > proxies, method-triggered filters, mirroring tools, etc. You can just > point these things at a set of URIs and they can do something useful > without knowing anything about the XML vocabulary used. I totally agree with this and you've done a great job articulating it as usual. > Different people use different definitions of RPC. I think that Mark's > definition is that a protocol is an RPC protocol if the definition of > new methods is something routinely done by the application, rather than > in a networking-specific layer. Interesting. I was using a definition of RPC where the call and parameters must be explicitly agreed-upon. That may explain the difference in our discussion. > Okay, but in REST, the action will almost always result in a new > resource that can be referenced and discussed. So you might as well call > it the "submit attack request" action. i.e. POST This is where I think we need a little flexibility. I agree with the benefit of actions always resulting in resources or state changes, but I don't think we necessarily then have to force people to think of all actions as posting a request document. The benefits of a representational layer can be there without this restriction. > Agreed, but we have much better tools for working with brittleness in > the representation layer than we do at the protocol layer. Again, I agree completely. And I would add that representational tools can be used to model *actions* just as well as documents. I think this gives much more flexibility without sacrificing the benefits of having a representational layer. > REST is about recasting applications *into* document/data retrieval and > hyperlinking applications! I can see how this is, but I am hesitant to agree simply because I do not believe that we need to turn every problem into a document/data retrieval problem in order to enjoy the core benefits of REST. This may not be the best analogy, but I get the same feeling about this that I get from physicist that want to recast every mechanical problems into physics problems. Sure, it is possible and there may be some benefits, but it is often more work than necessary. > *Except* for performance requirements, I think you'll have a hard time > demonstrating that GET/PUT/POST/DELETE are insufficient for let's say a > video game. All of the same benefits accrue as with any other > application of REST. Thinking about your problem in terms of > document/data forces you to make URIs for objects. Doing that makes > things addressable. Other benefits follow naturally. I have no doubt that we can build video games this way, but the question is whether we would want to and do we really have to. If our goals is to encourage creating URIs for important objects and resources, we should make that the explicit goal. Forcing programmers to make everything into document/data just to accomplish this goal as a side-effect seems to be overkill. > One reason to keep verbs out of the URIs is that it then becomes > implicit what object is being acted *upon*. With REST it is explicit: > > DELETE /foo/bar/baz > > I can (for example) use ACLs to turn off DELETE permission to that URI > or URIs of that resource type. > > Now compare to: > > POST /foo/bar/baz?action=DELETE > > Now you've moved the method up into the application level and a > pure-HTTP tool can't be used to secure it anymore. Now it needs to know > your application semantics. That's a big part of what REST is trying to > get away from. This is a very good point, but think a more extensible way to create this type of benefit is to create explicit action properties for ACLs to filter. Actions can have other standard properties that may be useful filter criteria such as "security-level", "does_modify", "no-side-effect". Limiting ACL controls to only GET, PUT, POST, and DELETE seems to be much too course-grained. Furthermore, if we make actions explicit URIs, it is very simple to filter access to those actions that the administrator wants to keep out. This would seem provide more fine-grained control. In this way, the action is not being moved to the application level, but rather it creates simple implicit representation for that action in the from of an identifiable URI. > Who said we should use verbs in the order? Yes, the order has a > vocabulary that must be negotiated, as verbs must be negotiated in an > RPC system. But that doesn't mean there are verbs in the actual order. It wasn't me. 8-) But, Seth certainly had no qualms putting verbs into the order for attacking an ogre. I don't think there is anything wrong with that. BTW, how would you represent an order to attack an ogre without using any verbs? > Well, SOAP is moving in that direction. If all you want is to send XML > to URIs, you can just send POSTs of XML. The standardization of the > verbs is a big part of what makes REST REST. I like the fact that SOAP is moving away from SOAP-RPC (with explicit binding) and I think it would be very good to have SOAP be part of REST in a standard endorsed way. As for standardization of verbs, again I don't know if we're talking about application level verbs. Protocol verbs are standardized already with GET, PUT, POST, DELETE. What you're suggesting for REST is not standardizing application verbs, but recasting application verbs into representational documents which can be acted upon by the protocol verbs. If the recommendation is to always recast applications verbs into documents, I would suggest that instead of overloading the semantics of the POST verb, we explicitly define a new protocol verb called EXECUTE with its own semantics. Then it is clear that what we're doing is sending representations of actions to be executed. Again, I appreciate the efforts of you and many others on explaining the benefits. I do hope this discussion is helpful as opposed to just distracting. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: bhaugen32 [mailto:bhaugen32@...] > No, you're POSTing the offer. The verb is POST. At the protocol level, certainly we are POSTing the purchase order. But, at the application level, we are making an offer for a purchase. To use Paul's term, by recasting the offer action into a "purchase order offer document", then you can use the generic verb POST. In any case, it simply means that we can model the same transaction in both a document/data way or a procedural method-call way. They use different verbs. //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
On Tue, Jun 18, 2002 at 06:41:15PM -0400, Joe Hsy wrote: > A good point. In this case the "verb" of this application is "offer". No, POST is the verb. It's like this. If I punch you in the nose, and you bleed as a result, did I invoke your punch() or bleed() methods. Answer; I invoked punch(), and bleed() occurred as a side effect. punch <-> POST offer <-> bleed MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
-----Original Message----- From: Mark Baker [mailto:distobj@...] > No, POST is the verb. > > It's like this. If I punch you in the nose, and you bleed as a result, > did I invoke your punch() or bleed() methods. Answer; I invoked > punch(), and bleed() occurred as a side effect. > > punch <-> POST > offer <-> bleed Interesting analogy. 8-) I think we're again talking different things. To take this analogy completely: In canonical REST, you would be POSTing a "punch" action document to my nose (verb = POST) In simple English, you are *punching* my nose (verb = punch). My nose may bleeds as a side effect, possibly, but that is hardly the verb of interest here. 8-) //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Joe Hsy wrote: > From: bhaugen > > > No, you're POSTing the offer. The verb is POST. > > At the protocol level, certainly we are POSTing the purchase order. > > But, at the application level, we are making an offer for a purchase. HTTP *is* the application level. > To use Paul's term, by recasting the offer action into a "purchase order > offer document", then you can use the generic verb POST. In any case, it > simply means that we can model the same transaction in both a document/data > way or a procedural method-call way. They use different verbs. Maybe it would be good to look at this on the next layer up. There is a business protocol - offer-acceptance - riding on top of the HTTP+REST application protocol. Offer-acceptance is a conversational protocol. An offer is more like a sentence in a conversation than a procedural method-call. I follow that there is more going on in state transfers than just GET, POST, PUT, etc. And that there needs to be more layers of agreement than just the standard HTTP methods. So if that is your main point, I agree. If your point is that offer-acceptance is really a procedural method call, I disagree. -Bob Haugen
On Mon, Jun 17, 2002 at 06:08:33PM -0700, Joe Hsy wrote: > Maybe at the root of what I'm trying to get at is that a method should have > a URI. Why should objects get all the benefits of universal addressability > and not methods? This has been a very odd conversation. The answer to your question is because objects (aka resources) are what the Web chose to center itself upon. You can try and give methods URIs if you like, and perhaps you'll build something useful (I doubt it). But it won't be REST. I'm going to drop out of this now, since we've been around it several times and you still don't appear to be getting it. But best of luck figuring this out! 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark, Joe, FWIW, this kind of friction reinforces the fact that we need to get more concrete about the REST architectural style. More specifically, it reinforces that we need samples......not just the ones we're sending around on the fly to each other in this mailing list, but real coherent ones that can be compiled and tested by people who discover the approach and need them to achieve "REST Zen" [1]. Thanks, Philip [1]: "Michael Champion achieves REST Zen" from http://www.prescod.net -----Original Message----- From: Mark Baker [mailto:distobj@...] Sent: Wednesday, June 19, 2002 12:31 AM To: Joe Hsy Cc: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] REST Best Practices On Mon, Jun 17, 2002 at 06:08:33PM -0700, Joe Hsy wrote: > Maybe at the root of what I'm trying to get at is that a method should have > a URI. Why should objects get all the benefits of universal addressability > and not methods? This has been a very odd conversation. The answer to your question is because objects (aka resources) are what the Web chose to center itself upon. You can try and give methods URIs if you like, and perhaps you'll build something useful (I doubt it). But it won't be REST. I'm going to drop out of this now, since we've been around it several times and you still don't appear to be getting it. But best of luck figuring this out! 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Joe Hsy wrote: > >... > > This is where I think we need a little flexibility. I agree with the > benefit of actions always resulting in resources or state changes, but I > don't think we necessarily then have to force people to think of all actions > as posting a request document. The benefits of a representational layer can > be there without this restriction. Maybe, but it is seldom a restriction. When the semantic for something is "here, take this and give it a URI", PUT or POST seems appropriate. And if we're sending a representation and getting a URI back, then it seems natural to think of it in this way. >... > I have no doubt that we can build video games this way, but the question is > whether we would want to and do we really have to. If our goals is to > encourage creating URIs for important objects and resources, we should make > that the explicit goal. Forcing programmers to make everything into > document/data just to accomplish this goal as a side-effect seems to be > overkill. Let's be clear that a video game is a very non-typical example. It is, after all, all about verbs, because you are trying to communicate behaviour to an on-screen avatar. But think about more typical network services. Google is clearly a GET. When you send an email you are POSTing the mail to a mailbox (or mail queue). When you send an IM, you are POSTing a message. Newsreading consists of GETting posts and POSTing new ones. Stock buying, selling consists of GETting prices and POSTing orders. >... > This is a very good point, but think a more extensible way to create this > type of benefit is to create explicit action properties for ACLs to filter. That's fine if you want application-level filtering. But if you "subclass" the standard methods then you get application-agnostic filtering "for free" from standard HTTP filtering software. Then you can implement another level yourself if you want also. >... > Furthermore, if we make actions explicit URIs, it is very simple to filter > access to those actions that the administrator wants to keep out. This > would seem provide more fine-grained control. In this way, the action is > not being moved to the application level, but rather it creates simple > implicit representation for that action in the from of an identifiable URI. My sense is that you more often want to filter on the object-type/method pair. If they are both in the URI then you need to split the URI to do that. That isn't hard but again its going to be specific to your particular application and your particular way of encoding methods in URIs. > > Who said we should use verbs in the order? Yes, the order has a > > vocabulary that must be negotiated, as verbs must be negotiated in an > > RPC system. But that doesn't mean there are verbs in the actual order. > > It wasn't me. 8-) But, Seth certainly had no qualms putting verbs into the > order for attacking an ogre. Okay, I thought we were talking ordering as in ordering pizza over the Internet. > .. I don't think there is anything wrong with > that. BTW, how would you represent an order to attack an ogre without using > any verbs? I would use a verb, but use the verb as a noun. I would "POST" an action-request and the action-request might have an "action" attribute which was a verb. In that particular case yes, I've pushed a verb into the representation. But it stays there. I expect a new URI to be created that *has that verb in it*. If it is a multiplayer game, I will get everybody else in sync by pointing them at the resource I created. They will fetch the verb-containing representation and do the right thing on their screens. >... > I like the fact that SOAP is moving away from SOAP-RPC (with explicit > binding) and I think it would be very good to have SOAP be part of REST in a > standard endorsed way. As for standardization of verbs, again I don't know > if we're talking about application level verbs. Protocol verbs are > standardized already with GET, PUT, POST, DELETE. What you're suggesting > for REST is not standardizing application verbs, but recasting application > verbs into representational documents which can be acted upon by the > protocol verbs. Usually there is no need for application verbs. The protocol verbs are sufficient. Most applications are about data, not actions. > If the recommendation is to always recast applications verbs into documents, > I would suggest that instead of overloading the semantics of the POST verb, > we explicitly define a new protocol verb called EXECUTE with its own > semantics. Then it is clear that what we're doing is sending > representations of actions to be executed. But you don't have to overload. When you post an order you are really POSTing an order. When you POST a player action, the player action is really a bit of state that will be given a URI and persist. > Again, I appreciate the efforts of you and many others on explaining the > benefits. I do hope this discussion is helpful as opposed to just > distracting. I think it is helpful to clarify the ideas for everyone. Paul Prescod
----- Original Message ----- > > That's fine if you want application-level filtering. But if you > "subclass" the standard methods then you get application-agnostic > filtering "for free" from standard HTTP filtering software. Then you can > implement another level yourself if you want also. I think you may have meant override/inherit/reuse rather than "subclass" Mike "I'm not so much pedantic as I am precise" D.
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > > This has been a very odd conversation. The answer to your question is > because objects (aka resources) are what the Web chose to > center itself > upon. You can try and give methods URIs if you like, and > perhaps you'll > build something useful (I doubt it). But it won't be REST. Mark, I just reread the relevant URI chapter of Roy's thesis on REST and no where does it indicate that a resource must be an object. I still don't see a real solid reason that giving methods URIs is a bad thing, but if it is simply not REST for no particular reason other than that REST is defined to not allow it, I guess so be it. > I'm going to drop out of this now, since we've been around it several > times and you still don't appear to be getting it. But best of luck > figuring this out! 8-) Will miss your input. I will need to spend more time on other things as well. 8-) //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: Philip Eskelin [mailto:philip@...] > Mark, Joe, > > FWIW, this kind of friction reinforces the fact that we need to get more > concrete about the REST architectural style. More specifically, it reinforces > that we need samples......not just the ones we're sending around on the fly to > each other in this mailing list, but real coherent ones that can be compiled and > tested by people who discover the approach and need them to achieve "REST Zen" > [1]. Not sure friction is the best word for it, but I am learning from the discussion and it has helped clarified why I thought a certain way. More solid examples of real applications would certain be useful! Would be great to see a RPG game implemented in REST. A kind of REST Zen and the art of web maintenance. 8-) //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message----- From: Paul Prescod [mailto:paul@...] > I would use a verb, but use the verb as a noun. I would "POST" an > action-request and the action-request might have an "action" attribute > which was a verb. In that particular case yes, I've pushed a verb into > the representation. But it stays there. I expect a new URI to > be created > that *has that verb in it*. If it is a multiplayer game, I will get > everybody else in sync by pointing them at the resource I > created. They > will fetch the verb-containing representation and do the > right thing on > their screens. Paul, I agree with pretty much everything on this post, especially the example outline in the above paragraph. It is essentially the special type of example where a verb can be useful (not required, but useful). It allows the representation of the action-request to have a URI. This is kind of what I've been trying to get at from the beginning. Maybe I'm getting closer to REST Zen. 8-) //Joe This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Joe Hsy wrote: > Not sure friction is the best word for it, but I am learning from the > discussion and it has helped clarified why I thought a certain way. > More solid examples of real applications would certain be useful! > Would be great to see a RPG game implemented in REST. A kind of REST > Zen and the art of web maintenance. 8-) Maybe 'friction' is too harsh - how about 'disconnect' or 'initial misconception'. What I'm getting at is this: I can imagine that if/when REST really catches on, this topic will be a very popular one, since people (like myself) seem to have such a tendency to regress back to a procedural approach. In your last message, you mentioned that you re-read some of the dissertation and can't find any references to methods/objects. I've been re-reading it too. One thing I noticed was that in REST you have resources, and then you have representations of resources that are transferred between components. One type of component is a gateway (aka reverse proxy). This is just like CGI. Which is the source of many "verb" based designs on the web. The implication I get in this section of the document (sect 5.2.3) is that while representations of resources are transferred to user agents directly from the origin server, method invocation is encapsulated away from the origin server and behind a gateway. Do you get that implication as well? I'll keep reading and see if I can find something that more explicitly clarifies it. -Philip
Philip Eskelin wrote: > >... > > One type of component is a gateway (aka reverse proxy). This is just like CGI. > Which is the source of many "verb" based designs on the web. The implication I > get in this section of the document (sect 5.2.3) is that while representations > of resources are transferred to user agents directly from the origin server, > method invocation is encapsulated away from the origin server and behind a > gateway. Do you get that implication as well? I agree. And in fact a CGI is more REST-y if it is used to expose resources rather than used as an endpoint target for method invocations. One strong indication that Fielding et al. did not anticipate that resources would be methods is that resources are things with state. The combination of state and behaviour is commonly called an "object": "In object-oriented programming, objects include data and the procedures necessary to operate on that data." -- geez I love dictionary.com. In REST, resources have state and the procedures associated with them are exposed as HTTP methods. The state is updated or retrieved through representations. Paul Prescod
HTTP allows for proxying but once the message has gone to the first proxy the client has no more say about where it goes. SOAP Routing allows a message to be directed hop by hop from one machine to another. Rohit Khare has made the case that this is a new mechanism for assembling software. Given an existing service you can add encryption, or logging or reliable delivery or whatever by routing it. One way to do this in HTTP is to POST an HTTP message which has as its representation another HTTP message. This feels like it would work but it also feels like tunnelling HTTP over HTTP. It isn't entirely comfortable to me that I might have to POST a GET. You can do all of this at the application level, and in fact this has been done many times. For instance I can encrypt a GET by doing this: http://www.encryptionservice.com/GET=http://www.someotheruri.com And I could then add a translation service like this: http://www.encryptionservice.com/GET=http://www.translate.com/GET=http://www.sometotheruri.com (assume proper levels of escaping) But is it really right to do it all at the application level? Paul Prescod
On Wed, Jun 19, 2002 at 05:09:40AM -0400, Paul Prescod wrote: > But is it really right to do it all at the application level? The problem is that there's no convention for chaining URIs like that. But chaining URIs for routing is just one very specific way to route. There are much more general ways, several of which our software uses. One is specifying a path as a header, and using SOAP/RFC2774 to make the header mandatory for processing (or not, if you don't care). Another is to have the route specified hop-by-hop so that the initial sender doesn't have complete knowledge; pub/sub routing does this. There's a handful of other types, each specified in different ways (a good thing). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Paul Prescod wrote: > HTTP allows for proxying but once the message has gone to the first > proxy the client has no more say about where it goes. SOAP Routing > allows a message to be directed hop by hop from one machine to another. > Rohit Khare has made the case that this is a new mechanism for > assembling software. Given an existing service you can add encryption, > or logging or reliable delivery or whatever by routing it. One of the things that Fielding notes in section 5.3.1 of his dissertation is that REST's style of layered system constraints help you introduct intermediaries dynamically. If you included routing semantics for multiple hops in the body of a message, doesn't that imply that the message then relies upon the arrangement of the network to be in a certain state? It almost seems like Rohit has expanded the scope of routing to include filtering and other transformational sematics; I personally would rather keep them separate. If a client has knowledge of multiple hops of routing (in order to "route" through logging or encryption intermediaries), then you are taken away from routing being controlled hop-by-hop and handled below the application level. > One way to do this in HTTP is to POST an HTTP message which has as its > representation another HTTP message. This feels like it would work but > it also feels like tunnelling HTTP over HTTP. It isn't entirely > comfortable to me that I might have to POST a GET. I'm sure you already know this, but Fielding includes the tunnel as a type of connector. This was an explicit decision based on the fact that REST components should be free to switch from active component behavior to that of a tunnel. I like this approach, but I don't think routing semantics should be specified and/or controlled at the application level because it would seem to over-complicate dynamic rearrangement of services. Regardless of message flow, in REST I think it is important to preserve that 1) the origin server is the ultimate recipient of requests to modify the value of its resources, and 2) that the user agent is the ultimate recipient of the response. -Philip
> The ironic thing is that the SOAP world is moving away from the SOAP > serialization and moving to XML Schema-based mappings. But you are right > to use what works today and SOAP serialization works in many languages > today. Yes. There are fancy XML data binding libraries for perl, python, java... but not for C++. ugh. > Interesting. It's too bad you have to emulate HTTP though. One of the > things we have to push SOAP, WSDL and XML Schema implementors on is > modularity of implementations. You should be able to send the data over We'd love to use HTTP actually (because lots of libraries exist for that). But we have other issues that prevent us from using HTTP (as it works today). Our remote devices are all behind firewalls. When our central system wants to communicate with those devices, we have to place that message (a Request (hello HTTP)) into a store and forward system (currently a tuple space, another RESTful idea). The remote devices connects to us and downloads all pending Requests. We've basically made HTTP's Request and Response asynchronous here. And our Request object looks just like an HTTP Request, only modeled as an object. We are just PUTing things and GETing things. Really sweet, actually. More work on the server side because we have to introspect the incoming object and determine its state and what that means, but this leaves us open to great extensibility. It's easier to modify the way we look at objects and their state than to upgrade an API. Next up: using RDF to markup the incoming objects so we can start to infer things and become even more flexible about what we can accept. C'mon C++ XML toolkits! We're waiting for you! :) Seth
> A good point. In this case the "verb" of this application is "offer". You > are essentially invoking the "make offer" method for the offer taker. The > order document is certainly essential, but it is part of the transaction. I believe you want to be free of methods in a REST world. REST talks about transferring state, not requesting a service to change a state for you. The fact that a new purchase order is created (via PUT) triggers certains events on the server. You don't call "make offer" you just PUT your offer. The server then runs that offer through its state machine, giving it to listeners, etc, etc. It will then return to you a document describing the result (hopefully, a Receipt document). > Again, I am suggesting that documents/data are important in services, but so > are verbs/actions. The verbs, or actions, exist as business logic in the server. They should be called directly by clients. Two systems should not communicate via actions. They should communicate via objects/documents. That's what REST wants. Eliminate the API from the protocol. It will be easier to communicate objects (things) to other systems, not actions. Seth
>>Who said we should use verbs in the order? Yes, the order has a >>vocabulary that must be negotiated, as verbs must be negotiated in an >>RPC system. But that doesn't mean there are verbs in the actual order. > > > It wasn't me. 8-) But, Seth certainly had no qualms putting verbs into the > order for attacking an ogre. I don't think there is anything wrong with > that. BTW, how would you represent an order to attack an ogre without using > any verbs? hehe Right, I believe that Seth The Mighty would have a state of Running, or Attacking. That is what the object Seth The Mighty is doing at that point. I guess it comes down to object ownership. My idea of REST is that a system (X) can request an object (via GET) from system (Y) and receive a representation of the state of that object. That system (X) is then allowed to make changes to the object, therefor changing its state. To save that state, the system (X) then transfers the object back to the system (Y) it got it from (via PUT) thereby changing its state. In the above model, the object can be changed by (X). (Y) merely /reacts/ to any state changes of that object. In a verb centric world, where system (X) would explicitly ask system (Y) to make Seth The Mighty attack, the object is owned and controlled by system (Y). No objects were transfered, no state traveled across the network. Therefor, no REST. > If the recommendation is to always recast applications verbs into documents, > I would suggest that instead of overloading the semantics of the POST verb, > we explicitly define a new protocol verb called EXECUTE with its own > semantics. Then it is clear that what we're doing is sending > representations of actions to be executed. Ahh... excelent way to phrase what you are talking about. While that makes me understand what you want to do (think the Action pattern from GoF patterns book) I don't quite gel with that. To me, it's worked out much better to just move objects around in the space and network. So far, we've been able to have the server do things when objects meet certain states. It keeps the coupling of our different systems WAY down because now all we have to agree upon is our object hierarchy. I don't have to get on the phone and talk through our list of actions/methods/etc and the right order to call them in, etc. I just have to show them a UML diagram and say "You can send me representations of these objects. I'll do the right thing." Seth
Wow, good analogies as of late! :) >>punch <-> POST >>offer <-> bleed > > > Interesting analogy. 8-) I think we're again talking different things. To > take this analogy completely: > > In canonical REST, you would be POSTing a "punch" action document to my nose > (verb = POST) > > In simple English, you are *punching* my nose (verb = punch). > > My nose may bleeds as a side effect, possibly, but that is hardly the verb > of interest here. 8-) Ahh... reverse your thinking. In REST, you are all about transfering state. So, when you want to punch me, what are you changing? Are you changing the state of my nose to bleed, or are you changing the state of your fist to "thrust"? I would say you are PUTing a new state of your fist to the server. The server then responds with a document describing the new state of my nose (bleeding). Since you don't control me, you can only change the state of your object (to one of attacking). The server can then run through what "Joe is now attacking" means to the world. The server would then run through some business logic, and determine that you indeed hit me and I am bleeding. That is a server induced state change, which can be communicated back to you. Seth
----- Original Message ----- From: "Joe Hsy" <joe.hsy@...> > Would be great > to see a RPG game implemented in REST. A kind of REST Zen and the art of > web maintenance. 8-) I agree - an RPG would be a fun & engaging example.
> I have been keeping tabs on Cocoon (http://xml.apache.org/cocoon/) as a possible > framework with which to build my next app. Has anyone any experience with how well Cocoon > and REST fit together in real life? I've worked with Cocoon a fair bit recently, there are 3 tutorials on developerWorks that I wrote if you want some more background on it. I've been thinking along the same lines, that Cocoon and REST might go well together, but haven't had time to explore this further. It'd be nice to work through a sample REST application, nothing complex, and see how easy it is to implement in various frameworks. Cheers, L.
----- Original Message ----- From: "Joe Hsy" <joe.hsy@...> > > I still don't see > a real solid reason that giving methods URIs is a bad thing, but if it is > simply not REST for no particular reason other than that REST is defined to > not allow it, I guess so be it. If you transfer the state of the verb or method, then that is REST. If you invoke the verb, then it is RPC-ish. Hey, having a resource which is a script on a server & doing a PUT to set its contents isn't 'wrong'. Associating that script resource with a schedule or event via other HTTP methods isn't a bad idea - but I think to get the actual behavior specified by the script text to be performed, you will need a different URI. One URI for messages that act upon the content of the script and one URI for the messages that the script acts upon. I know this isn't what you mean by a URI representing a verb, but that's as close as I can get with REST.
> I've worked with Cocoon a fair bit recently, there are 3 tutorials on developerWorks > that I wrote if you want some more background on it. > > I've been thinking along the same lines, that Cocoon and REST might go well > together, but haven't had time to explore this further. > > It'd be nice to work through a sample REST application, nothing complex, > and see how easy it is to implement in various frameworks. We Cocoon a lot here, and it can accept XML documents in a POST. The one thing that is nice about Cocoon is the sitemap, which is a mapping of logical URIs to physical resources. But, as of about a month ago, you couldn't use the sitemap to look at the incoming XML to make decisions. You can match on the URI string to direct to certain physical things on the web server, but you can't use XPath on the incoming document to make those decisions. Once that happens, Cocoon will be very powerful. I'm also not sure on Cocoon's support of PUT and DELETE. I think it only handles GET and POST (since it's all build on Servlets, and they have a doService(), doGet() and a doPost()). Seth
Forwarding... ----- Original Message ----- From: "wsmeans" <smeans@...> To: <rest-explore@yahoogroups.com> Sent: Wednesday, June 19, 2002 6:13 AM Subject: [rest-explore] Heads up on REST Birds-of-a-feather gathering at SDExpo. > Since I'm unable to post to the rest-discuss list (or even find out > why I can't post), I'll post this here and hope that some of the > interested parties read it. > > The CMP Media Software Development East Conference & Expo will be > putting a REST birds-of-a-feather gathering on its calendar. I'll be > hosting it, though due more to my own desire to learn more rather > than to any particularly deep knowledge of REST lore on my part. The > precise time hasn't been set yet, but as soon as it is, I'll post it > here (assuming that I'm still able to.) The conference will be in > Boston from November 18-22. > > I'm really hoping that this will be a chance for REST advocates to > get their message a little further into the industry mainstream. > Please make a note if you're planning to attend the conference or if > you'll be in the Boston area in that timeframe. > > > > To unsubscribe from this group, send an email to: > rest-explore-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
At 02:10 AM 20/06/2002, Seth Ladd wrote: >I'm also not sure on Cocoon's support of PUT and DELETE. I think it >only handles GET and POST (since it's all build on Servlets, and they >have a doService(), doGet() and a doPost()). Servlet v2.x also has doDelete() and doPut(). Cocoon requires v2.2 so it should be able to be supported, but I don't know to what extent it actually is supported by Cocoon. Robert
I've finally read through this thread. I think that I come down in between Paul and Bob here; not that there is much of a "middle", since they're pretty close. > Paul Prescod wrote: > > Okay, let's first define transactions in the context of this > discussion > > because people often mean different things. You do not mean > transaction > > in the sense of requiring "a group of operations on (distributed) > > resources be treated as one unit of work. In a unit of work, all the > > participating operations should either succeed or fail and recover > > together." > > Oh, but I *do* mean a unit of work, in the sense of two trading > partners coming to agreement on advancing a business deal to the next > state. Each business transaction succeeds or fails as a whole. Exactly right. I do consider this a transaction. The problem with it as discussed so far, is that it isn't composable with itself, so it will only ever be good for this one task. So I think what's here is a useful start, but isn't yet the kind of thing I would call a "building block". It needs something more. Unfortunately I'm no transaction guru. But I've got an email from Mark Little in my inbox that I should get to - perhaps he has some ideas. > > > In cases where the Response document says "Accept" but has an > error, > > > and the error message from the requesting business service cannot > be > > > delivered, the transaction model specifies a separate > Notification of > > > Failure to be sent from the requesting business service via > another > > > channel. Otherwise the responding activity may think incorrectly > > > that the transaction succeeded. > > > > I see, so otherwise it is to assume the transaction succeeded if it > > returns an Accept, whether it gets a receipt or not? > > Well, it would be a bad assumption, but the end state is ambiguous, > and ambiguities are what sometimes end up in court. I don't understand this yet. How can a response document say "Accept" but have an error? And if, for the sake of argument we assume that's ok, then shouldn't it be part of the contract that the "Acceptee" catch up to state (GET) prior to proceeding with any further work? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > I've finally read through this thread. Thanks. It's just a starting place. The implications could spawn several other threads. > > Oh, but I *do* mean a unit of work, in the sense of two trading > > partners coming to agreement on advancing a business deal to the next > > state. Each business transaction succeeds or fails as a whole. > > Exactly right. I do consider this a transaction. The problem with it > as discussed so far, is that it isn't composable with itself, so it > will only ever be good for this one task. > > So I think what's here is a useful start, but isn't yet the kind of > thing I would call a "building block". It needs something more. How do you mean "composable", and what more does it need? I'm not disagreeing. The idea was meant as a toe in the door, to see if any kind of conversation-like interaction would be acceptable to the REST gurus. If so, then we'll see where it can go. Here are some possible dimensions of composability. Do you mean one of these, or something else? 1. This thread focused on offer-acceptance. But almost every business protocol I can think of has a similar kind of interaction, where both trading partners must explicitly agree on the next state of the business deal. The interaction pattern could be exactly the same. See also #2: 2. Offer-acceptance is only the beginning of a longer conversation. For example, an offer to buy, when accepted, is intended to be fulfilled and paid for. So at least two other transactions will be forthcoming: * Deliver the committed goods or services, which I will call "Notify- Comfirm". Notify is where the seller notifies the buyer that the goods or services have been delivered, to the seller's best understanding. Confirm is where the buyer either agrees or disagrees. Notify-Confirm is actually the same as offer-acceptance. Notify is equivalent to Offer, Confirm equivalent to Accept. * Pay - also a Notify-Confirm transaction. 3. The longer conversation (an economic exchange) has its own patterns. It can be orchestrated or choreographed based on the states of the resources representing the economic commmitments and fulfillment events of the business deal. In other words, when all the commitments have been fulfilled, the order is complete. (That's what a lot of business people mean by "a transaction".) 4. The whole economic exchange between two trading partners may be hyperlinked into a network of economic exchanges - a value system or supply chain. For example, if I order a computer from Dell, my economic exchange with Dell may be hyperlinked to a slot on Dell's assembly schedule, which in turn may be hyperlinked to economic exchanges with Dell's suppliers for components, etc., turtles all the way down. > Unfortunately I'm no transaction guru. Nor am I, I'm just following my nose. > But I've got an email from > Mark Little in my inbox that I should get to - perhaps he has some > ideas. If so, please pass them on. > I don't understand this yet. How can a response document say "Accept" > but have an error? Lots of ways, for example: 1. Could be too late. Offers are not good forever. The buyer needs to be able to move on to a different seller. 2. The seller could have tried to change the offer in the response document or in some other way violate the rules of the deal. 3. There could have been authorization or certificate or signature problems. Thanks for the feedback, I know you've been very busy. -Bob Haugen
On Thu, Jun 20, 2002 at 11:38:58AM -0400, bhaugen32 wrote: > How do you mean "composable", and what more does it need? I mean that it should be possible to build up more complex business level coordination from whatever we decide is a good building block. So for example, we'd be able to build a three-way producer/supplier/subordinate-supplier transaction by composing two instances of the two-party version. Give/take, and all that. P-) > 1. This thread focused on offer-acceptance. But almost every > business protocol I can think of has a similar kind of interaction, > where both trading partners must explicitly agree on the next state > of the business deal. The interaction pattern could be exactly the > same. See also #2: > > 2. Offer-acceptance is only the beginning of a longer conversation. > For example, an offer to buy, when accepted, is intended to be > fulfilled and paid for. > So at least two other transactions will be forthcoming: > * Deliver the committed goods or services, which I will call "Notify- > Comfirm". Notify is where the seller notifies the buyer that the > goods or services have been delivered, to the seller's best > understanding. Confirm is where the buyer either agrees or disagrees. > Notify-Confirm is actually the same as offer-acceptance. > Notify is equivalent to Offer, Confirm equivalent to Accept. > * Pay - also a Notify-Confirm transaction. > > 3. The longer conversation (an economic exchange) has its own > patterns. It can be orchestrated or choreographed based on the > states of the resources representing the economic commmitments and > fulfillment events of the business deal. In other words, when all > the commitments have been fulfilled, the order is complete. > (That's what a lot of business people mean by "a transaction".) > > 4. The whole economic exchange between two trading partners may be > hyperlinked into a network of economic exchanges - a value system or > supply chain. For example, if I order a computer from Dell, my > economic exchange with Dell may be hyperlinked to a slot on Dell's > assembly schedule, which in turn may be hyperlinked to economic > exchanges with Dell's suppliers for components, etc., turtles all the > way down. I think the type of composition I have in mind could be used for all of these, though I'd focus on building more generic patterns as I described above, with the hopes that it would cover off what you've written there. When I think of this stuff, I inevitably think back to Bill Mcarthy's presentation at OOPSLA '97 Business Object workshop, about REA and the various interaction patterns seen in business; http://jeffsutherland.com/oopsla97/oo97final.html Unfortunately the content of that presentation isn't available, but I remember the gist quite clearly. > > I don't understand this yet. How can a response document > say "Accept" > > but have an error? > > Lots of ways, for example: > 1. Could be too late. Offers are not good forever. The buyer needs > to be able to move on to a different seller. > 2. The seller could have tried to change the offer in the response > document or in some other way violate the rules of the deal. > 3. There could have been authorization or certificate or signature > problems. Ah, I see. So what I described would apply then; that the expectation that a fault might happen should be part of the contract, and that the sides should synch up in some manner, before proceeding past a point of no return if it turns out that this error condition did occur. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > On Thu, Jun 20, 2002 at 11:38:58AM -0400, bhaugen32 wrote: > > How do you mean "composable", and what more does it need? > > I mean that it should be possible to build up more complex business > level coordination from whatever we decide is a good building > block. > > So for example, we'd be able to build a three-way > producer/supplier/subordinate-supplier transaction by composing two > instances of the two-party version. > > Give/take, and all that. P-) See http://jeffsutherland.org/oopsla2000/mccarthy/mccarthy.htm A little out of date, but still valid. You're describing an input-process-output-exchange-input-process-etc. chain. It's the same as case #4: > > 4. The whole economic exchange between two trading partners may be > > hyperlinked into a network of economic exchanges - a value system or > > supply chain. For example, if I order a computer from Dell, my > > economic exchange with Dell may be hyperlinked to a slot on Dell's > > assembly schedule, which in turn may be hyperlinked to economic > > exchanges with Dell's suppliers for components, etc., turtles all the > > way down. > > I think the type of composition I have in mind could be used for all > of these, though I'd focus on building more generic patterns as I > described above, with the hopes that it would cover off what you've > written there. See below. > When I think of this stuff, I inevitably think back to Bill Mcarthy's > presentation at OOPSLA '97 Business Object workshop, about REA and > the various interaction patterns seen in business; > > http://jeffsutherland.com/oopsla97/oo97final.html > > Unfortunately the content of that presentation isn't available, but I > remember the gist quite clearly. Yes, I'm still working closely witb Bill, and everything I'm talking about here has his basic REA give-take pattern right in the middle of it. We also collaborated in a UN/CEFACT project entitled Business Collaboration Patterns and Monitored Commitments. My goal was to start to define the patterns you request above. The project had some problems, including my lacks of time and resources, but I think I know how to define the stuff now, although the work of clearly writing the patterns remains. One of the missing pieces was REST. I was not happy with the way ebXML did some things. REST is better. Onward! And have fun, Bob Haugen
On Thu, Jun 20, 2002 at 12:13:15PM -0400, bhaugen32 wrote: > One of the missing pieces was REST. I was not happy with the way > ebXML did some things. REST is better. Absolutely. So do you agree that the basic interaction pattern you described wasn't easily composable into more complex patterns? I'm still thinking this through, so I may have missed something. Was it a goal of that description you provided to be composable in that way? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > On Thu, Jun 20, 2002 at 12:13:15PM -0400, bhaugen32 wrote: > > One of the missing pieces was REST. I was not happy with the way > > ebXML did some things. REST is better. > > Absolutely. I should add, in case any of my ebXML buddies read this, ebXML did a lot of things right, too. That's where I learned this transaction pattern. > So do you agree that the basic interaction pattern you > described wasn't easily composable into more complex patterns? I'm > still thinking this through, so I may have missed something. Was it a > goal of that description you provided to be composable in that way? I think the transaction pattern is composable. But you do need to surround it with the resources. In other words, the transaction pattern is all about getting agreement on the state(s) of the resource (s). The resource states are the composable elements on the next layer. REA defines all the necessary resources, by the way. In this document: http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf UN/CEFACT lists 6 transaction patterns: 1. Commercial Transaction (of which Offer-Acceptance is an instance) 2. Request/Confirm 3. Query/Response 4. Request/Response 5. Notification 6. Information Distribution ...and a bunch of interaction patterns. If you look at those in detail, you'll think "EDI-mailbox-style", and you'll be right. But I learned all this stuff from yet another guy named Jim Clark, one of the designers of RosettaNet. And his goal was always to get these patterns in a way that was technology- neutral, because he did not think EDI-mailbox-style was the end of the line. Am I speaking to your composability issue adequately yet? If not, please give me more guidance. -Bob Haugen
Hi Paul, This is an interesting idea, but I think embedding the routing into the URI removes the ease of adding new "itilities" as Khare poses as one of the advantages of routing. It forces the a priori lock-in of the route upon creation of the URI. It seems to me that one of the main ideas is that you can change the route and add other interesting processing later. //Joe -----Original Message----- From: Paul Prescod [mailto:paul@...] Sent: Wednesday, June 19, 2002 2:10 AM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] HTTP and Routing HTTP allows for proxying but once the message has gone to the first proxy the client has no more say about where it goes. SOAP Routing allows a message to be directed hop by hop from one machine to another. Rohit Khare has made the case that this is a new mechanism for assembling software. Given an existing service you can add encryption, or logging or reliable delivery or whatever by routing it. One way to do this in HTTP is to POST an HTTP message which has as its representation another HTTP message. This feels like it would work but it also feels like tunnelling HTTP over HTTP. It isn't entirely comfortable to me that I might have to POST a GET. You can do all of this at the application level, and in fact this has been done many times. For instance I can encrypt a GET by doing this: http://www.encryptionservice.com/GET=http://www.someotheruri.com And I could then add a translation service like this: http://www.encryptionservice.com/GET=http://www.translate.com/GET=http://www .sometotheruri.com (assume proper levels of escaping) But is it really right to do it all at the application level? Paul Prescod To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. This email message, and any attachments to it, are for the sole use of the intended recipients, and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message or its attachments is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Short version: this is a horrible idea. Anybody else on this list been around long enough to remember the bad old days of grotty mail addresses like research!ucbvax!dagobah!td and similar? Explicit path-based addressing was a bad idea then in that context, it's a bad idea now in the context of SOAP Routing, and it's an absolutely horrendous idea to do it in the context of embedding this kind of information in URI. Also note that in *all* current successful examples of routing (at least that I can think of) there is a clear distinction between addressing and routing. It's a bad idea to embed routing information explicitly in names / addresses for all kinds of reasons, and a moments reflection on successful routing schemes will demonstrate that it's just not done. In fact, this isn't really routing at all: it's "path-based addressing." Arguments have been offered elsewhere against SOAP Routing that generally apply here as well. The short version is that path-based addressing an administrative nightmare and a reliability black hole. There are perhaps a few new arguments as well, re: the philosophy of the Web, e.g.: what exactly are you naming when you write a URI like that? There's no reason to truly "route" at *any* level (much less the application level) unless physical connectivity / topology demands it. Now, a more abstract "routing" in the sense of iterative hand-offs via 3xx and dynamic name resolution are a great idea at the application level, but that's a different beast. I'm happy to drill down on this if necessary, but I really think that can be avoided with just a bit of thought about what things would look like if this kind of idea was deployed. Ick, yuck, gag. Jb
Jeff Bone wrote: > Short version: this is a horrible idea. Anybody else on this list been > around long enough to remember the bad old days of grotty mail addresses > like > > research!ucbvax!dagobah!td +1 Seth
A RESTy design for routing is to model the forward path as a resource and *not* to model the forward path as message-in-message. Aside from being ideologically correct, you get clean separation and development simplicity. for example, to forward to Jeff via Joe: PUT or POST to joe://messages/jeff/ ...message body here as xm... From there Joe can figure out for himself how to assemble the headers. - Lucas
On 6/20/02 2:51 PM, "Lucas Gonze" <lgonze@...> wrote: > > A RESTy design for routing is to model the forward path as a resource and > *not* to model the forward path as message-in-message. Aside from being > ideologically correct, you get clean separation and development > simplicity. > > for example, to forward to Jeff via Joe: > > PUT or POST to joe://messages/jeff/ > ...message body here as xm... > >> From there Joe can figure out for himself how to assemble the headers. > > - Lucas Right. Actually, that's not just a RESTy design, that's the right way to do addressing / routing, period. The address states where you want to get to, not how you're going to get there --- that's a different job, appropriately and best handled by a different mechanism. If we've all learned anything in 20+ years of protocol design, hopefully we've learned that information spaces should be abstracted as far away as possible from the details of navigating them. Random thought: that's probably the best argument for the Axiom of Opacity that I've yet encountered, oops. ;-) Jb
Call me naive, but I have no problem with this sort of routing. We use it a *lot* here, and it works great. I think you just have to understand the limited context in which it is used/useful. Our use case is basically, I want to send a HTTP message to some server, and I specify a proxy (or proxies) through which the message first traverses. Each of those proxies has to be trusted by the party that specifies them. So, for example, we use it from our wireless browser to specify a path that includes an intermediary that converts from RIM base station ids to the soon-to-be-standardized GEO headers (http://geotags.org). We also use it for security, so that the user can "turn on" security, which basically sends messages through a proxy that wraps them up with S/MIME. "Static routing", as we refer to this, is certainly not a general routing solution. We support 3 other types of routing, for different types of integration problems. But static routing definitely has its space - it's the most common form of routing that we use, which I think says something for the needs of wireless. Other domains may use other types of routing more commonly. No surprise there, I hope. Lucas wrote; > PUT or POST to joe://messages/jeff/ > ...message body here as xm... BTW, what the heck does that mean? Are you really suggesting using a URI scheme to identify people, or am I misreading? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> "Static routing", as we refer to this, is certainly not a general > routing solution. You're a special case here. If HTTP proxies can do the job, why not. But if you think you need a protocol gateway, stop and think twice. > Lucas wrote; > > PUT or POST to joe://messages/jeff/ > > ...message body here as xm... > > BTW, what the heck does that mean? Are you really suggesting using a > URI scheme to identify people, or am I misreading? It's not identifying people so much as labelling resources by their purpose. Jeff's mailbox/ messages bound for Jeff. - Lucas
On 6/20/02 3:34 PM, "Mark Baker" <distobj@...> wrote: > Call me naive, Okay. ;-) Ugh, I had hoped that invoking the spectre of "research!ucbvax!dagobah!td" would be sufficient, but apparently not. BTW: I'm all for composition of Web-based services, but the venerable pipeline isn't the right compositional metaphor for the distributed / cross-administrative-domain case. I'll stipulate the following: "static routing" i.e. path-based addressing may well have its appropriate uses, but only in the context where the entire path is within a single administrative domain / context and only when the entire chain represents a single, synchronous end-to-end interaction. Let's drill down, using the following two analogous examples http://foo.com/GET=http://bar.com/GET=http://baz.com/stuff rsh foo.com rsh bar.com rsh baz.com cat stuff Think about all the ways these can break... (1) BRITTLE. As soon as you cross an administrative boundary, you've rendered your application hopelessly brittle. You're entirely at the mercy of the downstream hops -wrt- namespace continuity, connectivity, environment, reporting and management of your failure modes, etc. What happens if the originating client has connectivity the the third hop, but the second hop does not for some reason? (2) FAILURE MODES and SEMANTICS. What happens if the second "hop" fails? The third "hop?" What should the client see? What *can* the client know about those failures? What are the semantics of chained HTTP responses? One might argue that this is nothing more than the current chained proxy scenario, but once you introduce additional filtering / operational semantics in the intermediaries it becomes much more (IMO untenably) complex. Proxies work because they're (more or less) transparent; the entire purpose of the intermediaries in the above is to perform some function. (3) ADMINISTRATIVE / CONFIG COMPLEXITY. The administrative picture is extremely complex. You are assuming that whatever appropriate administrative relationships, etc. have been established between each intermediary and its downstream for any give pipeline. For example, you assume that bar.com knows how to transform the representation it gets from baz.com, as well as any other representation it gets. That's not a safe assumption; it will only be true with a priori arrangement / communication between baz.com and bar.com. You could automate this by way of schemas, RDDL, etc. --- but I don't see how it's realistic or desirable to embed *that* information in URI... Those comments are really just the tip of the iceberg... I *will* admit that the problems aren't as many or as serious in the case of synchronous HTTP pipelining as they are in the async case e.g. SOAP Routing. In the latter, not only have you surrendered all control of reliability, failure modes, etc. but you ALSO have *absolutely* no way of guaranteeing that you know anything at all about the state of your request once it's handed off to the first hop! Multilevel pipes just aren't appropriate in the distributed / cross-domain case. Much better to maintain local control of your app *and* your failure modes by having pairwise interactions with the services you need to interact with: Not foo | bar | baz | baf > out Rather foo > 1 bar < 1 > 2 baz < 2 > 3 baf < 3 > out With the latter, you have visibility to and control the entire execution flow and intermediate states, and can accommodate and respond to failures and exceptional conditions yourself, rather than relying on someone else to do what needs to be done. But all this is just explanatory overkill: just think research!ucbvax!dagobah!td and *shudder.* Jb
I don't have time today to get into debates about this stuff in detail. Jeff, you should probably see if you can pick a fight with Rohit because he has thought about this stuff more than I have. Nevertheless, I'll point out that this technique has been used effectively. http://web.lfw.org/math/ e.g. http://web.lfw.org/math/nph-pmpm.cgi/http://web.lfw.org/math/alvirne-28.html http://web.shodouka.com/ e.g. http://web.lfw.org/shodouka/http://www.yahoo.co.jp/ http://crit.org/ e.g. http://crit.org/http://www.erights.org/ There are basically only a few ways to compose a service and a GET. You can either do a GET that triggers another GET, or you can do the GET and then feed the data from the get into the service. The former can be done in a declarative, addresable way. The latter cannot. Paul Prescod
On 6/20/02 4:25 PM, "Paul Prescod" <paul@...> wrote: > I don't have time today to get into debates about this stuff in detail. > Jeff, you should probably see if you can pick a fight with Rohit I'm certainly not out to pick a fight with anybody; rather, my visceral reaction to this stuff stems from some really, really, really unpleasant experiences with analogous addressing / routing schemes (e.g., UUCP, e-mail) back in the day. I see no reason to believe that it will work any better in this arena than it did back then. Jb
On 6/20/02 4:25 PM, "Paul Prescod" <paul@...> wrote: > Nevertheless, I'll > point out that this technique has been used effectively. > > http://web.lfw.org/math/ > e.g. > http://web.lfw.org/math/nph-pmpm.cgi/http://web.lfw.org/math/alvirne-28.html > http://web.shodouka.com/ > e.g. http://web.lfw.org/shodouka/http://www.yahoo.co.jp/ > http://crit.org/ > e.g. http://crit.org/http://www.erights.org/ It's worth noting that there's a BIG difference between just embedding a URI within another URI and assuming that doing so in some particular way results in chained GETs. I'm all for the former; in none of the cases you mention above is it safe to assume anything like the latter. In each of these cases, you're referring to a resource in the top-level namespace. The fact that the URI contains an embedded URI is both coincidental *and* meaningless to you --- the URI is opaque, and you can't assume that it represents a pipeline construction. > There are basically only a few ways to compose a service and a GET. You > can either do a GET that triggers another GET, or you can do the GET and > then feed the data from the get into the service. The former can be done > in a declarative, addresable way. The latter cannot. This is a bit mom-and-apple-pie; sure, declarative is great, we all love declarative. But the fact that you're embedding order-dependent procedural semantics in what is otherwise a declarative medium (URI) doesn't make it any more or less declarative than if the pipeline is locally controlled / exists in some medium other than a URI. (Consider: the pipeline could be just as declaratively constructed in some XML form that is interpreted and managed locally.) I'm not opposed to pipes, Paul --- I just think it's important to realize that you need to locally control all the transitions between intermediates, rather than assume that some third party will correctly and reliably do that for you. Consider: even in the shell case of foo | bar | baz, in fact the shell is arranging the connections between them by twiddling file descriptors. Control isn't handed down the pipe. Jb
On Thu, Jun 20, 2002 at 04:01:27PM -0500, Jeff Bone wrote: > (1) BRITTLE. As soon as you cross an administrative boundary, you've Yes, that's why I said that for us, the entire chain is "trusted". > (2) FAILURE MODES and SEMANTICS. What happens if the second "hop" fails? > The third "hop?" What should the client see? What *can* the client know > about those failures? What are the semantics of chained HTTP responses? > One might argue that this is nothing more than the current chained proxy > scenario, but once you introduce additional filtering / operational > semantics in the intermediaries it becomes much more (IMO untenably) > complex. Proxies work because they're (more or less) transparent; the > entire purpose of the intermediaries in the above is to perform some > function. No, it's actually quite straightforward. We spent lots of time checking this. It works great, with very simple rules. A client only cares about the request, but debugging can occur with the Via header if required. Basically, if you use the SOAP processing model, which encapsulates proper behaviour for any intermediary, you're good. > But all this is just explanatory overkill: just think > > research!ucbvax!dagobah!td > > and *shudder.* The implementation was crappy, but the theory was good. I'm with Rohit on this. I think you'll see bang paths again. Mark "uunet|tsltor!markb" Baker -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote: > > The implementation was crappy, but the theory was good. I'm with Rohit > on this. I think you'll see bang paths again. Would somebody mind providing a pointer to Rohit's utterances on this? No longer on FoRK, and a cursory examination of the archive (subject lines only) yielded nada... As for bang paths, all I can say is I hope *you* have to administer a machine that lots of folks try to "route" through... :-P ;-) Jb
On Thu, Jun 20, 2002 at 10:12:46PM -0500, Jeff Bone wrote: > Would somebody mind providing a pointer to Rohit's utterances on this? No > longer on FoRK, and a cursory examination of the archive (subject lines > only) yielded nada... Ack. I couldn't tell you if it was said on FoRK, in private email, or in person. Basically, each name in the path would be a key fingerprint. Oh wait, I remember a FoRK email talking about "Rohit's Adam", aka <adams-fingerprint>!<rohits-fingerprint>. Relative naming. > As for bang paths, all I can say is I hope *you* have to administer a > machine that lots of folks try to "route" through... :-P ;-) I used to co-administer such a machine, snarfing maps from can.uucp.maps Ah, the good old days. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Thu, Jun 20, 2002 at 11:31:38PM -0400, Mark Baker wrote: > Basically, each name in the path would be a key fingerprint. Oh wait, > I remember a FoRK email talking about "Rohit's Adam", aka > <adams-fingerprint>!<rohits-fingerprint>. Relative naming. Oops, obviously got that backwards. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On 6/20/02 10:12 PM, "Jeff Bone" <jbone@...> wrote: > On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote: > >> >> The implementation was crappy, but the theory was good. Actually, my gut tells me that it's the theory that's crappy, and undermines some of the goodness of the Web... It seems to me that, like generic interfaces, the separation of naming and "routing" and client-local control of all interactions are essential features of the Web. I need to think more about it, though, if I'm going to make a more compelling argument than analogy to bang paths. Now, having said that, I'm *all for* composition. IMO, tho, compositional metaphors need to leave the request originator in control of the whole end-to-end interaction. I think this is essential for loose coupling, independent development, etc. All the stuff we've come to know and love. Or, if intermediaries are to control interaction, they should have *full* control of the interaction and this should be invisible to clients. I've long wanted a mechanism by which the owner of, say, foo.com could "mount up" remote pieces of URI address space in his own space, ala: http://foo.com/ bar/ --> http://bar.com baz/ --> http://baz.com Further, if foo.com provided an interface by which bar.com and baz.com could "register" themselves in foo.com's space, then you'd have some enabling technology that could help solve many problems, namely the "publish from behind the firewall" problem. Cf. old rants about "SUDS," etc. $0.02, Jb
Jeff Bone wrote: > > On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote: > > > > > The implementation was crappy, but the theory was good. I'm with Rohit > > on this. I think you'll see bang paths again. > > Would somebody mind providing a pointer to Rohit's utterances on this? http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt Paul Prescod
I was just re-visiting this and I had a question: At 05:45 PM 1/06/2002, S. Mike Dierken wrote: >Here's how I would do it:.... > >== Create a new trip === >POST http://services.travelagents.com/trips/ HTTP/1.1.... > >== Acknowledgement of submission (with location of trip) == >HTTP/1.1 202 Accepted >Location: http://services.travelagents.com/trips/0173/ Why use 202 Accepted and not 201 Created ? RFC2616 says of a 202 - "The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon...The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled." If you do use 202, should the returned location should be something like http://services.travelagents.com/status/0173/ or http://services.travelagents.com/trips/0173/status/ ? Is it acceptable to return the actual location of the trip as you have done and then have the representation at that URI initially be a status saying 'processing x% complete' and then when processing is completed the representation changes to be the actual trip? Given that this is REST then a URI is a representation of the current state of a resource, so it sounds reasonable that if the current state IS 'x% complete' then it is reasonable to return THAT as a representation, does it not? Robert
I'm thinking of using a scheme prompted by something S. Mike Dierken said regarding using etags and "if-none-match" headers. The scheme is as follows: 1. Allow subscriptions to a resource http://foo.com/bar 2. When bar changes, publish notifications to all the subscriber containing the link to bar or the diff, etc and an entity tag to be used to identify bar at that particular instance of time (i.e. the state of bar when the notification was sent). 3. If a subscriber is only interested when bar is in that particular state (think along the lines of a lock on bar as suggested by Mike) it uses the etag and an "if-match" header to ensure that a GET is only successful if bar is still in the required state (e.g. if bar is not locked). Does this sound like a reasonable strategy? The reason I ask is that it makes me feel uneasy that the client has to know that the etag is overloaded to represent state and whether to use it or not. Robert
I'm seeing more symptoms on the part of message-oriented Web services that hide their actual resources behind a single service access point and a dispatcher, that now they need to construct elaborate mechanisms for addressing those hidden resources. The popular name for these mechanisms seems to be "correlation". I think the name was coined by MSFT, but now seems to be taken up by SUN. Doesn't this smell like a kludge? Here we have a proposal for adding something called "Correlation" to ebXML Business Process Specs: http://lists.ebtwg.org/archives/ebtwg-bps/200206/msg00035.html Excerpt: "The purpose of the project is to formalize the semantics that allows two BPSS users to unambiguously carry out multiple instances of the same ... collaboration [script] with each other. Correlation is an acknowledged concept within message based collaborations, and BPSS does not currently have the capability to specify correlation. In the absence of such capability the partners are left to either operate ambiguously (and therefore inefficiently), or to devise their own way of agreeing on the correlation rules." MSFT XLang has something similar, I quote: "11. Correlation and Port References We have so far maintained the illusion that the target for the delivery of messages between XLANG services is just the WSDL port of the recipient service. The reason this is an illusion is that by their very nature, stateful services are instantiated in order to act in accordance with the history of an extended interaction. Therefore, messages sent to such services need to be delivered not only to the correct destination port, but to the correct instance of the service that defines the port. The infrastructure hosting the service needs to be able to do this in a fairly generic manner, so as to avoid burdening every service implementation with the need to implement a custom mechanism for instance routing. "Consider the usual supply chain situation where a buyer sends a purchase order to the seller. Let us suppose that the buyer and seller have a stable business relationship and are statically configured to send documents related to the purchasing interaction to the URLs associated with the relevant WSDL ports. The seller needs to return an acknowledgement for the order, and the acknowledgement must be routed to the correct service instance at the buyer. The obvious and standard mechanism to do this is to carry a token or "cookie" in the order message that is copied into the acknowledgement for correlation." I mean, if the purchase order is a Web resource with a URI, can't you just address it directly? And if you can directly address the resource you are trying to hit, would you ever need something like "correlation"? Am I missing something here? [Aside: if you can't do conversations RESTfully, or if there is some reason that you want to hide the actual resources being addressed, then you need Correlation. But of course I'm assuming here that you can and you don't.] -Bob Haugen
On 6/20/02 11:41 PM, "Paul Prescod" <paul@...> wrote: > http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt Thanks, Paul. Having now had an opportunity to parse through this presentation, it appears to me that this is consistent with Rohit's (any my own) long-time advocacy of app-level routing in general, not specifically or just Henrik's path-based addressing proposal. I've pinged Rohit to confirm this, will report back with his response. (I.e., there's a big difference between the kind of "routing" that e.g. KN does and Henrik's path-based addressing proposal.) It's important to understand that there are many and different possible formulations of app-level routing in general and HTTP routing in particular, and that the latter does not imply or require path-based addressing and route transparency on the client. Further, there are many other potential compositional metaphors, declarative and otherwise, that do not imply or require "routing" in any meaningful sense. Considering only traditional "synchronous" HTTP, some of the alternatives (non-exclusive) are: Proxying -------- The standard proxy scheme can be considered a form of routing, indeed a truly static form. While clients must have explicit knowledge of the first proxy in the chain, the proxy is otherwise transparent and their is no impact on the addressing scheme. Path-based addressing --------------------- Path-based addressing is the "bang path" style we've been discussing; the client explicitly specifies a series of intermediaries by embedding the path in an address (URI) construction. This is both inflexible and problematic, particularly when considering the issues of crossing administrative domains. Note that this *REQUIRES* URI construction and is a form of "generative naming," therefore violating the Axiom of Opacity. (For what that's worth.) On the upside, its implementation is trivial: it is merely a form of proxying where the proxy chain is explicitly specified in the URI. Destination-based addressing ---------------------------- The alternative to path-based addressing to drive routing decisions is using the destination address and assuming some underlying machinery to resolve the address route the message. HTTP currently employs this sort of scheme; the underlying machinery is DNS and the assumption, modulo "static" routes through transparent proxy chains, is direct connection between client and server. 3xx + Topology -------------- Another possible routing scheme arranges servers in a graph topology such as a Plaxton mesh, and distributes partial information (e.g. Bloom filters on per-server object hash tables) about contents across the topology to be used in routing decisions. A client is "routed" across the graph by means of 3xx redirect from each intermediate server acting on their partial routing information. Namespace Composition --------------------- Namespace composition can be considered a form of proxying where the client has no idea that proxies are involved. In this scenario, some server A "mounts" a portion of server B's namespace into A's own namespace. Requests to A for objects in that portion of its namespace are --- transparently to the client --- proxied to B, with reponses (possibly filtered or transformed) flowing back through A to the client. These are just a few of the possibilities. When you introduce asynchrony, the possibilities get even richer. My $0.02: let's not jump to the conclusion that SOAP routing == "SOAP Routing" / "WS-ROUTING" in the Henrik et. al. sense, or that routing HTTP requires path-based addressing... Jb
Yup, agree 100%. FWIW, we have some words on this on our web site; http://www.idokorro.com/routing.html We have another type since that was written last year; reverse static and dynamic routing, like WS-Refer(?), and HTTP 305 response code. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Jeff Bone wrote: > > On 6/20/02 11:41 PM, "Paul Prescod" <paul@...> wrote: > > > http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt > > Thanks, Paul. > > Having now had an opportunity to parse through this presentation, it appears > to me that this is consistent with Rohit's (any my own) long-time advocacy > of app-level routing in general, not specifically or just Henrik's > path-based addressing proposal. Sure, that doesn't mean that he disavows Henrik's proposal, which I presume came out of work the two of them did together. Path-based routing is the version that takes the most new syntax so it is what I had trouble envisioning as part of REST. I already know how the other stuff (proxies, namespace remapping, redirection, etc.) work. >... > These are just a few of the possibilities. When you introduce asynchrony, > the possibilities get even richer. My $0.02: let's not jump to the > conclusion that SOAP routing == "SOAP Routing" / "WS-ROUTING" in the Henrik > et. al. sense, or that routing HTTP requires path-based addressing... It isn't a quesion of whether "routing HTTP requires path-based addressing." It doesn't. It's a question of whether there are problems that require routing where the client specifies the list of nodes in advance and then waits for the completion of hte action. If so, what is the syntax for supporting that. If Rohit is not enamored of WS-Routing then I don't know what he sees in SOAP at all. Paul Prescod
On 6/21/02 12:04 PM, "Paul Prescod" <paul@...> wrote: > It isn't a quesion of whether "routing HTTP requires path-based > addressing." It doesn't. It's a question of whether there are problems > that require routing where the client specifies the list of nodes in > advance and then waits for the completion of hte action. If so, what is > the syntax for supporting that. Note that "client specifies list of nodes [to process intermediate states of some request]" doesn't imply or require path-based addressing, or indeed any URI syntactic solution. PBA has this insidious problem: the client specifies A/B/C and hands off to A, counting on A to hand B/C to B, and counting on B to handoff to C, and counting on the reverse. That is different from" "client calls A, gets representation Ra. Client calls B with representation Ra, getting representation Rb. Client calls C with representation Rb, getting representation Rc." It's not necessary for any "intermediary" to know about or interact with any of the others, and if you want a way to declaratively specify or refer to such a sequence of handoffs, invent and XML dialect for it. (In fact, IIRC, this is what XML Pipes etc. do, more or less.) Don't overload URIs with operational semantics. Note that the first, in addition to the problems already mentioned an in addition to introducing new syntax *and* semantics, also means that there are now not one but *two* types of HTTP URI addressible resources: the traditional kind *and* an "addressable proxy" type. Lots of new complexity, and for what purpose? There's nothing you can do with the former that you can't do with the latter --- lots of costs with the former and no clear benefits in the synchronous case. In the async / Henrik sense, it's a different story and a different argument, but with the same conclusion IMHO. > > If Rohit is not enamored of WS-Routing then I don't know what he sees in > SOAP at all. I dunno. A nice envelope? Jb
Jeff Bone wrote: > > On 6/21/02 12:04 PM, "Paul Prescod" <paul@...> wrote: > > > It isn't a quesion of whether "routing HTTP requires path-based > > addressing." It doesn't. It's a question of whether there are problems > > that require routing where the client specifies the list of nodes in > > advance and then waits for the completion of hte action. If so, what is > > the syntax for supporting that. > > Note that "client specifies list of nodes [to process intermediate states of > some request]" doesn't imply or require path-based addressing, or indeed any > URI syntactic solution. That's why I finished the sentence. By the way, chained URI-syntax was just one possible solution. As Mark said, he uses XML-based routing. > ... PBA has this insidious problem: the client > specifies A/B/C and hands off to A, counting on A to hand B/C to B, and > counting on B to handoff to C, and counting on the reverse. That is > different from" "client calls A, gets representation Ra. Client calls B > with representation Ra, getting representation Rb. Client calls C with > representation Rb, getting representation Rc." It's not necessary for any > "intermediary" to know about or interact with any of the others, and if you > want a way to declaratively specify or refer to such a sequence of handoffs, > invent and XML dialect for it. (In fact, IIRC, this is what XML Pipes etc. > do, more or less.) Don't overload URIs with operational semantics. I think that this issue of operational semantics is a red herring. Do you agree that a site could offer a service like this: http://www.math.com/sum?x=5&y=9 It returns 11. How could it then be wrong to have something like http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7 As soon as you open the door to "generative" URIs (which we agree is necessary sometimes), it becomes clear that a reference to another resource is a valid input to the first resource. If I express this in XPipe or something, I have a declarative form the result but I don't have a *globally accessible URI* for the result unless I can write the XPipe to some file somewhere. > Note that the first, in addition to the problems already mentioned an in > addition to introducing new syntax *and* semantics, also means that there > are now not one but *two* types of HTTP URI addressible resources: the > traditional kind *and* an "addressable proxy" type. Lots of new complexity, > and for what purpose? No extra complexity. It follows as naturally as: a * b a * (b + c) Paul Prescod
On 6/21/02 12:47 PM, "Paul Prescod" <paul@...> wrote: > I think that this issue of operational semantics is a red herring. Nope, it's the meat of the matter. > Do you agree that a site could offer a service like this: > > http://www.math.com/sum?x=5&y=9 > > It returns 11. How could it then be wrong to have something like > > http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7 Nothing wrong with that at all, as long as (a) math2 explicitly tells the client how to construct that URI, and (b) the client assumes nothing more about URI construction than what math2 tells it. > > As soon as you open the door to "generative" URIs (which we agree is > necessary sometimes), Wow, that's new --- I thought we disagreed about that. :-) > it becomes clear that a reference to another > resource is a valid input to the first resource. If I express this in > XPipe or something, I have a declarative form the result but I don't > have a *globally accessible URI* for the result unless I can write the > XPipe to some file somewhere. > We're *almost* in agreement. The subtle but important point that I'd like to call attention to is the fact that http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7 ...means whatever www.math2.com states / wants it to mean, whereas the "dangerous" proposal is to assume that it's "safe" to do: http://www.math2.com/power?x=5&y=GET&GET=http://www.math.com/sum?x=2+y=7 ...(or invent your own syntax) and have the client assuming that math2 is going to do the right thing. I.e., you really don't want to open the door to embedding arbitrary URIs in the query strings of other URIs and assume that the receipient is going to do the right thing. > > No extra complexity. It follows as naturally as: > > a * b > > a * (b + c) > Well, there's your problem... (* a b), (* a (+ b c)) ;-) Jb
Jeff Bone wrote: > >... > > Nothing wrong with that at all, as long as (a) math2 explicitly tells the > client how to construct that URI, and (b) the client assumes nothing more > about URI construction than what math2 tells it. Fine. > > As soon as you open the door to "generative" URIs (which we agree is > > necessary sometimes), > > Wow, that's new --- I thought we disagreed about that. :-) Nope, we disagreed on whether it was sufficient to use "?" for generative URIs or whether the all sorts of URIs should be up for "generation". >...I.e., you really don't want to open the door > to embedding arbitrary URIs in the query strings of other URIs and assume > that the receipient is going to do the right thing. Well, duh. ;) It won't work unless the server is set up to allow it to work. That's why I said in the first message of this thread that this is an *application level* convention (negotiated between applications). But clearly I wasn't clear. Mark didn't understand either. He responded "there is no standard way to do this" which to me is the same as saying it must negotiated at the application level. I'll try to be more explicit next time. Paul Prescod
Consider this argument about how "documente-oriented web services" are better than RPC interfaces (after the stuff about UDDI). If you look closely I think you'll see an inadvertent argument for REST in there.... -------- Original Message -------- Subject: RE: [e-lang] web services taking off Date: Fri, 21 Jun 2002 11:37:57 -0700 From: "Karp, Alan" <alan_karp@...> Reply-To: e-lang@...-os.org To: "'e-lang@...-os.org'" <e-lang@...-os.org> Paul Prescod wrote: > > In case you'll be working on UDDI version 3, Thankfully, no. > I hope you'll look at my > critique of UDDI here: > > * http://www.xml.com/pub/a/2002/02/06/rest.html?page=2 > > That's not all I have to say about UDDI but its a start. The question of URI versus GUID came up in every meeting I attended. There were very good reasons for not using URIs, but I'd have to dredge up my notes from 2 years ago since I can't recall the reasons now. > > Okay, but this isn't really much more than you can do with > COM -- unless > the discovery is better. Which so far it isn't but okay maybe it could > be someday. > The major difference between NOM (CORBA/DCOM/RMI) and DEM (XML based web services) is that the former is designed to encapsulate data and the latter is meant to expose it. The object model gives me access to the methods, not the data; the document model gives me access to the data, not the methods. Kevin Smathers described the difference very nicely. While you can probably think of an OO design more quickly than you can a distributed document design, (and I do agree that any good designer could do so), that view completely neglects what you are trying to get from a loosely coupled design. Data/method encapsulation is what you are trying to avoid, not what you are trying to acheive. That is because you are trying to avoid making assumptions about how your data is going to be used, and encapsulation is the means by which you create those assumptions in the semantics of the methods that modify the data. Someone providing a MIDI object for example might give it a method to load data from a stream, play the data to an instrument, and write it to disk. Since I don't own a General MIDI keyboard, I would really like to translate instrument numbers before playing them on my keyboard. With a document format it is easy for me to use stream tools like 'sed' or 'perl' to manipulate the data with minimal coding. With data encapsulation I wouldn't be able to actually get at the data except through the methods that the original programmer provided. If the programmer didn't expect me to have to modify the Instrument set, then I can't do it. The rule of XML is that I can never even guess all of the uses to which my data might be put. Loosely coupled design is about showing data, not data hiding. _________________________ Alan Karp Principal Scientist Decision Technology Department Hewlett-Packard Laboratories MS 1141 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-6278 https://ecardfile.com/id/Alan_Karp http://www.hpl.hp.com/personal/Alan_Karp/ _______________________________________________ e-lang mailing list e-lang@...-os.org http://www.eros-os.org/mailman/listinfo/e-lang
-----Original Message-----
From: Paul Prescod [mailto:paul@...]
> Kevin Smathers described the difference very nicely.
>
> While you can probably think of an OO design more quickly than you can
> a distributed document design, (and I do agree that any good designer
> could do so), that view completely neglects what you are trying to get
> from a loosely coupled design. Data/method encapsulation is what you
> are trying to avoid, not what you are trying to achieve.
I've always thought this this type of characterization of OO is rather
unfair. Encapsulation can be both a good thing and a bad thing depending on
what you're encapsulating and the nature of the application. REST uses
encapsulation to good use as well. Per Roy's thesis chapter 5.2.1 (Data
Elements):
REST therefore gains the separation of concerns of the client-server
style without
the server scalability problem, allows information hiding through a
generic interface
to enable encapsulation and evolution of services, and provides for a
diverse set
of functionality through downloadable feature-engines.
I've never viewed OO as method oriented. Objects are data as well as
associated methods. Exposing data and methods appropriately are matters of
design (good designs expose the right set). Exposing all the data all the
time isn't the point and isn't always a good idea. Likewise, I still don't
understand why just because we are dealing with a super-scale distributed
system that we should not allowing *any* object methods to be exposed.
I think having an internet-scale OO system would be a very good thing and
would quite useful. I've been trying to see if REST or some of the core
concepts of REST can be the basis of such an OO system and I still think it
can. But, if we keep insisting REST as incompatible with OO, I guess it is
a hopeless cause.
//Joe
This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
I'm not sure 202 Accepted really is the best way to do this. I'm unclear whether HTTP status codes reflect the semantics of the business document - 'add trip please' - or whether they are like a message queue - 'request added... you'll need to get the response later...' My working assumptions are that the HTTP response codes should reflect the business-level meaning. If the business-level meaning is not currently available - and there is no business level content-type indicating this, then I'd bump it down into the response code. But this is not a one-size-fits-all solution & needs to be put to practice to determine whether it is a workable solution or not. ----- Original Message ----- From: "Robert Leftwich" <robert@...> To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com> Sent: Friday, June 21, 2002 1:52 AM Subject: Re: [rest-discuss] REST and travel agents revisited > I was just re-visiting this and I had a question: > > At 05:45 PM 1/06/2002, S. Mike Dierken wrote: > > >Here's how I would do it:.... > > > >== Create a new trip === > >POST http://services.travelagents.com/trips/ HTTP/1.1.... > > > >== Acknowledgement of submission (with location of trip) == > >HTTP/1.1 202 Accepted > >Location: http://services.travelagents.com/trips/0173/ > > Why use 202 Accepted and not 201 Created ? > RFC2616 says of a 202 - "The request has been accepted for processing, but the > processing has not been completed. The request might or might not > eventually be acted upon...The entity returned with this response SHOULD > include an indication of the request's current status and either a pointer > to a status monitor or some estimate of when the user can expect the request > to be fulfilled." > > If you do use 202, should the returned location should be something like > http://services.travelagents.com/status/0173/ or > http://services.travelagents.com/trips/0173/status/ ? > Is it acceptable to return the actual location of the trip as you have done > and then have the representation at that URI initially be a status saying > 'processing x% complete' and then when processing is completed the > representation changes to be the actual trip? > Given that this is REST then a URI is a representation of the current state > of a resource, so it sounds reasonable that if the current state IS 'x% > complete' then it is reasonable to return THAT as a representation, does it not? > > Robert > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
> > If Rohit is not enamored of WS-Routing then I don't know what he sees in > SOAP at all. Money?
Mike, Robert, I would think that the simplest approach to this example (and ones like it) would be to have the response be at the semantic scope of the protocol, not at the semantic scope of any kind of business requirement. It will follow the REST philosophy better if 201 or 202 means created or accepted *at the resource/representation level* and nothing more. Given the example we're discussing here [1], the first POST is sending a representation of a new trip that is to be subordinate to the 'trip' resource , and up to the server to process accordingly. If generically (in the REST sense) a subordinate resource was created, then 201 seems most appropriate. 202 would be more appropriate if the subordinate resource was accepted by the server, but not created at the time the response was sent to the user agent. Is that a clear way of seeing it? -Philip [1] http://conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui for people new to this discussion. -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Saturday, June 22, 2002 1:40 AM To: rest-discuss@yahoogroups.com; Robert Leftwich Subject: Re: [rest-discuss] REST and travel agents revisited I'm not sure 202 Accepted really is the best way to do this. I'm unclear whether HTTP status codes reflect the semantics of the business document - 'add trip please' - or whether they are like a message queue - 'request added... you'll need to get the response later...' My working assumptions are that the HTTP response codes should reflect the business-level meaning. If the business-level meaning is not currently available - and there is no business level content-type indicating this, then I'd bump it down into the response code. But this is not a one-size-fits-all solution & needs to be put to practice to determine whether it is a workable solution or not. ----- Original Message ----- From: "Robert Leftwich" <robert@...> To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com> Sent: Friday, June 21, 2002 1:52 AM Subject: Re: [rest-discuss] REST and travel agents revisited > I was just re-visiting this and I had a question: > > At 05:45 PM 1/06/2002, S. Mike Dierken wrote: > > >Here's how I would do it:.... > > > >== Create a new trip === > >POST http://services.travelagents.com/trips/ HTTP/1.1.... > > > >== Acknowledgement of submission (with location of trip) == > >HTTP/1.1 202 Accepted > >Location: http://services.travelagents.com/trips/0173/ > > Why use 202 Accepted and not 201 Created ? > RFC2616 says of a 202 - "The request has been accepted for processing, but the > processing has not been completed. The request might or might not > eventually be acted upon...The entity returned with this response SHOULD > include an indication of the request's current status and either a pointer > to a status monitor or some estimate of when the user can expect the request > to be fulfilled." > > If you do use 202, should the returned location should be something like > http://services.travelagents.com/status/0173/ or > http://services.travelagents.com/trips/0173/status/ ? > Is it acceptable to return the actual location of the trip as you have done > and then have the representation at that URI initially be a status saying > 'processing x% complete' and then when processing is completed the > representation changes to be the actual trip? > Given that this is REST then a URI is a representation of the current state > of a resource, so it sounds reasonable that if the current state IS 'x% > complete' then it is reasonable to return THAT as a representation, does it not? > > Robert > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Mike, Robert, I think we should keep it at the semantic scope of the REST style, not cast it at the semantic scope of any kind of business domain. So 201 or 202 should indicate status relating to the resource/represtation that was created or accepted, and nothing more. Specfically, in the example [1], the user agent is POSTing a 'new trip' representation that will be subordinate to the 'trips' resource located at node 'services.travelagents.com'. What the origin server does while processing the 'new trip' representation is none of the user agent's business, above and beyond whether the subordinate resource was created or accepted by the superordinate resource. (If I'm representing (pun intended) this right, the exact details of what 'create' and/or 'accept' mean is something that, at this level, is only known by the origin server.) Now, if the subordinate resource was created, then I would think a 201 should be returned, and the Location header field should contain the URI of newly created resource. Thoughts? -Philip [1] For people new to this discussion: http://conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Saturday, June 22, 2002 1:40 AM To: rest-discuss@yahoogroups.com; Robert Leftwich Subject: Re: [rest-discuss] REST and travel agents revisited I'm not sure 202 Accepted really is the best way to do this. I'm unclear whether HTTP status codes reflect the semantics of the business document - 'add trip please' - or whether they are like a message queue - 'request added... you'll need to get the response later...' My working assumptions are that the HTTP response codes should reflect the business-level meaning. If the business-level meaning is not currently available - and there is no business level content-type indicating this, then I'd bump it down into the response code. But this is not a one-size-fits-all solution & needs to be put to practice to determine whether it is a workable solution or not. ----- Original Message ----- From: "Robert Leftwich" <robert@...> To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com> Sent: Friday, June 21, 2002 1:52 AM Subject: Re: [rest-discuss] REST and travel agents revisited > I was just re-visiting this and I had a question: > > At 05:45 PM 1/06/2002, S. Mike Dierken wrote: > > >Here's how I would do it:.... > > > >== Create a new trip === > >POST http://services.travelagents.com/trips/ HTTP/1.1.... > > > >== Acknowledgement of submission (with location of trip) == > >HTTP/1.1 202 Accepted > >Location: http://services.travelagents.com/trips/0173/ > > Why use 202 Accepted and not 201 Created ? > RFC2616 says of a 202 - "The request has been accepted for processing, but the > processing has not been completed. The request might or might not > eventually be acted upon...The entity returned with this response SHOULD > include an indication of the request's current status and either a pointer > to a status monitor or some estimate of when the user can expect the request > to be fulfilled." > > If you do use 202, should the returned location should be something like > http://services.travelagents.com/status/0173/ or > http://services.travelagents.com/trips/0173/status/ ? > Is it acceptable to return the actual location of the trip as you have done > and then have the representation at that URI initially be a status saying > 'processing x% complete' and then when processing is completed the > representation changes to be the actual trip? > Given that this is REST then a URI is a representation of the current state > of a resource, so it sounds reasonable that if the current state IS 'x% > complete' then it is reasonable to return THAT as a representation, does it not? > > Robert
On Fri, Jun 21, 2002 at 11:21:48AM -0400, bhaugen32 wrote: > Doesn't this smell like a kludge? Most definitely. In the WSAWG, WS-Inspection was recently discussed; it's another complete kludge, attempting to solve the bootstrapping problem when you haven't agreed to any application semantic a priori (but of course, it only lets you find out what you have no possibility of discovering for yourself - the methods in the WSDL - unless you already expected it). FWIW, my rule of thumb for Web services specs is, if Henrik's name is on it, it's good, otherwise it's crap. So far, that's held up every time I've applied it. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote: > REST folk should find this interesting, imho... Yay, verbs in POST bodies *and* URIs. Woohoo! One of the "good" things about SOAP - or so I thought - was that it would act as a magnet for everybody wanting to do RPC, permitting their stuff to be nicely isolated from the rest of the Web (for later extermination, of course 8-). Let's hope that this practice of not using SOAP for all your RPC needs, doesn't catch on. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > > On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote: > > REST folk should find this interesting, imho... > > Yay, verbs in POST bodies *and* URIs. Woohoo! I think that people who do this sort of thing are often trying to do the right thing and just need a little direction. The REST world has not provided sufficient direction yet so we can't really blame them. Paul Prescod
On Tue, Jun 25, 2002 at 02:17:32PM -0700, Paul Prescod wrote: > I think that people who do this sort of thing are often trying to do the > right thing and just need a little direction. The REST world has not > provided sufficient direction yet so we can't really blame them. Oh, of course. I'm just mocking them. But FWIW, I'm sure Web services folks are trying to do the right thing too, but that doesn't mean you'll be met with open arms when you try to tell them how to do it properly (especially if you phrase it that way 8-). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
The title says it all really - what is the list of books that no REST-er should be without? Robert
I was reading the Http Events spec (http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents) again and went looking on rest-discuss for clarification of the 'Watched-URI: (URI of the watched resource)' and 'Subscription-URI: URI of the subscription object ' notification message headers. I found the discussion starting at http://groups.yahoo.com/group/rest-discuss/message/704 which ends up with Paul suggesting the following changes, among others: "A notification message MAY have the following headers: Watched-URI: (URI of the watched resource) The Watched-URI may be any valid URI for the resource that generated the notification. It need not be the original URI but it must refer to the same resource. If the client wants to retrieve a representation of the resource it SHOULD use this URI, not the original one. This will allow publishers to do a simple form of load balancing." What is the status of these changes and is the 'Subscription-URI: URI of the subscription object ' the URI of the subscription resource returned as a 'Location' header in the subscription response? Robert
Yes, those changes just never got added because I got busy with another project. Please feel free to add them. Robert Leftwich wrote: > > I was reading the Http Events spec (http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents) again and went looking on rest-discuss for clarification of the 'Watched-URI: (URI of the watched resource)' and 'Subscription-URI: URI of the subscription object ' notification message headers. I found the discussion starting at http://groups.yahoo.com/group/rest-discuss/message/704 which ends up with Paul suggesting the following changes, among others: > > "A notification message MAY have the following headers: > > Watched-URI: (URI of the watched resource) > > The Watched-URI may be any valid URI for the resource that generated the > notification. It need not be the original URI but it must refer to the > same resource. If the client wants to retrieve a representation of the > resource it SHOULD use this URI, not the original one. This will allow > publishers to do a simple form of load balancing." > > What is the status of these changes and is the 'Subscription-URI: URI of the subscription object ' the URI of the subscription resource returned as a 'Location' header in the subscription response? > > Robert > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
(sorry, had email troubles and just got this one) On Sat, Jun 22, 2002 at 01:45:02AM -0400, S. Mike Dierken wrote: > > > > If Rohit is not enamored of WS-Routing then I don't know what he sees > in > > SOAP at all. > > Money? Heh. Well, WS-Routing is just a small piece of the bigger routing picture with REST/ALIN. For the kinds of things Rohit wants to do, WS-Routing is mostly inappropriate. But the other types of ad-hoc routing (pub/sub, primarily) is what he's interested in (me too, actually). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
HI I saw this[1] in one of the weblogs I constantly watch. thought i'd post here... --Dilip [1] http://www.dotnetremoting.cc/DotNetCentric/2002/06/24.html#a222
Here's an example of industry mag discussing correct usage of HTTP GET .vs. POST - but in the end is foiled by poor implementation. This is from an XML/MS-SQL column. -- http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=19852 "[...] The method attribute's values on the form tag specify the HTTP verb to use when you're sending the request to the Web server. You use the GET verb for requests to the server that don't involve changes to data-or, more generally, state-on the server. You use POST when data-or state-changes. When you're performing database operations, you use GET when you're querying data and POST when you're inserting, updating, or deleting data." [...] "SQL Server 2000's ISAPI DLL incorrectly interprets an HTML form that uses method="POST" as posting a template or updategram. Instead, the ISAPI DLL should allow this type of message if you've enabled the Allow template queries setting. The best workaround is to use the GET method, although this approach limits the amount of data that someone can post to the server to the length of a URL (2083 characters if you're using Microsoft Internet Explorer-IE-5.0). Another workaround is to use the Allow POST setting, but you would need to make sure that you carefully controlled permissions on the virtual root to ensure that a posted template couldn't damage your system. Microsoft recently released XML for SQL Server 2000 Web Release 1, which includes additional configuration options to the ISAPI DLL that fix this bug. "
--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote: On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote: > REST folk should find this interesting, imho... > Yay, verbs in POST bodies *and* URIs. Woohoo! Having a very peripheral involvement in developing this protocol, I would welcome the group's help in proposing changes to make it more REST like. This paper , http://arxiv.org/abs/cs.DL/0205071 , indicates the direction in which this protocol is heading. The establishment of a separate architecture for proxies and caching doesn't seem to make sense to me at all. Bill Oldroyd The British Library
Robert Leftwich wrote: > > The title says it all really - what is the list of books that no REST-er should be without? A good understanding of HTTP I think is important. Here's a wonderful book on HTTP: HTTP Essentials, Protocols for Secure, Scalable Web Sites You need some language to implement your Web services. If you are using Java then I highly recommend this book: Inside Servlets, 2nd Edition by Dustin R. Calloway /Roger
Let's imagine the perfect REST toolkit. Would it be built upon an HTTP infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as well as I should or will. But I'm thinking that for instance it could be useful for all REST applications to support WebDAV's notion of collections so that you would get compatibility with WebDAV collection management tools "for free". If a REST app has to do locking, it might as well use WebDAV locking. If it has to do object versioning, it might as well use WebDAV versioning. Opinions? Let's presume I'm right. If you were building a REST app today, is there a good WebDAV toolkit out there that is especially designed to be really easy to extend? Zope? 4Suite? Something in Java? mod_dav? Paul Prescod
Some rough thoughts about a question I got from a client: * http://www.prescod.net/rest/restmail/ Paul
On 6/28/02 1:06 PM, "Paul Prescod" <paul@...> wrote: > Some rough thoughts about a question I got from a client: > > * http://www.prescod.net/rest/restmail/ > > Paul, This is good stuff. I've been thinking about this problem off and on for a while (cf. Old FoRKposts, etc.) and am very much in line with your suggestion. Let me toss out a couple of additional ideas / extensions: 1. Security It's trivially possible to achieve a MUCH higher level of security and authentication / authorization with this scheme than with existing mail protocols. A simple extension suffices: the principal who sends a mail cryptographically signs it; this signature is attached both to the message stashed in the outbox *and* to the notification that is sent to the recipient's inbox. The fetch operation performed by the recipient to fetch the message is also signed. Both parties verify the other's identities at appropriate points in the process. 2. Groups / Lists / List Archives This scheme subsumes much of the functionality of today's newsgroups, mailing lists, and list archives. If you assume that multiple principals may be associated with a given inbox, then that's all you need for the latter; a newsgroup is merely an inbox that's open to anybody. 3. Retractable E-mail It is possible to regard inboxes as caches of the contents of other parties' outbox contents. If to be the case, it becomes possible to consider the ability of a sender to "retract" a message after it has been sent. A sender may mark a message as being non-cacheable; it stays in his outbox as the authoritative copy of the message no matter how many times the recipient fetches it. If the sender wishes to retract, he merely deletes it. This of course does not prevent any recipient from saving a persistent copy, but well-behaved clients should honor caching hints. 4. Principals While not strictly necessary for any of the things discussed above, this (like most collaborative communication schemes / tools) simply begs for the definition of and integration with a reified notion of principal. If we can create a reasonable HTTP resource model for principals and their presence information, many interesting things become possible: * Presence-enabled "smart" mail delivery and feedback * Subsumption of IM functionality * Tight end-user control over inbound communication In general, a resource model for principals is useful in a huge variety of contexts... An application-neutral mechanism / model is something worthy of consideration. 5. Lifestreams-like Information Architecture / Management Metaphor It's already the case that many people tend to "live out of their mailboxes," i.e., use e-mail as both storage and organizational metaphor for most important information. Lifestreams and similar systems take this notion to its logical conclusion, and in the process provides a pleasantly simple yet powerful metaphor for personal information management. In addition, though not much has been said about this in the lit, IMO the "addressable journal stream + views" model provides a general information architecture that can be used to build loosely-coupled systems of communicating agents / components. The mail mechanism proposed above is very close to something that could be used as the basis for the above. Just some thoughts, cheers... Jb
Paul, Personally, I've considered this issue. My understanding is that it extends HTTP, so I believe a good approach would be to build a REST toolkit based on HTTP and layer an application framework on top of it that supplies WebDAV-based authoring. But like you, I have less knowledge about WebDAV than I do about HTTP, and wish I had more. Actually, Paul, I think I was with you at an XML conference done by DataChannel in San Jose back in 1999. We were in a WebDAV workshop, but I can't remember who conducted it. Jim Whitehead maybe? -Philip -----Original Message----- From: Paul Prescod [mailto:paul@...] Sent: Friday, June 28, 2002 9:51 AM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] WebDAV or HTTP as foundation for REST Let's imagine the perfect REST toolkit. Would it be built upon an HTTP infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as well as I should or will. But I'm thinking that for instance it could be useful for all REST applications to support WebDAV's notion of collections so that you would get compatibility with WebDAV collection management tools "for free". If a REST app has to do locking, it might as well use WebDAV locking. If it has to do object versioning, it might as well use WebDAV versioning. Opinions? Let's presume I'm right. If you were building a REST app today, is there a good WebDAV toolkit out there that is especially designed to be really easy to extend? Zope? 4Suite? Something in Java? mod_dav? Paul Prescod
Thanks, excellent generalizations. I'll add those and credit you! Funny how cool stuff just seems to fall out of REST designs. You try to improve on an existing system by a little bit and you almost accidentally improve upon it by a ton, just chasing the possibilities offered by the fact that everything has a URI. The concept of "web archives" of discussions would be quaint: the discussion *would be* its own web archive! Paul Prescod
Good stuff. One comment -- Any HTTP event system that caches events for pickup/deletion/etc will have almost exactly the same features. So doing a subscription protocol will have HTTP email as a side-effect and vice versa. What I mean is that you establish sessions, resource holders, etc.
Philip Eskelin wrote: > > Paul, > > Personally, I've considered this issue. My understanding is that it extends > HTTP, so I believe a good approach would be to build a REST toolkit based on > HTTP and layer an application framework on top of it that supplies WebDAV-based > authoring. My point is that WebDAV seems more "reusable" than just for authoring just as HTTP is more reusable than just for web pages. > .... But like you, I have less knowledge about WebDAV than I do about > HTTP, and wish I had more. There should be a WebDAV tutorial or book. > Actually, Paul, I think I was with you at an XML conference done by DataChannel > in San Jose back in 1999. We were in a WebDAV workshop, but I can't remember > who conducted it. Jim Whitehead maybe? Yep, Jim. One of the points he made was that WebDAV is sort of the uber-protocol and could replace FTP, many uses of NNTP, SMTP, etc. In other words what I might call the "strong REST hypothesis". But I didn't catch the significance then. I also recall that he was very suspicious of XML RPC protocols and I was ambivalent back then. Also, I just coincidentally read a message where he said: "I think we would have created far more problems for ourselves if we had tried to bite off the problem of creating a general-purpose remote proceedure call marshalling syntax. Since there are currently several competing proposals in this space, and given their dependency on XML efforts to add data typing to XML, I think it was a wise decision to not base our efforts on these other efforts, since it allows us to finish before, say, the year 2002." Another good prediction! Paul Prescod
oldieshome2002 wrote: > >... > > Having a very peripheral involvement in developing this protocol, I > would welcome the group's help in proposing changes to make it more > REST like. I suspect that as at many other organizations, there would need to be a kind of mindset change. The mindset which makes REST evangelism difficult is that of "protocol independence." This is a sort of trendy buzzword today. Unfortunately it is in competition with actually achieving interoperability. REST concentrates first and foremost on interoperability. Nevertheless, if you want to understand what they did "wrong" from a REST point of view, this list of "REST mistakes" might be a start: http://www.prescod.net/rest/mistakes > This paper , http://arxiv.org/abs/cs.DL/0205071 , indicates the > direction in which this protocol is heading. The establishment of a > separate architecture for proxies and caching doesn't seem to make > sense to me at all. Agreed! If they did HTTP right they wouldn't need that! Paul Prescod
At 11:50 PM 28/06/2002, Paul Prescod wrote:
>Let's presume I'm right. If you were building a REST app today, is there
>a good WebDAV toolkit out there that is especially designed to be really
>easy to extend? Zope? 4Suite? Something in Java? mod_dav?
I don't have any experience with it, but Apache's Slide project (http://jakarta.apache.org/slide/index.html) might be useful here. The front page says in part :
"Welcome to the Jakarta Slide project ! Slide is a project composed of multiple modules tied together using WebDAV (see below for more details about WebDAV).
It includes :
� A content management system with a Java API
� A servlet implementing the WebDAV protocol on top of the content management system
� A Java WebDAV and HTTP client library
� A WebDAV command line client
� WebDAV enabled Swing components
Main Features
WebDAV Servlet
�WebDAV Level 2
�DAV ACL support
�Delta V support
�DASL support
WebDAV Client Library
�100% Pure Java
�HTTP/1.1 support
�Easy to use object model
�WebDAV Level 2 support
�DAV ACL support
�Delta V support
�DASL support"
Anyone know more about the WebDAV side of Slide?
Robert
Hi I think that using HTTP Authentication over cookies is more elegant and is a good thing. However one of the guys I work with, who actually gets to do the implementation, is bascially so fed up with it that he is probably going to revert to using cookies -- has anyone got any positive advice / argumnents in favour HTTP Authentication that might convince him not to give up? The details can be found on the mod_perl list: http://mathforum.org/epigone/modperl These are the two threads concerned: http://mathforum.org/epigone/modperl/brumkraibix http://mathforum.org/epigone/modperl/lyrglazhoi Chris
Interesting talk. He says that IP is the "waist" of the Internet. Many protocols below it (Ethernet, ATM, PPP) many above it. But only one IP (well, two with IPv6). What most REST people want is to have HTTP be the "neck" -- the only protocol at its level. What do the IP level and the HTTP level have in common? Addressing. You want universal protocols at levels that do addressing so that any object can talk to any other object. http://www.iab.org/iab/DOCUMENTS/hourglass-london-ietf.pdf --- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com/os2002/ Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Get yer gear here... http://www.cafepress.com/cp/store/productdetail.aspx?prodno=rest.2592837
Joe Hsy wrote: > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > > >>Kevin Smathers described the difference very nicely. >> >> While you can probably think of an OO design more quickly than you can >> a distributed document design, (and I do agree that any good designer >> could do so), that view completely neglects what you are trying to get >> from a loosely coupled design. Data/method encapsulation is what you >> are trying to avoid, not what you are trying to achieve. > > > I've always thought this this type of characterization of OO is rather > unfair. Encapsulation can be both a good thing and a bad thing depending on > what you're encapsulating and the nature of the application. REST uses > encapsulation to good use as well. Per Roy's thesis chapter 5.2.1 (Data > Elements): > > REST therefore gains the separation of concerns of the client-server > style without > the server scalability problem, allows information hiding through a > generic interface > to enable encapsulation and evolution of services, and provides for a > diverse set > of functionality through downloadable feature-engines. > > I've never viewed OO as method oriented. Objects are data as well as > associated methods. Exposing data and methods appropriately are matters of > design (good designs expose the right set). Exposing all the data all the > time isn't the point and isn't always a good idea. Likewise, I still don't > understand why just because we are dealing with a super-scale distributed > system that we should not allowing *any* object methods to be exposed. > > I think having an internet-scale OO system would be a very good thing and > would quite useful. I've been trying to see if REST or some of the core > concepts of REST can be the basis of such an OO system and I still think it > can. But, if we keep insisting REST as incompatible with OO, I guess it is > a hopeless cause. Okay i'll have a go at this one :) 1) Object-Object interactions (semantics) OO systems have interactions between object and the semantic meaning of these methods is hard to encode in a form that a machine can understand. 2) State and side effects Does a call to getMethod() alter the state ? Do i need to persist the Object after getMethod() to preserve the state ? Should the Object device when to persist ? This isn't always what you want. How far does the side effects of this method call reach ? Will the call return in 0.01s or in 10days ? Can ignore the answer ? The problem doesn't lie in associating the operations with data as being done in OO, but rather in the fact that the information is hidden so an application cannot choose how to process the information itself. Whoever builds the object must anticipate the future uses for the system if it is to be scalable and extensible. If a Object representing an image is to be anything more than data. It must encode operations. And as describing behaviour of methods is very hard. Actually the method itself is the only _exact_ description we can get. If we use methods and hide data we can only have one implementation of each method if the system as a whole is to be reliable.And the behaviour must be exactly the same regardless of where you use the Object/methods. So we need exact platform independence for it to work. And still, in large scale distributed systems you can easily get almost uncontrollable interactions when different parts of the systems starts sending messages(method invocations) back and forth. These situations aren't easily avoided. But in a massively distributed system we must assume nodes in that system might be of different kinds. Not all information processing units are created equal :) A data structure is much easier to describe because it doesn't generate interactions that may be sequence dependend. init(),release() and release(),init() can have wildly different interaction patterns. So we can describe data in fever dimensions. And this make it simpler. Each node can implement it's own (or use some library) operations for whatever data types it is interested in. The errors that may arise is more easily handled because fewer (entirely unknown) interactions will occur. Formatting errors in data is often quite easy to detect. So we can validate input to a higher degree. We can not easily validate how a method works, mainly because of that we cannot se the side effects (as all side effects are hidden until we detect them) What i think one should strive for in distributed systems is to avoid side effects as much as possible. This make the system much more robust against timing differences. It is even so that the ordering of events is irrelevant if we have _no_ side-effects. OO is almost _purely_ side-effects, you use methods to alter the state of an object. And you never know how far these side effects reach. You are at the mercy of whoever made that particular object. You never know the state of the object, it's lika quantum-mechanics. Unless you look, you don't know what you have. And when you've looked you still don't know :) Comments and criticism are welcome ... I will not attempt to describe the REST architecture, many has done it before me and succeded well. > > //Joe /Mikael Andersson
I think of REST as the set of principles that assure the end-to-end principle at the HTTP protocol level. Seth Johnson Paul Prescod wrote: > > Interesting talk. He says that IP is the "waist" of the Internet. Many > protocols below it (Ethernet, ATM, PPP) many above it. But only one IP > (well, two with IPv6). What most REST people want is to have HTTP be the > "neck" -- the only protocol at its level. What do the IP level and the > HTTP level have in common? Addressing. You want universal protocols at > levels that do addressing so that any object can talk to any other > object. > > http://www.iab.org/iab/DOCUMENTS/hourglass-london-ietf.pdf -- [CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html
I think you've got some important ideas in there! REST (especially HTTP GET) is about "give me the data and don't tell me what to do with it." OOP is designed primarily to "tell you what to do with it" (to the extent of rules like the law of Demeter that strongly council against showing your hand) * http://www.ccs.neu.edu/home/lieber/LoD.html -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com/os2002/ Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 02:33 AM 3/07/2002, Mikael Andersson wrote: >OO is almost _purely_ side-effects, you use methods to alter the state of an object. How is this any different from a description of REST, you still use methods (albeit standardized HTTP methods) to alter the state of a resource, with the exception that GET allows side-effect free access? Refer to Mark Bakers 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model). >And you never know how far these side effects reach. You are at the mercy of whoever >made that particular object. Why is this any different for a resource? >You never know the state of the object, it's lika >quantum-mechanics. Unless you look, you don't know what you have. And when you've >looked you still don't know :) This is where REST is advantageous, however, you can still only see a 'representation' of the state of the resource, i.e. you only see what the resource provider wants you to see, so you can never truly know the state of the resource? Continuing on with the whole no side-effects approach, I'm having a hard time reconciling this notion, i.e. being purely functional (in the programming language sense) and being able to change the state of a resource via HTTP methods. Am I understanding what you mean when you say side-effect free and if so should we be looking more at FP rather than OOP for implementing REST-like systems? Robert
First i'd like to state this: One can call (almost) any system 'OO' if you look har enough. In the same way as all systems is procedureal to the core (as machinecode is procedural in some sense) We must try to look at how different techniques is used. Not how they are specified. Distributed systems is about realy more than about theory. People make mistakes. Robert Leftwich wrote: > At 02:33 AM 3/07/2002, Mikael Andersson wrote: > > >>OO is almost _purely_ side-effects, you use methods to alter the state of an object. > > > How is this any different from a description of REST, you still use methods > (albeit standardized HTTP methods) to alter the state of a resource, with > the exception that GET allows side-effect free access? Refer to Mark Bakers > 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model). > GET,POST,PUT has very clear meanings (esp. as describe in that draft). Most OO systems contain 1000's of methods with different semantics, and it's hard for a system to know what they mean. And they cannot explore, for doing so may alter the state unpredictably. Using GET you can (or you should be able to atleast...) explore quite freely. POST otoh, may alter state. > >>And you never know how far these side effects reach. You are at the mercy of whoever >>made that particular object. > > > Why is this any different for a resource? > When you have the 'object' (the page/whatever). The information in it will not change until you request it again. If you act on a local(or remote) object in a fullt distributed system, it may change. I feel the wholeness of a resource is important. All that is guaranteed in an OO system is that every object is consistent to it's own rules at all times. And the object is the rules, so we don't know them. But if i call one method, and then another. The result from the first and second is subject to timing issues with other systems involved. > >>You never know the state of the object, it's lika >>quantum-mechanics. Unless you look, you don't know what you have. And when you've >>looked you still don't know :) > > > This is where REST is advantageous, however, you can still only see a 'representation' > of the state of the resource, i.e. you only see what the resource provider wants you > to see, so you can never truly know the state of the resource? > Matter is built by atoms whose state we cannot know. But on a macroscopic scale it's predictable. But an atom here, won't affect something somewhere entirely different (sans entanglement, but that's another story :) ). But we get some view of the state in a format we can understand. In OO the view is composite. We must call many methods to get a 'view'. And during that time we're at risk of timing issues. > Continuing on with the whole no side-effects approach, I'm having a hard time > reconciling this notion, i.e. being purely functional (in the programming language sense) > and being able to change the state of a resource via HTTP methods. Am I understanding what > you mean when you say side-effect free and if so should we be looking more at FP rather > than OOP for implementing REST-like systems? I don't think we can be functional. But i think there is some important ideas there. A purely functional system can be executed in arbitrary order and yield the same result. This behaviour would do wonders for any distributed system. But we should strive to reduce the points where side effects can happen and also to reduce the impact they may have. Being resilient to timing problems is very hard. And when doing something in a distributed environment timing can be a nightmare. Btw i'm not an expert of functional languages. What i know is what a friend has showed me which is very good at these things and what i've read from a few sources. So don't think i can give a very deep insight on functional programming idioms and how it possibly relates to REST like systems. I have some more things on my mind here. But i'll try to keep myself from wandering to far astray. As i have a tendency to do so. I easily get too philosophical :) > > Robert > /Mikael Andersson
> -----Original Message----- > From: Mikael Andersson [mailto:mikael@xpedio.com] > Sent: 03 July 2002 12:33 > > First i'd like to state this: > One can call (almost) any system 'OO' if you look har enough. Here's a working guide to various definitions of OO: <http://www.paulgraham.com/reesoo.html> Bill de hra .. Propylon www.propylon.com
Mark Baker wrote in http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html > What's special about the application layer, > is that it is the "top dog". > You can't layer on top of it and still call > yourself a valid use of that protocol. > You can only extend it. How about the case we discussed previously about implementing the offer-acceptance business protocol in REST? There is clearly something else going on that seems to be to be "above" the HTTP protocol. As ISO says, you're not just exchanging data, you're making business commitments. Rohit Khare had an interesting diagram in his recent Soap Routing slide show where he added two layers on top the application protocol: Layer 8 - Economic (which is where business commitments cd go) Layer 9 - Political. What do you think? -Bob Haugen
bhaugen32 wrote: > > Mark Baker wrote in > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html > > > What's special about the application layer, > > is that it is the "top dog". > > You can't layer on top of it and still call > > yourself a valid use of that protocol. > > You can only extend it. > > How about the case we discussed previously about implementing the > offer-acceptance business protocol in REST? > > There is clearly something else going on that seems to be to > be "above" the HTTP protocol. As ISO says, you're not just > exchanging data, you're making business commitments. There is something else going on, but it is an extension of HTTP. I think of things like WebDAV and Offer/Acceptance as plugins. You should be able to trivially build an application using a mix of WebDAV and Offer/Acceptance at the same time. Individual resources should be able to mix bits of WebDAV and Offer/Acceptance in the same message (if they make logical sense together in a particular message). Whereas, HTTP and SMTP are really layered on top of TCP so you can't have a single TCP connection being both HTTP and SMTP at the same time. As usual, it is impossible to say anything authoritative about how SOAP would fit in. You can use it as a layer above HTTP (bad programmer!) or as an extension to HTTP (but what does it add?) > Rohit Khare had an interesting diagram in his recent Soap Routing > slide show where he added two layers on top the application protocol: > Layer 8 - Economic (which is where business commitments cd go) > Layer 9 - Political. I was at the talk and in that context it was clear that he meant it more as a joke. Not "economic protocols" like ebXML but "economic protocols" like -- how do I con venture capitalists into giving me money? -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
I'm currently looking at how a REST approach handles security and would value some feedback. As has been described elsewhere the resource-centric approach allows the use of existing ACL-based security - I'm interested in the influence this has on the resource model. A concrete example, as always, is a good thing.... Lets say our requirements for a medical system include the ability to attach documents to a patient record e.g. specialists reports, police and social workers investigations, etc. This is quite a natural thing for a REST-based system to handle, with each of the documents being linked to from the main patient record. Adding attachments would simply be a matter of a POST to the patient record URI of an xml-structure containing the link to where the document resides. A similar approach can be taken to change or delete the link (i.e. PUT & DELETE). (Note that attachments are not identified as a sub-resource in their own right as they are simply links and as such it is not really necessary to expose them separately). Now the security issues come into play. Suppose that for obvious reasons you want to be able to restrict who can add, update or delete particular types of attachments. Without having individual sub-resources for each of the types in question there appears to be no way to setup this style of security using ACL. If you do choose the sub-resources approach, what happens when your security requirements change? Do you then have to change your resources to match? Is there something I am missing in my understanding of the use of ACL in REST, as this approach appears too fragile and inter-dependant for my liking? Robert
Don Park wrote: > >... > > I can say the same about REST. Web came about because everyone added to > it. Much of current focus on web services came about because Dave Winer > evangelized XML-RPC and everyone started adding to it. Really? What large-scale services depend on XML-RPC to the extent that they do HTTP, FTP or SMTP? I don't think I have any mainstream software using XML-RPC (or SOAP) on my computer at all. > Unfortunately, I can't say the same about REST. All I see is a few > whitepapers describing an abstraction of HTTP protocol which does not > address the full range of web service applications. Where are the REST > equivalent of WSDL, UDDI, and XKMS specs? Don, first you have to step back and ask whether WSDL, UDDI and XKMS are good things. Then once you've decided that, it makes sense to ask for equivalents. They aren't so there isn't. The issue should be a no-brainer for UDDI. Who do you know who is using UDDI? For what? For WSDL, it is more subtle. Some days I think it might add to REST a little bit, but most days it doesn't seem to add much. I don't see it as a flaw of REST that it simplifies problems to the extent that WSDL becomes marginally useful at best. XKMS might be useful. I don't know anyone using XKMS so haven't had reason to reinvent it as REST yet. It looks like it uses as little of SOAP as possible. > ... Where are the REST tools and > libraries? J2EE and Expat are all you need for a "REST toolkit and library." I'm sorry to be so anticlimatic but the basic REST tools have been deployed for around eight years now. It's pretty hard to do better when the industry has already spent a *billion dollars* on REST toolkits. When Rael Dornfest wanted to build Meerkat he didn't go to Microsoft and ask them for a toolkit. He just said: "XML + RSS + HTTP = great app". The same goes for other REST apps like pkg_add in OpenBSD or Microsoft Exchange Server or Outlook Express. If the fact that people will build apps without making a big deal about it means REST is a "failure" then you're right, maybe it is doomed to fail. >... > While it disturbs me to see complex SOAP messages bearing very little > resemblance to the simple XML-RPC messages, I prefer SOAP over REST. I'm curious, have you read the SOAP spec? -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 10:05 AM 5/07/2002, Paul Prescod wrote: >Don Park wrote: > > ... Where are the REST tools and > > libraries? > >J2EE and Expat are all you need for a "REST toolkit and library." Are you serious? J2EE has almost the same level of complexity as SOAP and it is a single vendor set of pseudo-standards (JCP not withstanding) that *only* runs on that same vendors proprietary platform! How much mainstream s/w do you have on your computer that uses J2EE? Robert
Robert Leftwich wrote: > >... > >J2EE and Expat are all you need for a "REST toolkit and library." > > Are you serious? > J2EE has almost the same level of complexity as SOAP and it > is a single vendor set of pseudo-standards (JCP not withstanding) that > *only* runs on that same vendors proprietary platform! J2EE is a particular instance of a SOAP toolkit. Zope is another. PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype right now so I mentioned it. > How much mainstream s/w do you have on your computer that uses J2EE? Well presumably a lot of HTTP software I have talks to J2EE servers. But I have no particular attachment to that one toolkit. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 02:08 PM 5/07/2002, Paul Prescod wrote:
>Robert Leftwich wrote:
> >
> >...
> > >J2EE and Expat are all you need for a "REST toolkit and library."
> >
> > Are you serious?
> > J2EE has almost the same level of complexity as SOAP and it
> > is a single vendor set of pseudo-standards (JCP not withstanding) that
> > *only* runs on that same vendors proprietary platform!
>
>J2EE is a particular instance of a SOAP toolkit. Zope is another.
^^^^^^
Was that a Freudian slip :-)
>PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype
>right now so I mentioned it.
Given your history I guess I expected a bit more of a Python push :-)
Robert
Robert Leftwich wrote: > >... > > > >J2EE is a particular instance of a SOAP toolkit. Zope is another. > ^^^^^^ > Was that a Freudian slip :-) SOAP and Zope. For entirely non-technical reasons it is hard to think of one without the other! > >PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype > >right now so I mentioned it. > > Given your history I guess I expected a bit more of a Python push :-) Well if someone was asking my opinion of what to use... -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
> -----Original Message----- > From: Robert Leftwich [mailto:robert@leftwich.info] > > At 10:05 AM 5/07/2002, Paul Prescod wrote: > >J2EE and Expat are all you need for a "REST toolkit and library." > > Are you serious? > J2EE has almost the same level of complexity as SOAP J2EE is way (waayy) more complicated than SOAP; EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS... > a single vendor set of pseudo-standards (JCP not withstanding) In fairness, a good amount of the J2EE stuff goes through the JCP. But I do think that that calling expat+J2EE a REST toolkit is vaguely bogus. Bill de hra .. Propylon www.propylon.com
Bill de h�ra wrote: > >.... > > > a single vendor set of pseudo-standards (JCP not withstanding) > > In fairness, a good amount of the J2EE stuff goes through the JCP. But I > do think that that calling expat+J2EE a REST toolkit is vaguely bogus. I don't see the problem. REST is the architecture of the Web and a REST toolkit would be a piece of software that helps you build the mediating layer between your application and the Web. AFAIK, that's what (e.g.) J2EE and Zope are used for. Now that XML has come along it makes sense to want to extend these things. Just as they had native knowledge of HTML, you might want to give them native knowledge of XML and RDF. And maybe newer toolkits could better enforce best practices. But overall, I see no problem calling any web development platform a REST toolkit. REST is not something new. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
> -----Original Message----- > From: Paul Prescod [mailto:paul@...t] > > Bill de hra wrote: > > > > I do think that that calling expat+J2EE a REST toolkit is vaguely > > bogus. > > I don't see the problem. The problem is that is not a meaningful distinction to make; at best it's just co-opting systems by rebadging them. Along these lines, GNU Linux is a REST toolkit and Bash/Vi are client tools. Now if you agree with that, it's fine and we can stop there: what we call things is largely a mater of taste in any case. Personally, I like my definitions to define things not blur them together. There's a difference between saying you can use J2EE to do REStful stuff and saying that it is for RESTful stuff. I'm sure you know this, so I'm wondering where you're coming from. > REST is the architecture of the Web I know. > and a REST toolkit would be a piece of software that helps > you build the mediating layer between your application and > the Web. AFAIK, that's what (e.g.) J2EE and Zope are used > for. J2EE was not designed to do that any more than CORBA and DCOM were. That they're being refactoring to do this class of work or even that you can use J2EE for that class of work is incidental; that's aside from the fact that J2EE system encompasses more than a pair of EJB and Servlets containers. Bill de hra .. Propylon www.propylon.com
> Don, first you have to step back and ask whether WSDL, UDDI > and XKMS are good things. Then once you've decided that, it > makes sense to ask for equivalents. They aren't so there > isn't. The issue should be a no-brainer for UDDI. Who do you > know who is using UDDI? For what? Paul, Why do you insist on arguing over the individual trees instead of looking at the forest? I didn't bother replying when you casually filed away my previous comments as not being relevant to Rich's specific problem. Now you insist on examining the value of individual SOAP specs when I was pointing out that REST doesn't seem to be catching fire unlike SOAP. > J2EE and Expat are all you need for a "REST toolkit and > library." I'm sorry to be so anticlimatic but the basic REST > tools have been deployed for around eight years now. It's > pretty hard to do better when the industry has already spent > a *billion dollars* on REST toolkits. This display of trivialization and delusion does not become you. > I'm curious, have you read the SOAP spec? I have read 1.1 and earlier specs. I have not yet read the 1.2 drafts. Best, Don Park PS: I find this sudden and unilateral shift to REST mailing list distasteful, Paul.
Hmmm, I'm a bit hesitant to chime in here, because this forum is
generally a bit over my head, so apologies if I am OT...
Many young script-monkeys (like myself) that pass for programmers these
days tend to like things to have been done for us;
We don't write our own device drivers and suchlike, because we often
don't have the time or the skill. We just use an existing library, and
cut and paste from the sample code that came with the library documentation.
SOAP/XML-RPC/CORBA etc. all come as pre-packaged bundles, both
physically and conceptually. You import the library, read +cut+paste the
docs, and return a nicely massaged array or whatever. Then you and your
boss go home, on time, happy.
With REST, you have to independently research all the pieces and grok
the concepts, then find an appropriate library that provides
GET,POST,PUT etc. e.g. a default PHP install will *probably* only
include GET functionality (unless you build something up from the basic
socket functions, or include something like CURL - which doesn't mention
REST anywhere in it's docs). Then you have to parse the page returned,
which might mean having to learn DOM/SAX/REGEXP.
No, it isn't really hard (except the 'groking REST' part ;), but it
requires more time, more initiative and more brave, independent thought
(explain to your boss why you don't want to use this 'Industry Standard'
SOAP thing and want to 'make up' your own interface)
I'm not trying to get into a debate on the state of the industry/IT
training, just observing human nature as I see it. If people have the
option of being spoon-fed, they will go for it, regardless of what is on
the spoon.
Based on this, the idea of creating a sample "REST Library" might be a
good one?
1, It would theoretically be very simple to implement - just wrappers
round existing functions (the debate would probably take longer than the
writing ;)
2, It would be a point of focus for all the young whippersnappers like
myself who like to see concrete examples
3, As you have already pointed out Paul, most platforms will have the
components needed anyway, so after reading the docs, a programmer should
be able to implement the concepts, from the tools they already have.
4, Maybe REST is more of a concept than a specific implementation, but
that doesn't mean that a few provocative demos wouldn't help inspire the
troops.
5, I find there is nothing like actually building something to show up
the potential holes and pitfalls that people might fall into. Very Useful!
Just my two cents. Should I ask for a refund?
Ed Lucas
Paul Prescod wrote:
>Bill de h�ra wrote:
>
>
>>....
>>
>>
>>
>>>a single vendor set of pseudo-standards (JCP not withstanding)
>>>
>>>
>>In fairness, a good amount of the J2EE stuff goes through the JCP. But I
>>do think that that calling expat+J2EE a REST toolkit is vaguely bogus.
>>
>>
>
>I don't see the problem. REST is the architecture of the Web and a REST
>toolkit would be a piece of software that helps you build the mediating
>layer between your application and the Web. AFAIK, that's what (e.g.)
>J2EE and Zope are used for. Now that XML has come along it makes sense
>to want to extend these things. Just as they had native knowledge of
>HTML, you might want to give them native knowledge of XML and RDF. And
>maybe newer toolkits could better enforce best practices. But overall, I
>see no problem calling any web development platform a REST toolkit. REST
>is not something new.
>
>
Paul Prescod wrote:
> Let's imagine the perfect REST toolkit. Would it be built upon an HTTP
> infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as
> well as I should or will. But I'm thinking that for instance it could be
> useful for all REST applications to support WebDAV's notion of
> collections so that you would get compatibility with WebDAV collection
> management tools "for free". If a REST app has to do locking, it might
> as well use WebDAV locking. If it has to do object versioning, it might
> as well use WebDAV versioning.
>
> Opinions?
>
I have been lurking on this list for a while and have come to similar
conclusions about WebDAV. I don't claim to fully understand all the
ideas of REST and WebDAV, or if all parts of WebDAV are compliant to
RESTs architectural style, but i might as well throw caution to the wind
and jot down some opinions/hunches on WebDAV!
PROPFIND: I presume this has the same non-side-effects as GET. Maybe
some of the resources defined as metadata could be compressed into or be
referenced as properties of a resource e.g. service descriptions. The
problem of 'what does this resource do?' may be partially resolved if
there was a standard property on the resource defining a link to WSDL or
RDF document.
PROPPATCH: Could be used to prime a resource with appropriate meta-data
before commiting it for processing.
Namespace manipulation: Once a resource has been primed it could be
commited for processing by simply moving it to another collection.
ACLS: May solve some of the issues discussed about principles. Could it
allow for the use of one collection resource for all users viewing their
purchase orders? Users would only get resources for the purchase orders
they have permision to view.
Bindings and redirection (a bit like resource symbolic links): Could
allow for multiple views of the collections e.g. allowing for 'Cabinets'
concept you mention in the 'Reinventing Email using REST' article.
> Let's presume I'm right. If you were building a REST app today, is there
> a good WebDAV toolkit out there that is especially designed to be really
> easy to extend? Zope? 4Suite? Something in Java? mod_dav?
>
I have had experience with neon (prototyping WebDAV support for
StarOffice) and Slide (adding rysnc and rproxy support for HTTP GET to
the Slide HTTP/WebDAV layer and client). My view is that the WebDAV bits
are simply extentions to the HTTP bits. With Slide the WebDAV and HTTP
bits, encapsulated in a servlet, sit on top of a content management
system which is capable of supporting most the WebDAV features such as
locking, ACLs and basic versioning in addition to supporting features
not in WebDAV (AFAIK) like transactions (although the WebDAV DeltaV may
offer some aspects of this since i think it deals with sets of resources
and is designed to offer functionality similar to that of CVS).
I really liked you article about email and REST. When i was implementing
an IPP (Internet Printing Protocol) client i thought this type of thing
could be done using WebDAV. Print queues and jobs all fit nicely in the
resource and collection concepts and properties can be accessed using
PROPFIND and PROPPATCH; i rekon the IPP model can be represented as a
set of properties on resources (IPP does have distinct URIs for queues
and jobs but binary messages are POSTed, with methods encapsulated in
the message). The perhaps thorny issue of IPP print job notification
fits nicely into the unification of news/email ideas that you presented.
With hindsite it annoys me that i had to implement a binary protocol on
top of HTTP that tunneled through HTTP using POST. There were extentions
to HTTP that i think could of done the job just as well, if not better,
that reused existing, well proven, resources and concepts and could gain
from their future advances.
Some speculation: perhaps if the IPP group used WebDAV and the REST
style then this alternative way of printing could of achieved a faster
time to market.
All the other nice features sort of fall in place, just like for REST
email; it kind of makes me smile when i see how elegent these systems
could be :-) and also makes me frustrated that they are currently not :-(
Maybe REST printing could become another use case along side REST email.
Thanks,
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
----- Original Message ----- From: "Robert Leftwich" <robert@...> > Adding attachments would simply be a matter of a POST to the > patient record URI of an xml-structure containing the link to where the > document resides. A similar approach can be taken to change or delete the > link (i.e. PUT & DELETE). (Note that attachments are not identified as a > sub-resource in their own right as they are simply links and as such it is > not really necessary to expose them separately). Without an independent URI for the added link, you can't DELETE the link (since you can't identify the link you want to delete). You'd have to PUT the full patient record with a list of all the links minus the one you don't want. > Now the security issues come into play. Suppose that for obvious reasons you > want to be able to restrict who can add, update or delete particular types > of attachments. > Without having individual sub-resources for each of the types in question > there appears to be no way to setup this style of security using ACL. If you > do choose the sub-resources approach, what happens when your security > requirements change? Do you then have to change your resources to match? > > Is there something I am missing in my understanding of the use of ACL in > REST, as this approach appears too fragile and inter-dependant for my liking? > Can you provide a concrete example of ACL as it applies to these resources so we know what you are seeing from your perspective. If I had an ACL system that was aware of HTTP messages, I could filter on portion of the message - method, content-type, user-id, etc.: <acl> <ace> <grant> <principal>/robert</principal> <method>POST</method> <content-type>*</content-type> </grant> <deny> <principal>/mike</principal> <method>POST</method> <content-type>application/vnd.leftwitch.billing+xml</content-type> </deny> </ace> </acl>
----- Original Message ----- From: "Bill de h�ra" <dehora@...> > J2EE is way (waayy) more complicated than SOAP; > EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS... That's because it's doing different things. I wouldn't include IIOP (from Corba) or RMI (from Java) - optional & usually available but not required in J2EE. JNDI, JMS, JDBC and servlets are the main dish in J2EE for me & they are simple and very powerful. JAAS is probably just as core - I just don't happen to have any experience with it. As a note, JNDI may be interesting to the REST crowd because it is an API that talks to different datasources, has addressing and has a minimal set of common methods over those disparate types of data sources.
----- Original Message ----- From: "Ed Lucas" <ejl@...> > > Based on this, the idea of creating a sample "REST Library" might be a > good one? It is a very good idea in my opinion. And I think it is /required/ to get applications built to the REST approach. I'd like to use existing HTTP software - clients and servers - as a base, but there are a lot of landmines left from the Browser Wars. Even so, many existing software tools can be used as is and the ones that have 'issues' usually can be adjusted. The push I'd like to make is for an 'Automatable Web'. I'm not into the Semantic Web, and the existing 'Visual Web' just doesn't cut it - the tools have led people down the path exposing user interface via resources (rather than exposing the information) and handling messages in a "one resource, one method" approach (rather than full function get/put/post/delete). Simple RPC tools help scripters achieve some amount of networked automation, but to go to the next level you need to build on a strong foundation - the Web - and the features that give it strength. There has been talk in the past about APIs that are REST friendly - we should start a page on the Wiki. Here is one page that has psedo-code to describe REST ideas - but a new page is needed for full API discussions. http://internet.conveyor.com/RESTwiki/moin.cgi/PseudoCodeForRest?action=high light&value=api
Ed Lucas wrote: > >... > > Many young script-monkeys (like myself) that pass for programmers these > days tend to like things to have been done for us; > We don't write our own device drivers and suchlike, because we often > don't have the time or the skill. We just use an existing library, and > cut and paste from the sample code that came with the library documentation. Aha! So what you are lacking is sample code and documentation. That's very different than a toolkit. > SOAP/XML-RPC/CORBA etc. all come as pre-packaged bundles, both > physically and conceptually. You import the library, read +cut+paste the > docs, and return a nicely massaged array or whatever. Then you and your > boss go home, on time, happy. SOAP doesn't work that way if you actually want to get any of the benefits described for it (loose coupling, asynchronous sends, etc.). But if you just want to use it as a new-fangled, less-powerful CORBA, then sure. Against the recommendations of everyone who understands SOAP you can use the Visual Studio wizards out of the box and get tightly-coupled web service without support for references or pointers. > With REST, you have to independently research all the pieces and grok > the concepts, then find an appropriate library that provides > GET,POST,PUT etc. e.g. a default PHP install will *probably* only > include GET functionality (unless you build something up from the basic > socket functions, or include something like CURL - which doesn't mention > REST anywhere in it's docs). I don't believe that PHP is really that limited. The method that comes in should be encoded as a CGI environment variable. And PHP can make outbound HTTP requests out with any method. > .... Then you have to parse the page returned, > which might mean having to learn DOM/SAX/REGEXP. If you want the benefits of XML you have to learn some XML processing technology. I have some ideas about XML serialization/deserializtin techniques that are easier in some ways than the stanard techniques, but it doesn't save you from learning anything whatsoever. In Web Services technology that hides the XML from you (XML-RPC, VS.NET) is hiding your best hope for extensibility. > No, it isn't really hard (except the 'groking REST' part ;), but it > requires more time, more initiative and more brave, independent thought > (explain to your boss why you don't want to use this 'Industry Standard' > SOAP thing and want to 'make up' your own interface) There's no doubt. REST will not be easy to sell to your boss until it is clear that SOAP is either easy or extensible, but not both, and scarcely interoperable. > I'm not trying to get into a debate on the state of the industry/IT > training, just observing human nature as I see it. If people have the > option of being spoon-fed, they will go for it, regardless of what is on > the spoon. I certainly agree. > Based on this, the idea of creating a sample "REST Library" might be a > good one? > 1, It would theoretically be very simple to implement - just wrappers > round existing functions (the debate would probably take longer than the > writing ;) I have a few concerns with your proposal: 1. Duplicating the "toolkit" in .NET, Java, PHP, etc. is a bunch of work. They all have their own ways of dealing with XML and HTTP. And wrapping them consistently will hide whatever virtues each platform has. 2. Whatever environment we left out would feel like it "couldn't do" REST until they were given a toolkit. I'd rather teach people that they are not dependent. 3. I don't have a clear picture of what the toolkit looks like because it really is the sum of the platform's HTTP capabilities plus the platform's XML capabilities. >... > 5, I find there is nothing like actually building something to show up > the potential holes and pitfalls that people might fall into. Very Useful! Sure, we need more demos and documentation. We need people using many different platforms to make wildly varying REST apps, using wildly varying tools and techniques. There was no one toolkit for the HTML web and I don't think there will be one for the XML Web. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On Fri, Jul 05, 2002 at 06:21:51AM -0700, Don Park wrote: > > Don, first you have to step back and ask whether WSDL, UDDI > > and XKMS are good things. Then once you've decided that, it > > makes sense to ask for equivalents. They aren't so there > > isn't. The issue should be a no-brainer for UDDI. Who do you > > know who is using UDDI? For what? > > Paul, > > Why do you insist on arguing over the individual trees instead of > looking at the forest? I didn't bother replying when you casually filed > away my previous comments as not being relevant to Rich's specific > problem. Now you insist on examining the value of individual SOAP > specs when I was pointing out that REST doesn't seem to be catching fire > unlike SOAP. Okay, here's the forest as I see it: SOAP has existed for about 2 1/2 years, and from very early on has been heavily promoted by both Microsoft and IBM. It was touted as revolutionary in an era when "revolutionary" technologies were practically guaranteed to bring forth hordes of slavering investors. Furthermore, SOAP became seen as a core technology of Web Services not by accident, but because it was a key part of the development trend that led to the idea of Web Services. REST has been around (in substance if not in name) for much longer than SOAP. Yet the REST-for-Web-Services movement is still very new, and takes place in a dramatically changed marketplace. The economy is in recession, technical innovation has lost its magical aura (and even if it hadn't, the resources available for experimentation are vastly reduced). SOAP has money and momentum behind it; REST has a motley crew of smart developers. Furthermore, REST probably seems like a radical change to the money people, who are now afraid of radical change; yet not radical enough to that sizable portion of the developer community that thrives on being "cutting-edge." So the fact that REST isn't on the verge of taking over the world means what, exactly? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Don Park wrote: > >... > > Paul, > > Why do you insist on arguing over the individual trees instead of > looking at the forest? I didn't bother replying when you casually filed > away my previous comments as not being relevant to Rich's specific > problem. In a mailing list thread you are usually trying to discuss some specific topic. I didn't just file it, I also told you how to do the equivalent in HTTP. > ... Now you insist on examining the value of individual SOAP > specs when I was pointing out that REST doesn't seem to be catching fire > unlike SOAP. REST caught fire sometime in the mid-1990s. I first did a Web Service (an ad server) using REST techniques (and a pre-XML encoding) in 1996. Plus, REST has more real-world Internet-deployed apps than SOAP, including (AFAIK) Hotmail, Exchange, the whole RSS "system", etc. And the CIO of Utah has decided to use it. ;) * http://www.windley.com/2002/07/03.html#a64 If you see SOAP "catching fire" then you have a different perspective then the people I meet who are trying to make money selling web services tools or services. Also, I see an article every week about how businesses are taking a "wait and see" attitude towards Web Services: this is after *5* years of development. So "catching fire" does not seem to be the right word to me. SOAP is catching fire with software vendors who want to send a new round of tools. > > J2EE and Expat are all you need for a "REST toolkit and > > library." I'm sorry to be so anticlimatic but the basic REST > > tools have been deployed for around eight years now. It's > > pretty hard to do better when the industry has already spent > > a *billion dollars* on REST toolkits. > > This display of trivialization and delusion does not become you. There is nothing trivial about a the amount of money industry has spent implementing the REST architecture. I'm sorry if it seems that way to you. One of the main inventors of REST is also one of the lead designers of Apache (Fielding). So surprise, surprise, Apache has REST ideas deep down in its core. I see nothing trivial about pointing that out. PHP's developers are strongly influenced by the Apache group, so PHP has REST ideas deep down in its core too. etc. etc. for IIS. Fielding's REST thesis was a description of the architecture of the *existing tools*. Let me stress that again: the term REST is a way of describing the architecture of the tools that *already existed* when he wrote the thesis. I've also talked to people deeply involved with the standardization of J2EE and they immediately "GOT" REST and described how J2EE supports it implicitly. I can guarantee I'll have the same experience with the developers of Zope when I see them next (it's the response I've gotten from Zope users -- "oh, that's what I'm already doing"). So these are my observations from the real world. XML developers haven't caught on to the extent that HTML developers have yet. That's true. But they have the infrastructure, they just don't know how to use it (after all, it took years for HTML developers to learn how to use the tools also). This idea that something doesn't exist if it doesn't have a boxed toolkit is bizarre to me. Where is the toolkit for GOF patterns or XP or structured programming? Insofar as REST is an architectural style, it has more in common with structured programming than with SOAP. What is the SOAP architectural style? Who writes the best practices for SOAP services? > > I'm curious, have you read the SOAP spec? > > I have read 1.1 and earlier specs. I have not yet read the 1.2 drafts. I'll just be interested to see, when you do, whether you still see the spirit of XML-RPC in there. > PS: I find this sudden and unilateral shift to REST mailing list > distasteful, Paul. When I post about REST to XML-DEV, I'm told that it is tiresome and off-topic. Therefore I try not to keep threads running there for long. I asked on at least one occasion to move the thread to rest-discuss and nobody either agreed or disagreed. Furthermore, if I respond to a message on XML-DEV and then ask you to do your next response to rest-discuss, that could be perceived as a way for me to have my "last word" on XML-DEV and shunt your comments onto a different forum. I thought it was better to let you have the last work on that list and move my comments to a more appropriate one. If you prefer to discuss it on XML-DEV then we can go back there and I'll merely comment in my messages that you wanted to discuss it there. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Matt Gushee wrote: > >... > > Okay, here's the forest as I see it: > > SOAP has existed for about 2 1/2 years, and from very early on has been > heavily promoted by both Microsoft and IBM. Actually, you should read this: http://www.xml.com/pub/a/2001/04/04/soap.html >... > So the fact that REST isn't on the verge of taking over the world means > what, exactly? IIRC, Lotus Notes and Compuserve had all of the industry momentum in 1993/1994. The Web was an academic toy. That analogy was not picked at random. Both of those products failed to understand the importance of global, open, linking and addressing. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
> -----Original Message----- > From: Paul Prescod [mailto:paul@...t] > > There is nothing trivial about a the amount of money industry > has spent implementing the REST architecture. I'm sorry if it > seems that way to you. One of the main inventors of REST is > also one of the lead designers of Apache (Fielding). So > surprise, surprise, Apache has REST ideas deep down in its > core. I see nothing trivial about pointing that out. PHP's > developers are strongly influenced by the Apache group, so > PHP has REST ideas deep down in its core too. etc. etc. for IIS. Well said. Perhaps the problem is that industry is not fully cognizant of what it has been building. I'm reminded that many programmers did not realize fully what they were doing with OO until the likes of Jim Coplien and the GoF articulated the idea of Software Patterns. Bill de hra .. Propylon www.propylon.com
Bill de h�ra wrote: > >... > > Well said. Perhaps the problem is that industry is not fully cognizant > of what it has been building. I'm reminded that many programmers did not > realize fully what they were doing with OO until the likes of Jim > Coplien and the GoF articulated the idea of Software Patterns. True enough. We all learned web programming so incrementally. It was never approached as an architectural style, it was always tactical: "gotta get this information up today. Better give a different URI to each thing so it can be bookmarked. Oops, using POST messes up the 'refresh' button. Better use GET." etc. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
> -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@hotmail.com] > Sent: 05 July 2002 18:17 > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: [xml-dev] ANN: Building Web > Services the REST Way > > > > ----- Original Message ----- > From: "Bill de hra" <dehora@...> > > > J2EE is way (waayy) more complicated than SOAP; > > EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS... > > That's because it's doing different things. Sure, but that's what J2EE is according to Sun. A big beast. > I wouldn't include IIOP (from Corba) or RMI (from Java) - > optional & usually available but not required in J2EE. Yep, but the interop standard for EJB is RMI-IIOP, not RMI; historically that was invented to keep the CORBA crowd happy. And it's essence is synchronous, RPC and pass by value. I honestly don't know how well the stubs and skeletons thing fits with REST, but otherwise RMI-IIOP doesn't strike me as a RESTful protocol. > JAAS is probably just as > core - I just don't happen to have any experience with it. JAAS looks nice, it does much the same for authentication and authorization that JNDI does for directories and JDBC does for datasources. Clients can declare controls impendent of implementations. I wanted to use it an upcoming project, but I didn't think there was time for me to pick it up properly. Bill de hra .. Propylon www.propylon.com
http://blogstream.com/pauls/1025918592 HTTP is an Application Protocol Posted by Paul Prescod on Friday July 05, @06:23PM from the what-the-hell-are-you-REST-guys-talking-about? dept. REST people often say that HTTP is an application protocol and therefore you should not layer a "protocol independent" protocol on top of it, but rather should only use it as is or extend it using documented extension mechanisms. I want to offer an analogy that may clarify this. I think we all agree that HTTP should be the basis for new technologies. The question is whether these new technologies are new layers or new extensions. Here's an analogy that might be useful. TCP is to HTTP as XML is to XHTML. XHTML is layered on top of XML and XML makes almost no semantic demands on XHTML at all. XHTML can use an element like <title> to represent something that is "logically" an attribute and nobody complains. XHTML could use an attribute "date" to represent something that "logically" has sub-structure and if anyone complains it is because they are making life somewhat more difficult for developers. But the XML standard does not say that you should use attributes for "metadata-like things" and elements for "content-like things". It makes almost no semantic demands on the vocabulary at all. You would have to work pretty hard to violate the "semantics" of the XML specification. All you could do, really, is break the syntax -- be not-well-formed. Similarly, applications running on top of TCP have very few semantic responsibilities. Both XML and TCP are designed to say: "do what you want, just obey the syntactic rules of the specification." Now let's go up a step. XHTML is an XML application (in the old "SGML application sense). HTTP is an application protocol. They *do* make semantic demands on things building on top of them. In other words, you MUST extend, not layer, on them. "P" means "paragraph" in XHTML. There should never, ever, be a "layer" that adds another semantic on P like "parachute". That would destroy interoperability with XHTML processors in a very dangerous way. The documents would be valid XHTML (according to validating parsers) but meaningless! You are supposed to extend XHTML with new elements, and you are supposed to "subclass" P with "big paragraph" or "important paragraph" or "disputed paragraph" but you should never state that in "in my variant of XHTML, two P elements in a row means 'table'" Once you've done that, it is no longer a variant of XHTML. It is a semantically incompatible language and interoperability will suffer. Browsers can display it (if it is valid XHTML) but they are displaying gibberish. Imagine a future scenario where firewalls filter out all vocabularies except known ones like XHTML. Someone comes along and says: "We really need to route arbitrary new hypertext vocabularies through firewalls. Here's what we'll do. We'll write in NewML and 'serialize' down to HTML. It won't be semantically meaningful HTML, because we'll use all of the element types to mean what we want them to mean, and 'deserialize' back to NewML on the other side. No, even better: we'll make a meta-markup language and every man woman and child can invent their own new hypertext markup languages that serialize to and deserialize from HTML." Now if somebody proposed that, I would have the following responses: * If you needed more features in HTML, did you approach the working group to add them? Having an incompatible bifurcation doesn't seem productive. Maybe we could all benefit from your new features? * If the working group turned you down, did you consider using the existing, documented extension mechanisms? Millions of people have used them with success. How did they fail you? * Why do you have to piggy-back on HTML? Just because HTML slips through firewalls and is popular? Surely your new markup language could have achieved popularity of its own accord on the open market without pretending to be HTML. Why not build on XML (TCP, in our analogy). * Anyhow, why do we even need a framework for building hypertext markup languages? HTML is an extensible hypertext markup language which demonstrably satisfies most if not all distributed hypertext presentation needs. When there are a hundred or a thousand markup language variants, will interoperability be better or worse? These are the questions REST people ask SOAP people. My goal is to clarify why the relationship between SOAP (when running over HTTP) and HTTP is very different than the relationship between HTTP and TCP or TCP and IP. HTTP is "top dog" because it defines the baseline semantics for anything that builds on it, just as XHTML (or RSS or DocBook or...) does. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 03:10 AM 6/07/2002, S. Mike Dierken wrote:
>----- Original Message -----
>From: "Robert Leftwich" <robert@...>
>
> > Adding attachments would simply be a matter of a POST to the
> > patient record URI of an xml-structure containing the link to where the
> > document resides. A similar approach can be taken to change or delete the
> > link (i.e. PUT & DELETE). (Note that attachments are not identified as a
> > sub-resource in their own right as they are simply links and as such it is
> > not really necessary to expose them separately).
>Without an independent URI for the added link, you can't DELETE the link
>(since you can't identify the link you want to delete).
>You'd have to PUT the full patient record with a list of all the links minus
>the one you don't want.
Why do you *have* to PUT the *full* patient record? What is wrong with a PUT
containing a representation of the state the user agent wants changed, in
this case just the links it does want? For example, could the PUT contain a
Content-Model header 'Attachments' that told the server that this is the
only state it wanted to change, all the other state can remain the same?
> > Is there something I am missing in my understanding of the use of ACL in
> > REST, as this approach appears too fragile and inter-dependant for my
>liking?
> >
>Can you provide a concrete example of ACL as it applies to these resources
>so we know what you are seeing from your perspective.
Given the standards focus of REST I thought I would attempt to use the ACL
available in servlets. It supports the association of a role to a
URI/resource and an HTTP method if required, i.e.
<security-constraint>
<!-- web resources that are protected for all access -->
<web-resource-collection>
<web-resource-name>Protected Resource</web-resource-name>
<url-pattern>/patients/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- role-name indicates roles that are allowed
to access the web resources specified above -->
<role-name>system_user</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<!-- specialists attachments that have protected
creation, update & deletion,
i.e are read-only for non-specialist roles -->
<web-resource-collection>
<web-resource-name>Specialists Attachments</web-resource-name>
<url-pattern>/patients/attachments/specialists/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>specialist</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<!-- police attachments that have protected
creation, update & deletion
i.e are read-only for non-police roles -->
<web-resource-collection>
<web-resource-name>Police Attachments</web-resource-name>
<url-pattern>/patients/attachments/police/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>police_officer</role-name>
</auth-constraint>
</security-constraint>
Lets assume that the security requirements change so that you no longer want
all police_officer roles being able to create, update or delete any of the
reports, you only want them to be able to do this to reports from their own
precinct. To do this you will need to change the resource modelling to
include the precinct in order for you to define the resources at the correct
granularity to meet the requirement, e.g.
<security-constraint>
<!-- police attachments that have protected
creation, update & deletion for precinct1
i.e are read-only for non-police roles -->
<web-resource-collection>
<web-resource-name>Police Attachments Precinct 1</web-resource-name>
<url-pattern>/patients/attachments/police/precinct1/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>precinct1_officer</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<!-- police attachments that have protected
creation, update & deletion for precinct 2,
i.e are read-only for non-police roles -->
<web-resource-collection>
<web-resource-name>Police Attachments Precinct 2</web-resource-name>
<url-pattern>/patients/attachments/police/precinct2/*</url-pattern>
<http-method>POST</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>precinct2_officer</role-name>
</auth-constraint>
</security-constraint>
...
>If I had an ACL system that was aware of HTTP messages, I could filter on
>portion of the message - method, content-type, user-id, etc.:
Do you know of any standards based ACL that provides such features?
I am slowly(!) coming to the realization that although REST portrays itself
as being based on existing and long-standing (in web terms) standards, it
really is only based on a small number of very low-level standards (HTTP,
URI, etc) and anything else that is needed to build systems based on its'
principles requires the definition of your own standards or at least the use
of a standardized approach as defined by the few REST gurus, i.e.
asynchronous notifications, reliable delivery , security, authentication,
authorization, orchestration, message payloads, etc. most of which appear to
have yet to be used in anger in systems of any note.
This is an extremely difficult thing to sell to yourself, let alone to your
bosses and clients in the face of the juggernaut that is Web Services ala
SOAP, etc.
Robert
----- Original Message ----- From: "Robert Leftwich" <robert@...> > > Why do you *have* to PUT the *full* patient record? What is wrong with a PUT > containing a representation of the state the user agent wants changed, in > this case just the links it does want? For example, could the PUT contain a > Content-Model header 'Attachments' that told the server that this is the > only state it wanted to change, all the other state can remain the same? Mainly caching - if the next request (by a different client maybe) does a GET on the same URI, a cache could return the last PUT against that URI that is saw. Even if the Accept header said "text/html" the cache isn't required to fail with a 'content type not available' response. > > I am slowly(!) coming to the realization that although REST portrays itself > as being based on existing and long-standing (in web terms) standards, it > really is only based on a small number of very low-level standards (HTTP, > URI, etc) and anything else that is needed to build systems based on its' > principles requires the definition of your own standards or at least the use > of a standardized approach as defined by the few REST gurus, i.e. > asynchronous notifications, reliable delivery , security, authentication, > authorization, orchestration, message payloads, etc. most of which appear to > have yet to be used in anger in systems of any note. I agree with you. I would like to be able to download a fully REST-able adapter for SQL databases, or LDAP systems, or whatever. But that past few years have been spent on the 'visual web' and the types of automation we want - with security, interoperability, multiple document types, pub/sub events - is the next phase. But it will take work. REST is a set of low-level architectural principles - the implementation of the Web is based on only a small number of standardized technologies - because only a small number of technologies /could/ be standardized. The security/authentication/authorization part has the most chance of being standardized - but the Browser Wars left a mess of security due to the failure of HTTP to address the needs of UI based applications. HTTP standardizes identification - there is a header for it - but the mechanism for /verifying/ that identity is still implementation dependent & I believe it has to be. What the "REST crowd" would like to see is awareness within the industry, interest from designers and developers and new ground uncovered in the areas (and others) that you describe. Now that it is easier to look upon the Web from a 'big picture' point of view, we can see more clearly where to go next.
Question re: caching: Do the caching algorithms purge cached "records" based on whether a POST has occurred, so that subsequent GETs have to "go to the source?" This could be a dumb question, but I'm interested because of the impact that this consideration may have on something I'm working on. Seth Johnson "S. Mike Dierken" wrote: > > From: "Robert Leftwich" <robert@...> > > Why do you *have* to PUT the *full* patient record? > > Mainly caching - if the next request (by a different client maybe) does a > GET on the same URI, a cache could return the last PUT against that URI that > is saw. Even if the Accept header said "text/html" the cache isn't required > to fail with a 'content type not available' response. -- [CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html
Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and you can treat it as such. You say "almost no" below, but a requirement for clean layering is that there be zero dependancies. So it's actually a good analogy for extension. 8-O MB -----Original Message----- From: Paul Prescod <paul@...> To: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com> Sent: Fri Jul 05 21:31:10 2002 Subject: [rest-discuss] "Application Protocols" -- an analogy http://blogstream.com/pauls/1025918592 HTTP is an Application Protocol Posted by Paul Prescod on Friday July 05, @06:23PM from the what-the-hell-are-you-REST-guys-talking-about? dept. REST people often say that HTTP is an application protocol and therefore you should not layer a "protocol independent" protocol on top of it, but rather should only use it as is or extend it using documented extension mechanisms. I want to offer an analogy that may clarify this. I think we all agree that HTTP should be the basis for new technologies. The question is whether these new technologies are new layers or new extensions. Here's an analogy that might be useful. TCP is to HTTP as XML is to XHTML. XHTML is layered on top of XML and XML makes almost no semantic demands on XHTML at all. XHTML can use an element like <title> to represent something that is "logically" an attribute and nobody complains. XHTML could use an attribute "date" to represent something that "logically" has sub-structure and if anyone complains it is because they are making life somewhat more difficult for developers. But the XML standard does not say that you should use attributes for "metadata-like things" and elements for "content-like things". It makes almost no semantic demands on the vocabulary at all. You would have to work pretty hard to violate the "semantics" of the XML specification. All you could do, really, is break the syntax -- be not-well-formed. Similarly, applications running on top of TCP have very few semantic responsibilities. Both XML and TCP are designed to say: "do what you want, just obey the syntactic rules of the specification." Now let's go up a step. XHTML is an XML application (in the old "SGML application sense). HTTP is an application protocol. They *do* make semantic demands on things building on top of them. In other words, you MUST extend, not layer, on them. "P" means "paragraph" in XHTML. There should never, ever, be a "layer" that adds another semantic on P like "parachute". That would destroy interoperability with XHTML processors in a very dangerous way. The documents would be valid XHTML (according to validating parsers) but meaningless! You are supposed to extend XHTML with new elements, and you are supposed to "subclass" P with "big paragraph" or "important paragraph" or "disputed paragraph" but you should never state that in "in my variant of XHTML, two P elements in a row means 'table'" Once you've done that, it is no longer a variant of XHTML. It is a semantically incompatible language and interoperability will suffer. Browsers can display it (if it is valid XHTML) but they are displaying gibberish. Imagine a future scenario where firewalls filter out all vocabularies except known ones like XHTML. Someone comes along and says: "We really need to route arbitrary new hypertext vocabularies through firewalls. Here's what we'll do. We'll write in NewML and 'serialize' down to HTML. It won't be semantically meaningful HTML, because we'll use all of the element types to mean what we want them to mean, and 'deserialize' back to NewML on the other side. No, even better: we'll make a meta-markup language and every man woman and child can invent their own new hypertext markup languages that serialize to and deserialize from HTML." Now if somebody proposed that, I would have the following responses: * If you needed more features in HTML, did you approach the working group to add them? Having an incompatible bifurcation doesn't seem productive. Maybe we could all benefit from your new features? * If the working group turned you down, did you consider using the existing, documented extension mechanisms? Millions of people have used them with success. How did they fail you? * Why do you have to piggy-back on HTML? Just because HTML slips through firewalls and is popular? Surely your new markup language could have achieved popularity of its own accord on the open market without pretending to be HTML. Why not build on XML (TCP, in our analogy). * Anyhow, why do we even need a framework for building hypertext markup languages? HTML is an extensible hypertext markup language which demonstrably satisfies most if not all distributed hypertext presentation needs. When there are a hundred or a thousand markup language variants, will interoperability be better or worse? These are the questions REST people ask SOAP people. My goal is to clarify why the relationship between SOAP (when running over HTTP) and HTTP is very different than the relationship between HTTP and TCP or TCP and IP. HTTP is "top dog" because it defines the baseline semantics for anything that builds on it, just as XHTML (or RSS or DocBook or...) does. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/ To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote: > > Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and > you can treat it as such. HTTP connections *are* TCP connections and you can treat them as such. > You say "almost no" below, but a requirement > for clean layering is that there be zero dependancies. So it's actually > a good analogy for extension. 8-O There could never be zero dependencies. HTTP depends on TCP's "reliabilty" semantics. It depends on the fact that TCP is bidirectional and synchronous. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Paul Prescod wrote: > bhaugen32 wrote: > > > > Mark Baker wrote in > > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html > > > > > What's special about the application layer, > > > is that it is the "top dog". > > > You can't layer on top of it and still call > > > yourself a valid use of that protocol. > > > You can only extend it. > > > > How about the case we discussed previously about implementing the > > offer-acceptance business protocol in REST? > > > > There is clearly something else going on that seems to be to > > be "above" the HTTP protocol. As ISO says, you're not just > > exchanging data, you're making business commitments. > > There is something else going on, but it is an extension of HTTP. I > think of things like WebDAV and Offer/Acceptance as plugins. Are you thinking of Offer/Acceptance as a technical thing? It can be implemented via several technical protocols, including REST (as we discussed) or EDI-mailbox-style SOAP (as in ebXML or RosettaNet) or email or fax or paper and ink, for that matter. In each case, what you want to end up with technically is a single document spelling out the business commitment and signed by both parties to signify their agreement. But the essence is in another dimension, where the business commitments live: economic and legal. Also, this is not a case of abusing HTTP as an application protocol, but using it as it was intended in order to achieve this purpose in this other dimension. > > Rohit Khare had an interesting diagram in his recent Soap Routing > > slide show where he added two layers on top the application protocol: > > Layer 8 - Economic (which is where business commitments cd go) > > Layer 9 - Political. > > I was at the talk and in that context it was clear that he meant it more > as a joke. Not "economic protocols" like ebXML but "economic protocols" > like -- how do I con venture capitalists into giving me money? Thanks, I suspected he didn't mean what I meant. But I took it seriously anyway, and still like the idea. And I think ISO and UN/CEFACT think about it in much the same way. What I hear from both groups now is that there is a layer of business protocols on top of the ISO stack, and then a layer of regulatory protocols on top of the business protocols. -Bob Haugen
A good litmus test for layering in my experience, is if the top piece can be defined independantly of the bottom piece. You won't find any mention of TCP in RFC 2616 (I hope - I don't have it handy) for example, but XHTML couldn't exist without XML. A HTTP connection isn't necessarily a TCP connection because of this. This is a really subtle point, but an important one, and one that could do with some more rigorous defintion IMO. MB -----Original Message----- From: Paul Prescod <paul@...> To: Mark Baker <mbaker@...>; rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com> Sent: Sat Jul 06 11:55:55 2002 Subject: Re: [rest-discuss] "Application Protocols" -- an analogy Mark Baker wrote: > > Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and > you can treat it as such. HTTP connections *are* TCP connections and you can treat them as such. > You say "almost no" below, but a requirement > for clean layering is that there be zero dependancies. So it's actually > a good analogy for extension. 8-O There could never be zero dependencies. HTTP depends on TCP's "reliabilty" semantics. It depends on the fact that TCP is bidirectional and synchronous. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Btw, my last response on xml-dist-app to Stuart Williams should explain the answers to the questions you had, Bob. Sorry, don't have a browser handy to look up the URI. MB -----Original Message----- From: bhaugen32 <bhaugen32@...> To: rest-discuss@yahoogroups.com <rest-discuss@...m> Sent: Sat Jul 06 12:23:02 2002 Subject: Re: [PMX:#] [rest-discuss] Top dog Paul Prescod wrote: > bhaugen32 wrote: > > > > Mark Baker wrote in > > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html > > > > > What's special about the application layer, > > > is that it is the "top dog". > > > You can't layer on top of it and still call > > > yourself a valid use of that protocol. > > > You can only extend it. > > > > How about the case we discussed previously about implementing the > > offer-acceptance business protocol in REST? > > > > There is clearly something else going on that seems to be to > > be "above" the HTTP protocol. As ISO says, you're not just > > exchanging data, you're making business commitments. > > There is something else going on, but it is an extension of HTTP. I > think of things like WebDAV and Offer/Acceptance as plugins. Are you thinking of Offer/Acceptance as a technical thing? It can be implemented via several technical protocols, including REST (as we discussed) or EDI-mailbox-style SOAP (as in ebXML or RosettaNet) or email or fax or paper and ink, for that matter. In each case, what you want to end up with technically is a single document spelling out the business commitment and signed by both parties to signify their agreement. But the essence is in another dimension, where the business commitments live: economic and legal. Also, this is not a case of abusing HTTP as an application protocol, but using it as it was intended in order to achieve this purpose in this other dimension. > > Rohit Khare had an interesting diagram in his recent Soap Routing > > slide show where he added two layers on top the application protocol: > > Layer 8 - Economic (which is where business commitments cd go) > > Layer 9 - Political. > > I was at the talk and in that context it was clear that he meant it more > as a joke. Not "economic protocols" like ebXML but "economic protocols" > like -- how do I con venture capitalists into giving me money? Thanks, I suspected he didn't mean what I meant. But I took it seriously anyway, and still like the idea. And I think ISO and UN/CEFACT think about it in much the same way. What I hear from both groups now is that there is a layer of business protocols on top of the ISO stack, and then a layer of regulatory protocols on top of the business protocols. -Bob Haugen To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote: > > A good litmus test for layering in my experience, is if the top piece > can be defined independantly of the bottom piece. You won't find any > mention of TCP in RFC 2616 (I hope - I don't have it handy) for example, > but XHTML couldn't exist without XML. "HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification." But you can imagine a similar state for XHTML (in a world where there were multiple competing markup language syntaxes): "This does not preclude XHTML from being encoded in any other syntax. XHTML only presumes a concept of 'element' and 'attribute'. Blah blah blah blah." In fact it is very trendy these days to define markup languages in terms of the "infoset" and say that "any mapping from any syntax to the infoset is legal." So you could imagine an XHTML this is an extension to the "infoset" but the infoset would be a layer on top of XML itself. (after all, it has been implemented on top of relational databases etc.) > A HTTP connection isn't necessarily a TCP connection because of this. The same goes for many XML specifications. XHTML doesn't happen to have that language in the spec because there is no real competitor to XML (though there are hardly competitors to TCP used much anymore either!). -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Mark Baker wrote, > A good litmus test for layering in my experience, is if the top piece > can be defined independantly of the bottom piece. You won't find any > mention of TCP in RFC 2616 (I hope - I don't have it handy) for > example, but XHTML couldn't exist without XML. Sadly not the case. The best illustration of HTTP's coupling with TCP is the definition of the value of the mandatory Host: request header (see RFC 2616, 14.23). Even tho' TCP isn't explicitly mentioned it's hard to make sense of without the assumption of TCP as the underlying transport protocol. Implicit couplings to TCP show up elsewhere in the spec (particularly in section 8) and also in related RFCs (eg. 2109). IMO HTTPs alleged transport independence is mostly window dressing. Cheers, Miles
On Sat, 6 Jul 2002, Paul Prescod wrote: > Mark Baker wrote: > > > > A good litmus test for layering in my experience, is if the top piece > > can be defined independantly of the bottom piece. You won't find any > > mention of TCP in RFC 2616 (I hope - I don't have it handy) for example, > > but XHTML couldn't exist without XML. > > "HTTP communication usually takes place over TCP/IP connections. The > default port is TCP 80 [19], but other ports can be used. This does not > preclude HTTP from being implemented on top of any other protocol on the > Internet, or on other networks. HTTP only presumes a reliable transport; > any protocol that provides such guarantees can be used; the mapping of > the HTTP/1.1 request and response structures onto the transport data > units of the protocol in question is outside the scope of this > specification." > > But you can imagine a similar state for XHTML (in a world where there > were multiple competing markup language syntaxes): > > "This does not preclude XHTML from being encoded in any other syntax. > XHTML only presumes a concept of 'element' and 'attribute'. Blah blah > blah blah." > > In fact it is very trendy these days to define markup languages in terms > of the "infoset" and say that "any mapping from any syntax to the > infoset is legal." So you could imagine an XHTML this is an extension to > the "infoset" but the infoset would be a layer on top of XML itself. > (after all, it has been implemented on top of relational databases etc.) FWIW we do something similar, and imho more convincing, with RDF. RDF is defined in its own world of edge-labelled graphs, with any mapping to XML (or to unicode/text) being fine. And there _are_ non-XML syntaxes that work for exchanging RDF, so there's definitely some layering going on. Flipside of that is disconnection: by remaining aloof from nitty gritty of the 'lower' layers, the loftier layer risks reinventing useful stuff from below. In SOAP's case, content negotiation etc.; in RDF's case, query mechanisms (XPath, XQuery etc). We can't win... ;-) Dan -- mailto:danbri@... http://www.w3.org/People/DanBri/
Defining it in terms of the Infoset is only a partial defintion (granted, it shoots a hole in my litmus test as currently worded). You still need to pick a serialization in order to be able to realize the thing. And once you've picked a serialization, you are no longer a layer because the serializations themselves remain recognizable. I suppose that true layering is perhaps native to protocols, and doesn't apply to data formats. At least that seems a reasonable hypothesis based on this discussion. Thanks for that text from 2616 - it makes my point about HTTP/TCP, and saves a response to Miles. 8-). In HTTP "0.9" and 1.0, there was actually some poor layering, because a request was said to end if the connection went down (I.e. TCP FIN was effectively given HTTP semantics). MB -----Original Message----- From: Paul Prescod <paul@...> To: Mark Baker <mbaker@...>; rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com> Sent: Sat Jul 06 15:42:53 2002 Subject: Re: [rest-discuss] "Application Protocols" -- an analogy Mark Baker wrote: > > A good litmus test for layering in my experience, is if the top piece > can be defined independantly of the bottom piece. You won't find any > mention of TCP in RFC 2616 (I hope - I don't have it handy) for example, > but XHTML couldn't exist without XML. "HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification." But you can imagine a similar state for XHTML (in a world where there were multiple competing markup language syntaxes): "This does not preclude XHTML from being encoded in any other syntax. XHTML only presumes a concept of 'element' and 'attribute'. Blah blah blah blah." In fact it is very trendy these days to define markup languages in terms of the "infoset" and say that "any mapping from any syntax to the infoset is legal." So you could imagine an XHTML this is an extension to the "infoset" but the infoset would be a layer on top of XML itself. (after all, it has been implemented on top of relational databases etc.) > A HTTP connection isn't necessarily a TCP connection because of this. The same goes for many XML specifications. XHTML doesn't happen to have that language in the spec because there is no real competitor to XML (though there are hardly competitors to TCP used much anymore either!). -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Mark Baker wrote,
> Thanks for that text from 2616 - it makes my point about HTTP/TCP,
> and saves a response to Miles. 8-). In HTTP "0.9" and 1.0, there was
> actually some poor layering, because a request was said to end if the
> connection went down (I.e. TCP FIN was effectively given HTTP
> semantics).
Hmm ... I disagree. The passage that Paul quoted certainly represents
the desire of the WG to make HTTP transport independent, but the
reality is different. The Host: header ties the HTTP to TCP, and it's
semantics couldn't easily be magic'd away by editorial passes between
1.0 and 1.1.
Rather than wrestling with ASCII art UML diagrams, here's a Java
fragement which illustrates the problem,
public interface HttpRequest
{
public HostPortPair getHost();
public void setHost(HostPortPair host);
}
public final class TcpHttpRequest
{
public HostPortPair getHost()
{
// no problem
}
public void setHost(HostPortPair host)
{
// no problem
}
}
public final class NonTcpHttpRequest
{
public HostPortPair getHost()
{
// oops ... how do we implement this?
}
public void setHost(HostPortPair host)
{
// oops ... how do we implement this?
}
}
The problem is probably fixable ... the Host: header might be definable
in a transport independant way without creating other problems. But it
wasn't in RFC 2616. Maybe HTTP/1.2 ;-)
IIRC there are a few threads on this in the HTTP WG mailing list
archive, but I don't have any references handy just now.
Cheers,
Miles
Robert wrote: > Now the security issues come into play. Suppose that for obvious reasons > you want to be able to restrict who can add, update or delete particular > types of attachments. > > Without having individual sub-resources for each of the types in question > there appears to be no way to setup this style of security using ACL. If > you do choose the sub-resources approach, what happens when your security > requirements change? Do you then have to change your resources to match? > > Is there something I am missing in my understanding of the use of ACL in > REST, as this approach appears too fragile and inter-dependant for my > liking? Conceptually, I think applying ACLs as associations between users/groups and resources/representations and HTTP methods makes a lot of sense. For example: Allow(philip, GET, resource1) Allow(administrators, *, *) Deny (guests, *, POST) Deny (*.microsoft.com, *, *) ;-) These could be declared in XML and could be applied to any logical or physical location in a node's namespace. Then S. Mike wrote in response: > If I had an ACL system that was aware of HTTP messages, I could filter > on portion of the message - method, content-type, user-id, etc.: Definitely. I immediately think about filters being a great place to do this....not only to filter at the HTTP message header level, but also at the ACL policy level (e.g., what I show above declared above and beyond optional or mandatory header fields). Good topic. -Philip PS: I just got back from a week of scuba diving in Key West. During a deep wreck dive, I think I achieved Zen on REST and methods. Let me get caught up and I'll send my take.
> -----Original Message----- > From: Philip Eskelin [mailto:philip@eskelin.com] > > Conceptually, I think applying ACLs as associations between > users/groups and resources/representations and HTTP methods > makes a lot of sense. For example: > > Allow(philip, GET, resource1) > Allow(administrators, *, *) > Deny (guests, *, POST) > Deny (*.microsoft.com, *, *) ;-) > > These could be declared in XML and could be applied to any > logical or physical location in a node's namespace. Or in any language that supports aspect oriented programming. Those allow and deny methods look a lot like pointcut operators to me. Bill de hra .. Propylon www.propylon.com
> > Conceptually, I think applying ACLs as associations between users/groups and > resources/representations and HTTP methods makes a lot of sense. For example: > > Allow(philip, GET, resource1) > Allow(administrators, *, *) > Deny (guests, *, POST) > Deny (*.microsoft.com, *, *) ;-) > I've always taken the approach that permissions are declarative relationships between information and users. The 'users' actually could be an individual, a group, etc. I generalize that into 'principal'. The actual storage, caching, updating, etc. in an implementation is what makes a product work in any particular setting. You could bind the permissions to the information, or to the user, or in a third 'link table' or whatever. The principal could be a 'role' and these could be a fixed list and hardcoded into the application logic - there are a lot of choices on how to implement permissions. One interesting aspect is that permissions are relationships between information and users and they 'block' messages coming from many sources to one target, and subscriptions are also relationships between information and users and they 'forward' messages from one source to many targets - and the forwarded messages are echoes of the operations that hit the permission 'block'. There's something important in there somewhere... permissions and subscriptions are tangled somehow. These are the four foundations of applications I enjoy building - information, users, permissions and subscriptions - and they way you manage messages into or out of this system makes it a holistic system. Mike
Philip Eskelin wrote: > >... > > PS: I just got back from a week of scuba diving in Key West. During a deep > wreck dive, I think I achieved Zen on REST and methods. And I thought *I* was obsessed. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Bill de h�ra wrote: > >... > Or in any language that supports aspect oriented programming. Those > allow and deny methods look a lot like pointcut operators to me. And I was thinking of semantic Web languages. ;) Seriously, semantic web languages (e.g. DAML) seem to have the inferencing and subclassing facilities that would allow really sophisticated security rules to be succinctly stated. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 07:47 AM 8/07/2002, Philip Eskelin wrote: >Robert wrote: > > > > Is there something I am missing in my understanding of the use of ACL in > > REST, as this approach appears too fragile and inter-dependant for my > > liking? > >Conceptually, I think applying ACLs as associations between users/groups and >resources/representations and HTTP methods makes a lot of sense. I agree. My original issue was in attempting to fit the requirements to the existing servlet security spec. It is obvious (now) that this spec is not sufficiently powerful/granular to cope with a REST approach. Robert >PS: I just got back from a week of scuba diving in Key West. Just to make you feel even better - it's been somewhere between - (that's minus!) 7 (centigrade) overnight and +10C daytime for the past week or so, not quite scuba weather!
> -----Original Message----- > From: Paul Prescod [mailto:paul@...t] > > Seriously, semantic web languages (e.g. DAML) seem to have > the inferencing and subclassing facilities that would allow > really sophisticated security rules to be succinctly stated. Yes, you can hang some metadata RDF style about security off a resource, and if you use this to fire processing actions, you've reinvented AI slots and frames; not a bad thing imo. And as we were talking about J2EE a few days back, take a look at the JAAS. Syntactically it feels a bit clunky, but underneath it is nicely declarative and gives you a good separation of policy and mechanism. Bill de hra .. Propylon www.propylon.com
Paul wrote: > I don't see the problem. REST is the architecture of the Web and a REST > toolkit would be a piece of software that helps you build the mediating > layer between your application and the Web. AFAIK, that's what (e.g.) > J2EE and Zope are used for. Now that XML has come along it makes sense > to want to extend these things. Just as they had native knowledge of > HTML, you might want to give them native knowledge of XML and RDF. And > maybe newer toolkits could better enforce best practices. But overall, I > see no problem calling any web development platform a REST toolkit. REST > is not something new. I agree with your position that any web development platform could be called a REST toolkit. However, I think a more RESTful toolkit should have types defined in its namespace that correspond to Fielding's documented approach if it's going to make programming RESTfully feel more concretely similar (and IMO easier to comprehend the REST style). For example, here are some of the objects that are being implemented in my toolkit (sorry I keep bringing up my own vaporware, but it's the most concrete thing I have right now): CObject, CString, CList, CTable, CResource, CRepresentation, CConnector, CStream, CRequest, CResponse, CComponent, CFilter, CProxy, etc. Add a handful of sample apps to a class framework like this and you've got a nice simple way to communicate the essence of the RESTful style. -Philip
At 08:27 AM 8/07/2002, S. Mike Dierken wrote: >I've always taken the approach that permissions are declarative >relationships between information and users. What about functionality and users, i.e. restricting the functions those users can perform on the information. This tends to be more of a user-agent issue, but still there needs to be the ability to hide or disable functionality that the current user cannot perform. A declarative mapping from resource permissions to functionality could be useful, but the user agent would need to be able to discover what the resource permissions are. Hmm... if the resource permissions were available as a resource in their own right, then a user-agent could retrieve them and do the mapping as required. Sounds vaguely plausible and is certainly RESTful is it not ? >there are a lot of choices on how to implement permissions. Indeed there are, unfortunately none of which appear to be ideally suited to REST out of the box :-( >There's something important in there somewhere... permissions and >subscriptions are tangled somehow. If you think HTTP Events then the permissions are intimately tied to subscriptions - if you don't have permission to access a resource then you cannot subscribe to it. The issue of the composite resources, i.e. the /site/changes resource is more problematic, the publisher would need to filter notifications based on the subscribers permissions. >These are the four foundations of >applications I enjoy building - information, users, permissions and >subscriptions - and they way you manage messages into or out of this system >makes it a holistic system. It's a concern that we as an industry need to keep on building users, permissions and subscriptions. Why have we still not standardized/componentized these things sufficiently well that we can concentrate on the information, which is where the real value and benefits lie? Robert PS And why is it that my systems end up more as hole-istic rather than holistic :-)
Bill wrote: > > Conceptually, I think applying ACLs as associations between > > users/groups and resources/representations and HTTP methods > > makes a lot of sense. For example: > > > > Allow(philip, GET, resource1) > > Allow(administrators, *, *) > > Deny (guests, *, POST) > > Deny (*.microsoft.com, *, *) ;-) > > > > These could be declared in XML and could be applied to any > > logical or physical location in a node's namespace. > > Or in any language that supports aspect oriented programming. Those > allow and deny methods look a lot like pointcut operators to me. This is a very interesting take. I hadn't of that. How might you implement it? I understand AOP but I'm not sure I understand how you would integrate that into this conceptual approach. Do you mean pointcut operators applied to doFilter methods inside filter components? -Philip
On 7/7/02 5:40 PM, "Paul Prescod" <paul@...> wrote: > Philip Eskelin wrote: >> >> ... >> >> PS: I just got back from a week of scuba diving in Key West. During a deep >> wreck dive, I think I achieved Zen on REST and methods. > > And I thought *I* was obsessed. My gestalt happened in the shower... That's a whole lot more mundane; Phil, I'm envious. ;-) :-) Jb
----- Original Message -----
From: "Robert Leftwich" <robert@...>
>
> What about functionality and users, i.e. restricting the functions those
> users can perform on the information.
Those functions are communicated via messages and the permissions are
filters that use data from those messages.
So I guess permissions are relations between users and information AND with
patterns/pointers into (prototypical) messages.
>A declarative mapping
> from resource permissions to functionality could be useful, but the user
> agent would need to be able to discover what the resource permissions are.
Sure - getting a repesentation in XML is easy.
>
> Hmm... if the resource permissions were available as a resource in their
own
> right, then a user-agent could retrieve them and do the mapping as
required.
> Sounds vaguely plausible and is certainly RESTful is it not ?
Yep - you wouldn't /evaluate/ the permissions, but you can do some great UI
hints.
> If you think HTTP Events then the permissions are intimately tied to
> subscriptions - if you don't have permission to access a resource then you
> cannot subscribe to it.
Being subscribed to a resource is the same as reading the future of a
resource - so the only
permissions you need are GET permissions (or 'read' permissions if you are a
old fogey into those archaic things called operating systems).
Depending on how you implement the relation between info and users, the act
of creating a subscription is either an act upon the information, or perhaps
an act upon a user, or an act upon a third entity (a collection of
permissions). That third entity would have permissions unto itself. Fun...
> The issue of the composite resources, i.e. the
> /site/changes resource is more problematic, the publisher would need to
> filter notifications based on the subscribers permissions.
You have to filter on the current state of the subscribers GET ('read')
permission on the resource - somewhat intensive, unless you are willing to
live with latency, and then you could have the subscription(s) listen for
changes to permissions on the subscribed resource. (it sounds complicate,
but honest it really isn't - i've done this stuff with RDBs as the backend
and it was very straightforward...)
>
> It's a concern that we as an industry need to keep on building users,
> permissions and subscriptions. Why have we still not
> standardized/componentized these things sufficiently well that we can
> concentrate on the information, which is where the real value and
> benefits lie?
I'm amazed that OSes don't ship with all four aspects out of the box - file
systems are fine for information (ignoring searchability), but there are no
common/standardized subscription mechanisms on that and certainly no common
directory systems. Heck, my OutlookExpress address book is my personal
directory service - I'd love to have LDAP into that thing...
Paul wrote: > Philip Eskelin wrote: > > > >... > > > > PS: I just got back from a week of scuba diving in Key > > West. During a deepwreck dive, I think I achieved Zen on > > REST and methods. > > And I thought *I* was obsessed. I'm not finished catching up, so pardon me if I take anyone off their thread. During my dive, I realized that in order for me to see the fish around the wreck, and swim across the ship's deck to a payphone and act like I'm placing a call, I must go to the site first. I can't do any of it from the boat. I swim to the mooring buoy and descend down the line to the wreck....i.e., I transfer myself. I probably went over the top with my analogy. But what it helped me realize is that when you boiled it down, my notion of method - and even my revised notion (after our noun vs. verb discussion) - was *yet* another RPC! Makes me cringe ;-). Bottom line: to break away from an RPC over the Internet, why not just take 'remote' out of RPC and replace it with 'local'? And how do you do that in REST? You GET a representation of the resource, invoke your method locally, and then POST the updated representation back to the resource. That's it. Wasn't it Tip O'Neill that said "all politics is local"? You get the idea... -Philip
Jeff wrote: > Paul wrote: > > Philip Eskelin wrote: > > > > > > ... > > > > > > PS: I just got back from a week of scuba diving in Key > > > West. During a deep wreck dive, I think I achieved Zen > > > on REST and methods. > > > > And I thought *I* was obsessed. > > My gestalt happened in the shower... That's a whole lot more mundane; > Phil, I'm envious. ;-) :-) Glad to be back on the list! To combine my "method Zen" with the security discussion and Mike's comments about the role (pun intended) of subscriptions, here is a contrast that I find interesting: Old Way (DCE RPC, ONC RPC, EZ-RPC, Microsoft RPC, CORBA, DCOM, RMI, XML-RPC, SOAP, etc): 1. Remote message to a server requesting subcription to a topic 2. Remote response by server indicating the results 3. Remote message to server indicating update to topic by a publisher client(s) 4. Remote server sends (or multicasts) an update to each remote subscriber 5. Remote message to server requesting any or all of the topic's contents New Way (REST, WebDAV?, etc): 1. Subscriber client creates subordinate representation (r1) of a subscription 2. HTTP POST of r1 to the remote topic's Subscriptions-URI resource, including a Subscriber-URI entity field if the client desires real-time event notifications 3. Publisher client creates subordinate representation (r2) of an update relative to the topic's watched content resource 4. HTTP POST of r2 to the remote topic's Watched-URI resource 5. Server translates and/or forwards r2 via HTTP PUT to each subscriber client's Subscriber-URI resource 6. HTTP GET to the remote topic's Watched-URI resource to fetch any or all of the topic's contents Notice the common theme is that old method invocations are remote, and new invocations are local. For REST, invocations don't happen over the network at the "application-semantic" level, unless it's GET, PUT, POST, or DELETE. Whether the data requested in old #5 or new #6 is fetched remotely may depend on features like: throttles, caching rules, filtering ACL policies, existence of proxies, etc. With the old method, it seems that snapping in these features would become dismally over-complicated. Since the new method does all method invocations locally, the semantics of these features sit at the HTTP level, which is a very RESTful and *much* simpler approach. Additional, detailed differences between the two approaches could take up several pages. Comments/thoughts on the contrast? Should we post something more polished like it on RESTwiki? -Philip
Okay, I have only just joined this group (and rest-explore), so bear with me as I get up to speed here. I have been reading (and reading and reading) information on REST. I have watched an endless number of REST-related debates on xml-dev. I have probably seen just about ever argument made for and against REST. At times, I have thought I understood REST enough to see its value. At other times, I have looked at REST and seen nothing of value. And in the end, I am exactly where I started off. Maybe this has to do with the fact that every time I see REST, it is joined at the hip with HTTP. I know that REST is a methodology and HTTP is an implementation. I also know that a lot of people say that HTTP is an example of REST. But that's where the relationship stops for me. HTTP (in it's original incarnation, as I understand it) had a very simple purpose: provide a simple technique to allow researchers to share their works with other researchers. The purpose of HTTP was simple. The implementation of HTTP was simple. But, as far as I can see, the fact that it is RESTful is just as much a coincidence as anything else. So, if this is the case, why does everyone keep getting hung up on HTTP when discussing REST? It seems to me that the "REST effort" would progress much better if all conversations would just drop HTTP and talk about implementations in general. I think that a lot of people (including myself) end up having a hard time determining if an argument is about REST or the "RESTfulness of HTTP". HTTP may be a good example of the REST principles, but that's all it should be. Maybe we could come up with (assuming there isn't already) a fictitious RESTful implementation (NOT BASED ON HTTP) that would allow discussions of REST without losing focus or making it difficult for us newer guys to figure out which is about REST and which is about something related to REST. --- Seairth Jacobs seairth@... p.s. I'm not looking for a flame war here. I just want to figure out what REST is all about without having to deal with the excess baggage of HTTP.
Quite often, URIs (especially the URL subset) are used has "noun" examples when discussing REST. Is this due to the fact that most discussions are also talking about HTTP (see my last post), or is there something about a URI that is particularly RESTful in of itself? --- Seairth Jacobs seairth@...
I do not know whether this is more appropriate for this list or the rest-explore list. I have written down some ideas I had a while back. While writing it down, I tried to keep REST (as I understood it at the time) in mind during some of the design process. I would be curious to see what others thought about how RESTful this is or is not and what would improve it's RESTfulness. If nothing else, this may allow me to better understand REST principles at work by looking at something in a context I am familiar with (that isn't HTTP). Note that this is a draft document (and all that goes with it). http://www.seairth.com/web/rpc/gtp.html --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > The purpose of HTTP was simple. The implementation of > HTTP was simple. But, as far as I can see, the fact that it is RESTful is > just as much a coincidence as anything else. HTTP was simple. And it succeeded. And it grew. And it /continued/ to succeed. Why was that? If you list the reasons, and give that list a name, you will have 'named' the principles of the Web architecture. Roy just happened to call it REST. In other words - HTTP happened first, REST was the name made up to explain it. > So, if this is the case, why > does everyone keep getting hung up on HTTP when discussing REST? Not every discussion of REST falls back on HTTP. I've talked a small amount about using JMS with REST concepts - addressability, minimal methods, multiple representations for an entity, etc. Refering back to HTTP is just a way of giving concrete examples and avoiding academic ivory towers. > It seems to me that the "REST effort" would progress much better if all > conversations would just drop HTTP and talk about implementations in > general. I think that a lot of people (including myself) end up having a > hard time determining if an argument is about REST or the "RESTfulness of > HTTP". HTTP may be a good example of the REST principles, but that's all it > should be. Maybe we could come up with (assuming there isn't already) a > fictitious RESTful implementation (NOT BASED ON HTTP) that would allow > discussions of REST without losing focus or making it difficult for us newer > guys to figure out which is about REST and which is about something related > to REST. Okay. Start a page on the Wiki. But remember, an implementation of REST shines when it is large-scaled and network based - single-user/single-machine APIs have a lot of other issues and tradeoffs that make REST not a clear choice.
> Quite often, URIs (especially the URL subset) are used has "noun" examples > when discussing REST. Is this due to the fact that most discussions are > also talking about HTTP (see my last post), or is there something about a > URI that is particularly RESTful in of itself? For me, REST is a about remote, untouchable 'resources' - and in order to interact with them, they need to be identified. This 'identity' aspect seems fundamental to REST. And it seems easier to talk about noun-oriented things when you talk about things with identity. Really /anything/ can be identified - methods, operations, transactions, etc. - but when you have identity, it seems to 'noun-ify' whatever you are talking about.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > I do not know whether this is more appropriate for this list or the > rest-explore list. I have written down some ideas I had a while back. > While writing it down, I tried to keep REST (as I understood it at the time) > in mind during some of the design process. I would be curious to see what > others thought about how RESTful this is or is not and what would improve > it's RESTfulness. If nothing else, this may allow me to better understand > REST principles at work by looking at something in a context I am familiar > with (that isn't HTTP). Note that this is a draft document (and all that > goes with it). > > http://www.seairth.com/web/rpc/gtp.html > Cool. >> "In data manipulation, there are five basic possible actions: ADD, EDIT, DELETE, GET, and PUT" Coming up with basic actions for data manipulation is a great start. I've had problems with the particular ones from HTTP, as well as the ones from SQL. With ADD, what are you adding data to? Why isn't there a remove? Interesting... I'll have to take some time with this paper. Thanks.
From: "S. Mike Dierken" <mdierken@...> > >> "In data manipulation, there are five basic possible actions: ADD, EDIT, > DELETE, GET, and PUT" > Coming up with basic actions for data manipulation is a great start. I've > had problems with the particular ones from HTTP, as well as the ones from > SQL. > With ADD, what are you adding data to? Why isn't there a remove? The actual use of the verbs is somewhat relative to the application. In the case of ADD, it is only useful in a situation where you want to "add" something to the target. For instance, you might "add" a contact to a contacts resource. Using PUT is not necessarily sufficient here because you still have to indicate that you want to add the resource. DELETE is the "remove". Truthfully, data entry only has four verbs (3 push/1 pull): ADD, EDIT, DELETE, GET. However, a problem one encounters in a loosely coupled system is that we don't always know which push verb to use. This is why I include the PUT operation. This allows the source to "loosely" send data to the target. I should also point out that the verbs chosen in GTP are not related to HTTP verbs in any way, though a few are named the same. > Interesting... > I'll have to take some time with this paper. Thanks. Yes, take a look. I have tried to show some examples to clarify the verbs. If you want more, I'd be happy to give more. Give me a scenario and let me see if I can "implement" it in GTP. Also, what do you think of the [potential] RESTfulness of GTP? Am I at least in the ballpark, as far as you see it? Or is this approach not what REST is about? I do have some doubts about the relationship between REST "state transfers" and GTP. --- Seairth Jacobs seairth@...
Pardon my ignorance, but while we are getting all Zen here...Is REST just CRUD? || 'CRUD' || 'REST' || || Create || PUT || || Read || GET || || Update || POST || || Delete || DELETE || Add to this globally unique UID's (via lovely URI's) and you turn the whole world into one large addressable database where each thing is a BLOB. It seems simple yet earth shattering to me. Think of all the glue I can write now. ;) Is this too simple? Am I missing something? Is google the new SQL? cheers, bld This message contains information from Equifax, Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e:mail postmaster@....
----- Original Message ----- From: <Bruce.Durling@...> > Pardon my ignorance, but while we are getting all Zen here...Is REST just > CRUD? > > || 'CRUD' || 'REST' || > || Create || PUT || > || Read || GET || > || Update || POST || > || Delete || DELETE || > > Add to this globally unique UID's (via lovely URI's) and you turn the whole > world into one large addressable database where each thing is a BLOB. It > seems simple yet earth shattering to me. Think of all the glue I can write > now. ;) > You are very close - the specific meaning of each operation /is/ different, but the analogy is sound. Unfortunately RDBMS doesn't have uniform/universal addressing - at least I personally don't know how to use SQL to talk about (and operate upon) databases, tables, columns, etc. In terms of SQL (I don't know if the CRUD words match the SQL operators...) PUT = "Upsert" (Update or Insert as necessary) DELETE = Delete POST = Insert (and maybe Alter Table, Create Table) GET = Select
Bruce.Durling@... wrote: > > Pardon my ignorance, but while we are getting all Zen here...Is REST just > CRUD? This is a meme I'm starting to promote. >... > Add to this globally unique UID's (via lovely URI's) and you turn the whole > world into one large addressable database where each thing is a BLOB. It > seems simple yet earth shattering to me. Think of all the glue I can write > now. ;) Even better, think of all of the glue you can avoid writing, because interoperability falls out of the architecture. ;) > Is this too simple? Am I missing something? Is google the new SQL? I would say that HTTP is to networked applications what SQL is to relational databases. It's an important analogy but it is more than an analogy. The "few methods" concept seems to fall out of the universe itself. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
It's important to point out that while the CRUD analogy is good, it's only good with respect to the generic interface part of the architecture. REST is about more than just the generic interface. MB
Miles Sabin wrote: > >... > > Sadly not the case. > > The best illustration of HTTP's coupling with TCP is the definition of > the value of the mandatory Host: request header (see RFC 2616, 14.23). > Even tho' TCP isn't explicitly mentioned it's hard to make sense of > without the assumption of TCP as the underlying transport protocol. > Implicit couplings to TCP show up elsewhere in the spec (particularly > in section 8) and also in related RFCs (eg. 2109). IMO HTTPs alleged > transport independence is mostly window dressing. IMO, transport independence is mostly hype anyways. IP needs to be transport independent. But above IP, I don't see that it really ends up mattering. If you want to use HTTP, you might as well roll out TCP and IP because they will be useful for other things anyways! -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On 7/8/02 8:49 AM, "Seairth Jacobs" <seairth@...> wrote: > Truthfully, data entry only has four verbs (3 push/1 pull): ADD, EDIT, > DELETE, GET. However, a problem one encounters in a loosely coupled system > is that we don't always know which push verb to use. This is why I include > the PUT operation. This allows the source to "loosely" send data to the > target. > > I should also point out that the verbs chosen in GTP are not related to HTTP > verbs in any way, though a few are named the same. Seairth, I dont mean to stir the pot, but what you've just described *is* semantically equivalent to HTTP. It seems to me that you only differ on the detail and "syntax," not the high-level semantics. To wit: GTP HTTP ------ ----- GET GET DELETE DELETE EDIT PUT or POST ADD PUT or POST PUT xxx response code The major exception seems to be that you have a notion of a "response method" indicated by PUT. I'm not sure what that buys you, really. Consider: HTTP PUT creates / replaces / updates the state of a resource given some data (representation) of the desired resource state. When performed on an enclosing container resource, this can be considered an ADD. Similarly, when performed on any existing resource, it's an EDIT. Your PUT, in the backchannel case, is basically equivalent to (a single, nonspecific) HTTP response code --- truthfully, it doesn't serve much purpose at all, because subsequent information would be needed to discern the actual intent / meaning of the resource. In general, your model - as with HTTP applications that use PUT - seems to work with a less abstract notion of resource than i.e. applications that encapsulate resource state behind GET and POST; with POST-based apps, you can't ever actually set the state of a resource directly, at best you ask the resource or its container to do that for you. You never GET resource state directly, you merely get a representation. And that encapsulation is a good thing. Your model is actually weaker than HTTP, because it doesn't accommodate the more abstract application of POST, meaning "feed some arbitrary data to a resource" with the resource itself being responsible for the interpretation. (If PUT is a valid GTP *request* method, then GTP isn't weaker --- it's semantically equivalent, as originally asserted.) Similarly, I'm not sure what ONX buys you over XML. In both cases (GTP/HTTP, ONX/XML) the differences seem superficial at best. I don't mean to dis your effort, but it's worth asking whether your effort wouldn't be better spent trying to get what you want to do done with HTTP and XML rather than reinventing them. We see further when we stand on the shoulders of giants. :-) $0.02, Jb
----- Original Message ----- From: "Mark Baker" <mbaker@...> To: <Bruce.Durling@...>; <rest-discuss@yahoogroups.com> Sent: Monday, July 08, 2002 10:28 AM Subject: RE: [rest-discuss] Is REST CRUD? > It's important to point out that while the CRUD analogy is good, it's > only good with respect to the generic interface part of the > architecture. REST is about more than just the generic interface. > Yes - I forgot to mention that in my e-mail... a RDBMS is solving a different problem, so it won't have the same list of architectural characteristics as REST, but the flexibility to implement any application-specific operation on top of CRUD is similar to the ability to implement any application-specif operation on top of GPPD (GET/PUT/POST/DELETE).
Seairth Jacobs wrote: > >... > > Maybe this has to do with the fact that every time I see REST, it is joined > at the hip with HTTP. This bothers many people but it is important to understand that one of the central virtues of REST is *standardization* of interfaces. It isn't the case that any protocol with generic interfaces is equal to any other one. The one that is deployed is (all else equal) MUCH BETTER because of the interoperability you get out of using it. > ... I know that REST is a methodology and HTTP is an > implementation. I also know that a lot of people say that HTTP is an > example of REST. But that's where the relationship stops for me. HTTP (in > it's original incarnation, as I understand it) had a very simple purpose: > provide a simple technique to allow researchers to share their works with > other researchers. But what does it matter what HTTP was intended to do 12 years ago. HTTP has evolved quite a bit if you look at the specifications. There is nothing in those specifications that is specific to some particular problem domain. >... > It seems to me that the "REST effort" would progress much better if all > conversations would just drop HTTP and talk about implementations in > general. Until there is a second REST-designed protocol, HTTP *is* about as general as we can get. Plus, a big attraction of REST to me is the power of HTTP tools. * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0074.html -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Right. But you bring up another point that anybody promoting (or using) the generic interface should remember; GET/POST/PUT/DELETE *might* be sufficient (actually, GET and POST might be), but REST says that the interface can be extended if you want to, so long as the new method is generic to all resources, like LOCK, WATCH, etc.. Though I can understand not mentioning this first to emphasize how general the existing methods are, and to get people thinking about how to solve their problems using only those methods. Perhaps at the end of the talk or whatever, just say "oh yah, and you can add new methods". 8-) MB -----Original Message----- From: S. Mike Dierken Sent: Mon 7/8/2002 2:12 PM To: Bruce.Durling@equifax.com; rest-discuss@yahoogroups.com; Mark Baker Cc: Subject: Re: [rest-discuss] Is REST CRUD? ----- Original Message ----- From: "Mark Baker" <mbaker@idokorro.com> To: <Bruce.Durling@equifax.com>; <rest-discuss@yahoogroups.com> Sent: Monday, July 08, 2002 10:28 AM Subject: RE: [rest-discuss] Is REST CRUD? > It's important to point out that while the CRUD analogy is good, it's > only good with respect to the generic interface part of the > architecture. REST is about more than just the generic interface. > Yes - I forgot to mention that in my e-mail... a RDBMS is solving a different problem, so it won't have the same list of architectural characteristics as REST, but the flexibility to implement any application-specific operation on top of CRUD is similar to the ability to implement any application-specif operation on top of GPPD (GET/PUT/POST/DELETE).
Paul, > -----Original Message----- > From: Paul Prescod [mailto:paul@prescod.net] > > Bruce.Durling@... wrote: > > > > Pardon my ignorance, but while we are getting all Zen > here...Is REST > > just CRUD? > > This is a meme I'm starting to promote. And don't stop at CRUD. Here's about as far as I got to in terms of similarities, and I'm sure you could tweak it to make a bit more sense. My interest was in mapping Linda onto HTTP. http sql linda jspaces cvs GET SELECT rd/in read update/checkout PUT CREATE out write add POST UPDATE out write commit DELETE DELETE cin take remove noop (triggers) noop notify (sendmail ;) Miles Sabin (cc'd) said once it might possible to use DDDS to support a global tuplespace; his interest was mapping Linda onto Rest. Noteworthy: Linda doesnt have a single namespace, which is a mistake Mark Baker pointed out to me a while back. What Mark Baker said is important though; few methods is just one aspect of Rest. As an aside: a lot of process synchronization problems can be handled by applying best practices for CVS, rather than global locking schemes (as per SourceSafe), which maybe wouldn't be planetary scalable anyway. Javaspaces has done a good job on the semantics for synchronization on read and write ops. Bill de hra .. Propylon www.propylon.com
On 7/8/02 2:56 PM, "Bill de hra" <dehora@...> wrote:
> Noteworthy:
> Linda doesnt have a single namespace, which is a mistake Mark Baker
> pointed out to me a while back...
IMO, the right mapping from Linda->the Web does *not* assume that the Web
itself constitutes a global tuplespace. After all, Linda's methods (in, rd,
out) are operations on a tuplespace; the Web's GET, POST, DELETE are
operations on resources, not on the Web as a whole (whatever that means).
So the right mapping is tuplespace->resource, not tuplespace->HTTP
namespace. The HTTP namespace merely provides an arbitrarily large number
of named tuplespaces, i.e. resources. Equivalently, resources aren't
tuples, they're tuplespaces.
A more detailed explanation of a Webby Linda mapping can be found at
http://internet.conveyor.com/RESTwiki/moin.cgi/LindaAndTheWeb
> As an aside: a lot of process synchronization problems can be handled by
> applying best practices for CVS, rather than global locking schemes (as
> per SourceSafe), which maybe wouldn't be planetary scalable anyway.
<RANT>
Not exasperated with you particularly, Bill, but let me rant for a sec:
Could we all get over this whole idea of locking as necessary or desirable
for versioning, avoiding conflict in object evolution, etc.? It's a
side-effect of a bad storage metaphor, namely that stored entities are
mutable. Stored entities need not be mutable: imagine a filesystem in
which stored files are immutable, identified by OIDs (maybe hashes), and
accessible directly via those names or more conveniently via names. What's
mutable is the file name->stored objects (i.e. bits), and indeed a canonical
mapping must be maintained, but that can be done heuristically. With the
addition of a stream of representations of mutations in the name->stored
object mappings --- something like a filesystem journal --- it is possible
to have complete and implicit file versioning.
The evolutionary history of a given file is then an arbitrarily bushy tree
of immutable stored entities, and the "canonical" version is just the
particular version that happens to be pointed to by some name in a
hierarchical namespace at some given time. The history / version graph
itself can be reconstructed from the journal and consulted / heuristics
applied to generate the canonical mapping in the case of conflicts.
If we factor the notions of naming and storage and assume immutability, then
the problem isn't just solved, it *disappears.* Really. This is one of
those problems we can just define away by appropriate abstraction.
Check out Tannenbaum's Amoeba operating system and its fileserver ("bullet")
/ directory server architecture. Also, Plan 9 has a new archival filesystem
architecture called Venti that applies essentially the same concepts to
block-level storage.
These issues are rather near and dear to my heart --- they're part of the
Deepfile "Big Picture." I just cringe whenever people talk about
versioning, locking, DAV, CVS, etc. because most people don't recognize that
these are only band-aids on what is fundamentally a sick and empoverished
filesystem metaphor.
</RANT>
Cheers!
Jb
I was trying to draw a protocol analogy to XML/XHTML. The best I could come up with was; XML is to XHTML as HTTP is to Yahoo. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> Jeff Bone: > These issues are rather near and dear to my heart --- they're > part of the Deepfile "Big Picture." I just cringe whenever > people talk about versioning, locking, DAV, CVS, etc. because > most people don't recognize that these are only band-aids on > what is fundamentally a sick and empoverished filesystem metaphor. Jeff, I didn't recognise that and I'm glad you said it. I do think filesystems (or rather directories) are a pretty impoverished as a user interface. I hate having to micro-manage files by naming versions of them and figuring out what directories they should go into. I also imagine you've got opinions on Lifestreams? Bill de hra .. Propylon www.propylon.com
Bill de h�ra wrote, > Miles Sabin (cc'd) said once it might possible to use DDDS to support > a global tuplespace; his interest was mapping Linda onto Rest. I take that back ;-) I think I now now how to build a fully distributed tuple space, but it doesn't bear any particularly interesting relationship to HTTP or REST (hint, take a peek at http://citeseer.nj.nec.com/460728.html). And I now also think that some REST idioms are much more closely related to Pi Calculus than anything else (tho', to be honest, that's probably stretching things a bit). REST interests me a bit, but mostly for reasons that are likely to be anathema to dyed in the wool RESTians ... Cheers, Miles
From: "Jeff Bone" <jbone@...>
>
> Seairth, I don�t mean to stir the pot, but what you've just described *is*
> semantically equivalent to HTTP. It seems to me that you only differ on
the
> detail and "syntax," not the high-level semantics. To wit:
>
> GTP HTTP
> ------ -----
> GET GET
> DELETE DELETE
> EDIT PUT or POST
> ADD PUT or POST
> PUT xxx response code
>
> The major exception seems to be that you have a notion of a "response
> method" indicated by PUT. I'm not sure what that buys you, really.
Actually, GTP is a good deal different from HTTP (at least as I see it).
One of the primary differences is that it is not necessarily a client-server
protocol. It is perfectly correct send a PUT message and get a DELETE
message in return. In other words, there is no set relationship between
what message is received based and what message was sent. This is an
application-specific issue, not a protocol issue. HTTP has a distinctive
client and server parts. Yes, it is possible to have a given application
implement both parts and effectively allow for peer-to-peer communication.
But, to my knowledge, this was not the intent of HTTP (and more or less
still isn't). On the other hand, it is entirely forseeable to design
peer-to-peer, client-server, etc. applications in GTP.
If you were to map GTP verbs to HTTP verbs (sticking to the client-server
pattern only), you would probably end up with:
HTTP GTP
----- -----
GET GET
DELETE DELETE
PUT GET, conditionally followed by an ADD or EDIT
POST PUT
response PUT, always used as the "response" from the "server"
Again, a request can potentially receive a response that uses any of the
verbs. PUT is just the most generic response and is equatable to HTTP
responses *when implementing an HTTP-like GTP-based application*. The real
strength is in being able to get back any sort of message. Here are some
examples:
* Two peer-to-peer programs could use PUT to send heartbeats to one another.
* An "offline address book" client application could send a PUT message to a
server, which would return an EDIT message to instruct the client to update
one or more local entries.
* A client application could initiate a session with a GET message. The
server may then respond with a GET message indicating that it wants to know
more about the client capabilities. The client would then respond with a
PUT message.
* One server (A) could be queuing requests to go to another server (B).
Server A might start with a PUT message to Server B to indicate its status.
Server B would then issue a GET message for the next message in the queue.
Server A would then send whatever message was queued. This process would
repeat itself until Server A sent a final PUT message indicating that there
are no more queued messages.
It may be possible to force implementation all of the above on top of HTTP,
but that feels to me like the proverbial "square peg in a round hole". This
is why I do not consider GTP and HTTP to be "semantically equivalent".
> Consider: HTTP PUT creates / replaces / updates the state of a resource
> given some data (representation) of the desired resource state. When
> performed on an enclosing container resource, this can be considered an
ADD.
> Similarly, when performed on any existing resource, it's an EDIT. Your
PUT,
> in the backchannel case, is basically equivalent to (a single,
nonspecific)
> HTTP response code --- truthfully, it doesn't serve much purpose at all,
> because subsequent information would be needed to discern the actual
intent
> / meaning of the resource.
Part of this, I think I have already answered up top. As for the HTTP PUT
verb being an "ADD if not exist, otherwise EDIT", I have always had issues
with this. PUT is the logical equivalent of:
IF GET
EDIT
ELSE
ADD
END
In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb.
You are attempting to perform a compoung command using a single command.
This seems to me to be a particularly non-RESTian verb.
> In general, your model - as with HTTP applications that use PUT - seems to
> work with a less abstract notion of resource than i.e. applications that
> encapsulate resource state behind GET and POST; with POST-based apps, you
> can't ever actually set the state of a resource directly, at best you ask
> the resource or its container to do that for you. You never GET resource
> state directly, you merely get a representation. And that encapsulation
is
> a good thing. Your model is actually weaker than HTTP, because it doesn't
> accommodate the more abstract application of POST, meaning "feed some
> arbitrary data to a resource" with the resource itself being responsible
for
> the interpretation. (If PUT is a valid GTP *request* method, then GTP
isn't
> weaker --- it's semantically equivalent, as originally asserted.)
Okay, given that GTP PUT can be used like HTTP POST and that GTP is not like
HTTP, would you still say that GTP is still weaker? GTP allows the
"representation" of a resource to be sent instead of the resource itself. A
GTP message can never perform an action. Only the recipient can determine
what actions can and can't be taken. Only the recipient performs the actual
action. To me, this is REST-like abstraction. The actual level of
abstraction reached depends entirely on the actual implementation of a
GTP-enabled application. GTP just makes the facilities available.
You know, I am almost beginning to get an idea. Maybe GTP is more of a
generic foundation protocol. GTP itself is neither RESTful not non-RESTful.
Instead, it provides a foundation on which RESTful applications can be built
(a la HTTP-alike). HTTP is more of a combination of a protocol and an
application in this sense. Increasingly, people are using HTTP less as an
application and more as a foundation protocol. The difference is that GTP
is designed from the ground up to provide only the foundation and leaves the
actual REST implementation to the application level that sits on top of it.
On the other hand, maybe I am just fooling myself here. :)
> Similarly, I'm not sure what ONX buys you over XML. In both cases
> (GTP/HTTP, ONX/XML) the differences seem superficial at best.
Yes, ONX is similar to XML. However, the devil is in the details. ONX is
specifically designed to accomodate data in ways that XML is unsuited for.
It is also designed to be more efficiently parsable. This allows for faster
processing times and faster network transmission times. As I point out in
the GTP introduction, GTP could be written with XML as well. "ONX vs. XML"
is not the issue here.
> I don't mean to dis your effort, but it's worth asking whether your effort
> wouldn't be better spent trying to get what you want to do done with HTTP
> and XML rather than reinventing them. We see further when we stand on the
> shoulders of giants. :-)
And yet, if HTTP and XML were truly the "dynamic duo" that everyone wants to
believe they are, this list (and several others) wouldn't exist.
---
Seairth Jacobs
seairth@...
> Mark Baker wrote: > > It's important to point out that while the CRUD analogy is good, it's > only good with respect to the generic interface part of the > architecture. REST is about more than just the generic interface. > S. Mike Dierken wrote: > > Yes - I forgot to mention that in my e-mail... a RDBMS is solving a > different problem, so it won't have the same list of architectural > characteristics as REST, but the flexibility to implement any > application-specific operation on top of CRUD is similar to the ability to > implement any application-specif operation on top of GPPD > (GET/PUT/POST/DELETE). I find the idea of a Resource having many Representations bears many similarities to the idea of a Logical Entity (as in logical vs. physical models) in Relational Theory. In SQL, views provide representations of logical entities that may span many physical tables. Obviously the mechanism for identifying and resolving an entity is different to identifying and resolving a resource but the principles seem similar. Can a *View* in SQL be considered a rough equivalent to a *Representation* of a resource in REST? Unfortunately SQL Databases don't allow updates through views that span multiple tables. Therefore a true separation of the logical model from the physical model has never been fully realised :-( Fortunately for a REST+HTTP based architecture this separation seems to be fundamental in the sense that I can PUT/POST one representation to a resource (assuming of course that the resource understands and supports them) and GET a different one back based on Content Negotiation, Etags or URI query parameters. Robert.
>> The major exception seems to be that you have a notion of a "response >> method" indicated by PUT. I'm not sure what that buys you, really. > > Actually, GTP is a good deal different from HTTP (at least as I see it). > One of the primary differences is that it is not necessarily a client-server > protocol. The distinction between client-server and peer-to-peer has everything to do with overall system architecture - with the roles the various components play in the context of a single interaction - and, really, very little to do with the underlying protocol. Having built, I think, the first Internet-scale commercial p2p app (Ding!), I think I can safely make some assertions, here. ;-) I've generally found C-S to be an inadequate distinction --- really, you want to think about whether components initiate or service a request in a given interaction; a component that plays the role of a server in one interaction might be a client in the next; indeed, proxy components play both roles in the context of a single conceptual interaction (server to the initiating client, client to the origin server.) Another distinction is whether responses are synchronous or asynchronous (or both) with requests --- this issue is orthogonal but related to C-S v. p2p. As discussed ad nauseam early in this list's lifecycle, either is sufficient to model the other. The short version is that you don't need new protocols beyond HTTP to do things like "p2p" or async --- assuming that the semantics of the supported methods are equivalent. The protocol should describe the interactions between components at a semantic level. Again, given the similarity between the semantics, I see no need for a new application protocol. > It may be possible to force implementation all of the above on top of HTTP, > but that feels to me like the proverbial "square peg in a round hole". :-/ I see nothing in your list that can't be modeled IMHO even more simply just by assuming you have resources chatting with each other over HTTP. But that may be because resource modeling in terms of HTTP has become second nature by now... It's a hard thing to grok, but seriously: whenever in the past I've thought HTTP provided a more complex or unnatural or grotty model for something, I've been wrong. Having helped propagate at least one non-HTTP app protocol (whodp) and lived to regret it, I'm seriously leery of any new protocols. HTTP is incredibly general, and it doesn't have the constraints and implications that most programmers intuitively think it has. > IF GET > EDIT > ELSE > ADD > END > > In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb. > You are attempting to perform a compoung command using a single command. > This seems to me to be a particularly non-RESTian verb. I don't think I understand what you've said, but I'm pretty sure we don't agree on the meaning of HTTP's PUT. > Okay, given that GTP PUT can be used like HTTP POST and that GTP is not like > HTTP, would you still say that GTP is still weaker? I can't get past the second: I'm still certain that GTP is essentially equivalent to HTTP, the differences merely rooted in misunderstanding of HTTP. > GTP allows the > "representation" of a resource to be sent instead of the resource itself. That's the basis of HTTP --- resources are NEVER, EVER sent. Only representations. > Yes, ONX is similar to XML. However, the devil is in the details. ONX is > specifically designed to accomodate data in ways that XML is unsuited for. You know, everytime I run into this argument, nobody can ever come up with datatypes that XML is *actually* unsuitable for. (Graph structures are incredibly general...) > It is also designed to be more efficiently parsable. Some research by some guys at IBM Almaden a year or so ago proved that the efficiency issue -wrt- parsing XML is wildly overstated. For the average bit of XML, it's statistical noise in the overall performance picture. > And yet, if HTTP and XML were truly the "dynamic duo" that everyone wants to > believe they are, this list (and several others) wouldn't exist. Methinks you misunderstand the purpose of this list... It exists, in large part, specifically to help propagate better understanding of HTTP's generality and utility. Resistance is futile. :-) Reinventing the wheel is one thing; reinventing *wood* something else entirely. ;-) Jb
BTW, I've been thinking more about this, and there definitely some similarities between REST's generic interface and the generic interface of other systems, but there are some important differences too, especially with SQL/CRUD and other data manipulation languages. The most important one, IMO is about "POST", and that while it can be used for insertion/creation, it's really a very generic method for "accept this data", which can be used to implement everything (except GET - PUT and DELETE can be negotiated). This is pretty different than SQL INSERT or CRUD "CREATE", since both are explicit operations where the invoker has explicit a priori knowledge of the state of the resource after a successful invocation. With POST, that knowledge has to be negotiated. Just something to keep in mind. MB
----- Original Message ----- From: "Jeff Bone" <jbone@...> > Could we all get over this whole idea of locking as necessary or desirable > for versioning, avoiding conflict in object evolution, etc.? It's a > side-effect of a bad storage metaphor, namely that stored entities are > mutable. Stored entities need not be mutable: imagine a filesystem in > which stored files are immutable, identified by OIDs (maybe hashes), and Somebody I respect a lot once said "Dynamism is an illusion". This was in reference to versioning in Groves. Kind of similar I suppose...
How about "XHTML is to XML as C++ is to programming" Or "XHTML is to XML as InternetExplorer is to C++" ----- Original Message ----- From: "Mark Baker" <distobj@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, July 08, 2002 1:49 PM Subject: [rest-discuss] XML/XHTML analogy > I was trying to draw a protocol analogy to XML/XHTML. The best I could > come up with was; > > XML is to XHTML as HTTP is to Yahoo. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
At 06:20 AM 9/07/2002, Jeff Bone wrote: ><RANT> > >Not exasperated with you particularly, Bill, but let me rant for a sec: Thanks for responding to the need for that rant, very interesting stuff ! >On 7/8/02 2:56 PM, "Bill de h�ra" <dehora@...> wrote: > > > As an aside: a lot of process synchronization problems can be handled by > > applying best practices for CVS, rather than global locking schemes (as > > per SourceSafe), which maybe wouldn't be planetary scalable anyway. > >If we factor the notions of naming and storage and assume immutability, then >the problem isn't just solved, it *disappears.* Really. This is one of >those problems we can just define away by appropriate abstraction. Since the OP specifically mentioned process synchronization, how does the immutable approach make that disappear? More specifically how does it handle the stale data/lost update problem? I can see that there is no such thing as a lost update in the traditional sense, but how does it cope with that scenario and still make sure that the 'current ' file contents are accurate? Further, were you implying that immutability makes the problem of people/processes working out of queue go away, e.g. in the workflow sense that there is a shared queue of work needing to be done, with multiple processes being fed from the queue, how does immutability help with this sort of process synch'ing? Robert
> > Part of this, I think I have already answered up top. As for the HTTP PUT > verb being an "ADD if not exist, otherwise EDIT", I have always had issues > with this. PUT is the logical equivalent of: > > IF GET > EDIT > ELSE > ADD > END > > In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb. > You are attempting to perform a compoung command using a single command. > This seems to me to be a particularly non-RESTian verb. It's very RESTian in that the conditional is implemented on the server, which allows the client to PUT data to a location known by the client in advance - bypassing gnarly issues of ownership of IDs. The server becomes stupid and the client becomes smart. Not all Web applications /have/ to be built this way, but it is a very powerful way to build applications.
----- Original Message ----- From: "Robert O'Brien" <robrien@...> > > I find the idea of a Resource having many Representations bears many > similarities to the idea of a Logical Entity (as in logical vs. physical > models) in Relational Theory. In SQL, views provide representations of > logical entities that may span many physical tables. Obviously the mechanism > for identifying and resolving an entity is different to identifying and > resolving a resource but the principles seem similar. Can a *View* in SQL be > considered a rough equivalent to a *Representation* of a resource in REST? I really don't think so. A RDBMS view mainly changes schema with regard to naming and I think it's a namespace operation - it changes the names by which you address/navigate the data. If you access the data with something like these: SELECT * from view_2 where key = $id SELECT * from view_3 where key = $id then I think /that/ would be REST 'representation' - the resource ID hasn't changed, only the content returned. > > Unfortunately SQL Databases don't allow updates through views that span > multiple tables. I bet there are companies that do that... but not many. I think Dr. Stonebraker's last company did something like that.
From: "Paul Prescod" <paul@...> > Seairth Jacobs wrote: > > > > Maybe this has to do with the fact that every time I see REST, it is joined > > at the hip with HTTP. > > This bothers many people but it is important to understand that one of > the central virtues of REST is *standardization* of interfaces. It isn't > the case that any protocol with generic interfaces is equal to any other > one. The one that is deployed is (all else equal) MUCH BETTER because of > the interoperability you get out of using it. Sure, I understand that. And if HTTP is truly RESTful, then I think it is a good thing to make such a statement. However, what I was saying was that it seems like REST and HTTP are > > > ... I know that REST is a methodology and HTTP is an > > implementation. I also know that a lot of people say that HTTP is an > > example of REST. But that's where the relationship stops for me. HTTP (in > > it's original incarnation, as I understand it) had a very simple purpose: > > provide a simple technique to allow researchers to share their works with > > other researchers. > > But what does it matter what HTTP was intended to do 12 years ago. HTTP > has evolved quite a bit if you look at the specifications. There is > nothing in those specifications that is specific to some particular > problem domain. I agree that HTTP has taken on a lot more over the years. However, it seems to me that HTTP 1.1 contains a lot of features that are not necessarily RESTful (e.g. persistant connections). In other words, I think that there is a subset of HTTP 1.1 that is definitely RESTful. However, HTTP 1.1 altogether does not seem quite as RESTful. To claim that "HTTP is an example of REST" implies (esp. to those who do not understand REST but do understand HTTP) that HTTP and REST are a one-to-one relationship, which I do not believe to be the case. Earlier versions of HTTP were more RESTful. The very fact that Fielding used HTTP as an example of REST shows that at one point in the past REST and HTTP *were* one-to-one related. Another way to look at this HTTP/REST thing is: if HTTP is the only implementation of REST that the REST-minded community will discuss, then why do we even have REST in the first place? REST is only useful as a concept that could be generally applied. Otherwise, it may as well be called "HTTP Guidelines". --- Seairth Jacobs seairth@...
From: "Jeff Bone" <jbone@...> > > The distinction between client-server and peer-to-peer has everything to do > with overall system architecture - with the roles the various components > play in the context of a single interaction - and, really, very little to do > with the underlying protocol. Having built, I think, the first > Internet-scale commercial p2p app (Ding!), I think I can safely make some > assertions, here. ;-) > > I've generally found C-S to be an inadequate distinction --- really, you > want to think about whether components initiate or service a request in a > given interaction; a component that plays the role of a server in one > interaction might be a client in the next; indeed, proxy components play > both roles in the context of a single conceptual interaction (server to the > initiating client, client to the origin server.) > > Another distinction is whether responses are synchronous or asynchronous (or > both) with requests --- this issue is orthogonal but related to C-S v. p2p. > As discussed ad nauseam early in this list's lifecycle, either is sufficient > to model the other. > > The short version is that you don't need new protocols beyond HTTP to do > things like "p2p" or async --- assuming that the semantics of the supported > methods are equivalent. The protocol should describe the interactions > between components at a semantic level. > > Again, given the similarity between the semantics, I see no need for a new > application protocol. > > > It may be possible to force implementation all of the above on top of HTTP, > > but that feels to me like the proverbial "square peg in a round hole". > > :-/ > > I see nothing in your list that can't be modeled IMHO even more simply just > by assuming you have resources chatting with each other over HTTP. But that > may be because resource modeling in terms of HTTP has become second nature > by now... It's a hard thing to grok, but seriously: whenever in the past > I've thought HTTP provided a more complex or unnatural or grotty model for > something, I've been wrong. Having helped propagate at least one non-HTTP > app protocol (whodp) and lived to regret it, I'm seriously leery of any new > protocols. > > HTTP is incredibly general, and it doesn't have the constraints and > implications that most programmers intuitively think it has. Okay, it sounds like you have worked with HTTP in ways that I have not. If this is the case, then you would obviously know how flexible HTTP is when it's actually applied to a situation. Maybe I need to sit down and look at and work with HTTP in some of those same ways to see for myself... > > Yes, ONX is similar to XML. However, the devil is in the details. ONX is > > specifically designed to accomodate data in ways that XML is unsuited for. > > You know, everytime I run into this argument, nobody can ever come up with > datatypes that XML is *actually* unsuitable for. (Graph structures are > incredibly general...) > > > It is also designed to be more efficiently parsable. > > Some research by some guys at IBM Almaden a year or so ago proved that the > efficiency issue -wrt- parsing XML is wildly overstated. For the average > bit of XML, it's statistical noise in the overall performance picture. Hmm... interesting. Well, that is certainly something to think about (re XML vs. ONX). However, as I pointed out, GTP can just as easily sit on top of XML, so it's not an issue as far as GTP discussions go. > Methinks you misunderstand the purpose of this list... It exists, in large > part, specifically to help propagate better understanding of HTTP's > generality and utility. Resistance is futile. :-) Reinventing the wheel is > one thing; reinventing *wood* something else entirely. ;-) Yes, this is definitely true. The list description is "Introductory-level discussion about REpresentational State Transfer, the name given to the architecture of the World Wide Web by Roy Fielding". Hmm... Thanks for the feedback. I am not convinced that GTP isn't a better solution, but I do realize I need to take a better look at the workings of HTTP. :) --- Seairth Jacobs seairth@...
> S. Mike Dierken wrote: > A RDBMS view mainly changes schema with regard to naming and I > think it's a namespace operation - it changes the names by which > you ddress/navigate the data. Agreed. I find the idea of logical vs. physical model separation as one way to think of a resource and it's many 'representations'. For example when a resouce needs to represent itself, in XML, using different schema. > If you access the data with something like these: > SELECT * from view_2 where key = $id > SELECT * from view_3 where key = $id > > then I think /that/ would be REST 'representation' - the resource > ID hasn't changed, only the content returned. Agreed; I was assuming the use of a surrogate key for entity identity - a common way of mapping objects to SQL DBMS - rather than the namespace operations refered to above. Robert.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > Another way to look at this HTTP/REST thing is: if HTTP is the only > implementation of REST that the REST-minded community will discuss, then why > do we even have REST in the first place? REST is only useful as a concept > that could be generally applied. Otherwise, it may as well be called "HTTP > Guidelines". This is a very good point. This discussion could (and probably should) be boiled down into "HTTP Guidelines" - but the REST principles stand apart from HTTP. Personally, I have used the principles where I needed to build large-scale, long-lived technology in support of products/applications - even when I could not directly use HTTP for one reason or another. For example, I once built a system using RDBMS and JMS to create a large scale subscription and notification system - the characterstics it borrowed from REST were global identifiers, generic interface and representations. The toughest part in terms of education was when the limited operations in the interface caused the identifiers to grow (via 'sub-properties') - that was too much for many people to understand & they just wanted to put everything into one slot (putting operation names into identifiers, etc).
Sorry, missed the 'protocol' part... How about "XML is to XHTML as TCP/IP is to HTTP" or "XML is to markup as HTTP is to distributed computing" or "XML is to XHTML as HTTP is to AS2" (AS2 is a HTTP+MIME based biz doc exchange protocol) or "XML is to XHTML as HTTP is to Hotmail" hmm... I think your analogy is the best... mine just don't make sense. ----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com>; "Mark Baker" <distobj@...> Sent: Monday, July 08, 2002 5:58 PM Subject: Re: [rest-discuss] XML/XHTML analogy > How about "XHTML is to XML as C++ is to programming" > Or "XHTML is to XML as InternetExplorer is to C++" > > > ----- Original Message ----- > From: "Mark Baker" <distobj@...> > To: <rest-discuss@yahoogroups.com> > Sent: Monday, July 08, 2002 1:49 PM > Subject: [rest-discuss] XML/XHTML analogy > > > > I was trying to draw a protocol analogy to XML/XHTML. The best I could > > come up with was; > > > > XML is to XHTML as HTTP is to Yahoo. > > > > MB > > -- > > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > > Ottawa, Ontario, CANADA. distobj@... > > http://www.markbaker.ca http://www.idokorro.com > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Following the "REST as SQL CRUD" theme, would it be fair then to say that SQL's EXEC is similar to POST? As with using POST for insertion/creation, implementing a CRUD "CREATE" using a SQL stored proc may result in the state of the resource not being a priori knowable after successful invocation. --Peter http://www.razorsoft.net/weblog -----Original Message----- From: Mark Baker [mailto:mbaker@...] Sent: Monday, July 08, 2002 5:42 PM To: Mark Baker; S. Mike Dierken; Bruce.Durling@...; rest-discuss@yahoogroups.com Subject: RE: [rest-discuss] Is REST CRUD? BTW, I've been thinking more about this, and there definitely some similarities between REST's generic interface and the generic interface of other systems, but there are some important differences too, especially with SQL/CRUD and other data manipulation languages. The most important one, IMO is about "POST", and that while it can be used for insertion/creation, it's really a very generic method for "accept this data", which can be used to implement everything (except GET - PUT and DELETE can be negotiated). This is pretty different than SQL INSERT or CRUD "CREATE", since both are explicit operations where the invoker has explicit a priori knowledge of the state of the resource after a successful invocation. With POST, that knowledge has to be negotiated. Just something to keep in mind. MB
On Mon, Jul 08, 2002 at 10:15:20PM -0700, S. Mike Dierken wrote: > Sorry, missed the 'protocol' part... > How about "XML is to XHTML as TCP/IP is to HTTP" That's the one we started with, which I believe is incorrect because the latter relationship is one of "layering & use", whereas the former is just of "use". > or "XML is to markup as HTTP is to distributed computing" That's ok. > or "XML is to XHTML as HTTP is to AS2" (AS2 is a HTTP+MIME based biz doc > exchange protocol) > or "XML is to XHTML as HTTP is to Hotmail" s/Hotmail/Yahoo - that's cheating! > hmm... I think your analogy is the best... mine just don't make sense. I think there's something to be written about this, to explain layering vs. use vs. extension of protocols, data formats, etc.. Might be worth a Wiki page when I get around to it. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
From: "S. Mike Dierken" <mdierken@...> > > Another way to look at this HTTP/REST thing is: if HTTP is the only > > implementation of REST that the REST-minded community will discuss, then > why > > do we even have REST in the first place? REST is only useful as a concept > > that could be generally applied. Otherwise, it may as well be called > "HTTP > > Guidelines". > > This is a very good point. This discussion could (and probably should) be > boiled down into "HTTP Guidelines" - but the REST principles stand apart > from HTTP. Yes, the REST principles do stand apart. My mistake was in believing that this list focused on REST itself, not "REST as it applies to HTTP". > Personally, I have used the principles where I needed to build large-scale, > long-lived technology in support of products/applications - even when I > could not directly use HTTP for one reason or another. Yet according to some, there isn't anything that HTTP can't do. ;) And maybe Jeff Bone is right. Maybe it is the uberprotocol (at least as far as REST is concerned). I am going to have to do some more searhing, playing, etc. to see how this is possible. And in the end, I would be happy to discover his truth. In the meantime, is there a list out there that is about REST itself? Sure, I expect HTTP to come up in conversation now and then, but I want something that is primarily about REST and not HTTP (which I am beginning to believe this list is actually about). I know I have some more te learn before I fully understand REST. I am finding that using HTTP to teach REST is just too confusing. HTTP brings too much baggage with it (even if the baggage is nothing more than the "tradtional web mindset"). --- Seairth Jacobs seairth@...
*sigh* You know, with the entire conversation of "GTP vs. HTTP" and "ONX vs. XML", I totally forgot about my original question: Is GTP RESTful? I am not necessarily looking to supplant HTTP or XML. If someone finds any of it useful, I would be ecstatic. However, GTP is just as much an academic effort as anything else (at this point, anyhow). I am trying to grasp what REST means without specifically looking to HTTP for examples. So, back to the original question (and it's corrolaries): Is GTP RESTful? If not, what is lacking? What REST principals does GTP not address? What parts of GTP do not fit into the REST principles? --- Seairth Jacobs seairth@... p.s. And if this is the wrong list to be asking these questions to, can someone suggest another list where this would be more appropriate?
Seairth Jacobs wrote: > >... > > In the meantime, is there a list out there that is about REST itself? Let's put it this way: try and find a list that discusses relational databases without a focus on SQL. Obviously there is some subset of the relational world for whom it is practical and feasible to separate SQL from relational. But the much larger subset spends their day working in SQL and need to solve problems in SQL. There are few proposed alternatives to SQL and their deployment costs would be massive. So you will not find many programmers outside of the academy who strongly separate theory and practice. The same is true of REST. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
From: "Paul Prescod" <paul@...> > > Let's put it this way: try and find a list that discusses relational > databases without a focus on SQL. Obviously there is some subset of the > relational world for whom it is practical and feasible to separate SQL > from relational. But the much larger subset spends their day working in > SQL and need to solve problems in SQL. There are few proposed > alternatives to SQL and their deployment costs would be massive. So you > will not find many programmers outside of the academy who strongly > separate theory and practice. The same is true of REST. True enough. However, if I were looking to solve an SQL problem, I would look for an SQL list. If this list is for solving HTTP problems (as they apply to REST), then it would make more sense to call this list something like "http-rest-discuss". I had thought that this was a more generalized list. I was wrong. I can accept that and move on. :) Truthfully, I don't have any problem discussing HTTP as it relates to REST. I just have trouble learning REST by discussing REST as it relates to HTTP. I admit that this may be my own problem and no one else's. I'm just trying to figure out a way around that problem... --- Seairth Jacobs seairth@...
Seairth Jacobs wrote: > >... > > Truthfully, I don't have any problem discussing HTTP as it relates to REST. > I just have trouble learning REST by discussing REST as it relates to HTTP. > I admit that this may be my own problem and no one else's. I'm just trying > to figure out a way around that problem... Roy's thesis makes the distinction between REST and HTTP. If you want to compare REST to GTP I'd start there, especially with this bit: "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." I don't think it is easy to answer whether GTP is RESTful. To do so, I would have to really understand it, almost as well as you do, and then try to apply it mentally to a bunch of REST-architected systems and see whether it handles them properly. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On 7/8/02 9:04 PM, "Seairth Jacobs" <seairth@...> wrote: > Thanks for the feedback. I am not convinced that GTP isn't a better > solution, but I do realize I need to take a better look at the workings of > HTTP. :) No prob, and I hope you don't feel too beat up --- I just hate seeing people make the same mistakes that I've made in the past, and inventing new app protocols when HTTP would've sufficed is definitely one of those. :-) Jb
On 7/8/02 7:58 PM, "Robert Leftwich" <robert@...> wrote:
>
> Since the OP specifically mentioned process synchronization, how does the
> immutable approach make that disappear? More specifically how does it handle
> the stale data/lost update problem? I can see that there is no such thing
> as a lost update in the traditional sense, but how does it cope with that
> scenario and still make sure that the 'current ' file contents are accurate?
That's a good question... IME, the "lost update" problem is neither as
common / problematic as most people seem to think, nor as difficult to
resolve. It does, however, usually require really application-specific
solutions.
In the case where the stored objects --- including perhaps the canonical
name -> object mappings --- are immutable, there are a number of ways to
resolve it. Techniques for doing so are indeed simpler by virtue of the
immutability of the stored objects. Consider the following sequence:
A looks up name foo, gets ref to object 1
A computes 1' from 1
B looks up name foo, gets ref to object 1
B computes 1'' from 1
B writes 1''
B writes new mapping of foo -> 1''
A writes new mapping of foo -> 1'
The canonical mapping of foo now points at 1', and the mapping foo -> 1'' is
"lost." However, it's not really lost: during this time, the mappings from
name to object have been:
t1: foo -> 1
t2: foo -> 1''
t3: foo -> 1'
The version tree for the object has been (read down and left-to-right)
Foo @ t1 --> 1
/ \
Foo @ t2 --> 1'' \
\
Foo @ t3 --> 1'
The "canonical" version of the object can heuristically be considered to be
the one pointed to by the latest mapping of name -> object. If this isn't
sufficient, if it's truly necessary for correct application semantics to
ensure that this mapping is never updated if it has been updated subsequent
to the initial read, then it suffices to just check the canonical (most
current) mapping to ensure it's the same before doing the update. I.e.:
A looks up name foo, gets ref to object 1
A computes 1' from 1
B looks up name foo, gets ref to object 1
B computes 1'' from 1
B writes 1''
CONDITIONAL ON foo -> 1, B writes new mapping of foo -> 1''
CONDITIONAL ON foo -> 1, A writes new mapping of foo -> 1'
In the failure case, A must then take some application-specific action to
resolve things. This could be notifying a user, rereading and doing some
kind of merge, etc.
Note that transactions --- the ability to perform or not perform a sequence
of such actions as an atomic unit --- does indeed aid in implementation of
correct algorithms even in the presence of immutable stored objects. But
that's really orthogonal to locking - transactions in the abstract neither
imply nor require locking.
>
> Further, were you implying that immutability makes the problem of
> people/processes working out of queue go away, e.g. in the workflow sense
> that there is a shared queue of work needing to be done, with multiple
> processes being fed from the queue, how does immutability help with this
> sort of process synch'ing?
I'm not sure it does... Explain further?
Jb
From: "Paul Prescod" <paul@...> > > Roy's thesis makes the distinction between REST and HTTP. If you want to > compare REST to GTP I'd start there, especially with this bit: > > "REST is defined by four interface constraints: identification of > resources; manipulation of resources through representations; > self-descriptive messages; and, hypermedia as the engine of application > state." > > I don't think it is easy to answer whether GTP is RESTful. To do so, I > would have to really understand it, almost as well as you do, and then > try to apply it mentally to a bunch of REST-architected systems and see > whether it handles them properly. Now, this is something I can understand. Thanks. So, the basic constraints are: 1) Identification of resources: I am not sure about this one. In part, I having trouble what it means to "identify a resource" in a RESTful fashion. The most common technique, as I understand it, is the URI. However, I am not sure that I understand what exactly makes the URI the right identification method for the job (unless this is just because of it's relationship to HTTP, etc.). I suppose the other problem here is that this part of GTP is somewhat left to be handled be the application that is implemented on top of it. In other words, it is up to the application that uses GTP to determine the actual identification process, format, etc. The main reason I did this is because I could not see what advantage there would be to forcing all GTP-enabled applications to use URIs (as opposed to some other identification format). 2) Manipulation of resources through representations: Now, I have always had a question about this one. How exactly can one manipulate resources over a network any other way? In other words, it seems to me that any time I communicate with a computer that returns a resource to me, I can only ever get a "representation" of that resource (even if the representation contains all known aspects of that resource). When I download my e-mail, I am retrieving a representation of what is on the POP server. When I send an e-mail, the SMTP server is only getting a representation of that e-mail. When I download a file from FTP, I am getting a representation of what is on the FTP server. If I were to then edit the downloaded representation and upload it back again, I am sending back a request to update the remote resource through my version of the representation. Does any of what I am saying make sense, or am I just not grasping what is really meant by this constraint? 3) Self-descriptive messages: GTP has got this one. Since it is base on ONX (or XML), this is a given. 4) Hypermedia as the engine of applications state: Okay, I think I understand this one. All that this is saying is that any given representation of a resource contains some sort of link to other representations of the same or other resource(s). In HTML, it is the URL in anchors, etc. These links are the only allowable methods by which a state can be transferred from one representation to another representation (or from one state to another state). Now, how this applies to GTP is a good question. In part, I think this is somewhat like the same argument I have for #1 above. I think that, as GTP stands now, it does not impose the method by which "hypermedia" is achieved. Maybe in order for GTP to be more REST-like, I need to impose the resource identification and hypermedia rules up front. For instance, maybe the URI should be the only allowable format. This would certainly make this aspect of GTP universal across implementations, but would it also impose restrictions on what can and cannot realistically be done with GTP? --- Seairth Jacobs seairth@...
On 7/9/02 11:50 AM, "Seairth Jacobs" <seairth@...> wrote: > > 1) Identification of resources: I am not sure about this one. In part, I > having trouble what it means to "identify a resource" in a RESTful fashion. > The most common technique, as I understand it, is the URI. However, I am > not sure that I understand what exactly makes the URI the right > identification method for the job (unless this is just because of it's > relationship to HTTP, etc.). Things to think about: a URI doesn't have to be an HTTP URI --- you could easily have GTP URIs. Second, a URI isn't anything more than a name for something --- think handle, name, OID, hash, whatever. The only semantics a URI "officially" has is dereference - Axiom of [URI] Opacity. (In fact, that's questionable --- but that's a good first approximation.) The nice thing about HTTP and many other URI schemes is that the naming is decentralized and uncoordinated --- as long as there's a DNS name or IP address to qualify the namespace, it's possible to add names with no coordination between administrative concerns whatsoever. This is an important point and, IMO, one of the keys to the success of the Web. > 2) Manipulation of resources through representations: Now, I have always had > a question about this one. How exactly can one manipulate resources over a > network any other way? In other words, it seems to me that any time I > communicate with a computer that returns a resource to me, I can only ever > get a "representation" of that resource (even if the representation contains > all known aspects of that resource). When I download my e-mail, I am > retrieving a representation of what is on the POP server. When I send an > e-mail, the SMTP server is only getting a representation of that e-mail. > When I download a file from FTP, I am getting a representation of what is on > the FTP server. If I were to then edit the downloaded representation and > upload it back again, I am sending back a request to update the remote > resource through my version of the representation. Does any of what I am > saying make sense, or am I just not grasping what is really meant by this > constraint? Nope, you've basically got it. In the literal sense, this constraint is a tautology. You can only manipulate things via representations. I suspect that the purpose of the constraint is to point out and underscore the distinction between the logical entity denoted by the URI --- the resource --- and the representation. Most people get confused the other way around, and assume that resources are transferred --- this is still a source of confusion for many very bright people, cf. recent discussion in TAG and elsewhere. > 4) Hypermedia as the engine of applications state: Okay, I think I > understand this one. All that this is saying is that any given > representation of a resource contains some sort of link to other > representations of the same or other resource(s). In HTML, it is the URL in > anchors, etc. These links are the only allowable methods by which a state > can be transferred from one representation to another representation (or > from one state to another state). Now, how this applies to GTP is a good > question. In part, I think this is somewhat like the same argument I have > for #1 above. I think that, as GTP stands now, it does not impose the > method by which "hypermedia" is achieved. This one, IMO, is the most propaganda-like of the constraints: politically charged and technically not that useful / meaningful. It simply begs for the definitions of hypermedia, application, application state, and engine. Nor, IMO, does a literal interpretation of REST - REpresentational State Transfer - really require hypermedia. (IMO, all the rest of REST is useful in thinking about i.e. globally distributed filesystems containing objects that do not in fact refer to one another via hyperlinks... But with the addition of this constraint, REST ties itself undesirably and inextricably to the existing Web and other Web-like hypermedia systems. IMHO, short-sightedness on Roy's part.) But that's a controversial dead horse that we've already beat up. Having said that, the Web is a GOOD THING and distributed systems in general gain tremendously by accommodating the Web's hypermedia data model, REST architecture, and other technical qualities. jb
I didn't know SQL had "EXEC". SQL92 doesn't appear to. If it's a method for passing data to some thing for processing, then I guess it probably is the same, though the name "EXEC" doesn't suggest that it's the same. And not knowing the state after a stored procedure executes is necessary but insufficient to be the same as POST. MB -----Original Message----- From: Peter Drayton Sent: Tue 7/9/2002 2:45 AM To: Mark Baker; 'S. Mike Dierken'; Bruce.Durling@equifax.com; rest-discuss@yahoogroups.com Cc: Subject: RE: [rest-discuss] Is REST CRUD? Following the "REST as SQL CRUD" theme, would it be fair then to say that SQL's EXEC is similar to POST? As with using POST for insertion/creation, implementing a CRUD "CREATE" using a SQL stored proc may result in the state of the resource not being a priori knowable after successful invocation. --Peter http://www.razorsoft.net/weblog -----Original Message----- From: Mark Baker [ mailto:mbaker@idokorro.com] Sent: Monday, July 08, 2002 5:42 PM To: Mark Baker; S. Mike Dierken; Bruce.Durling@equifax.com; rest-discuss@yahoogroups.com Subject: RE: [rest-discuss] Is REST CRUD? BTW, I've been thinking more about this, and there definitely some similarities between REST's generic interface and the generic interface of other systems, but there are some important differences too, especially with SQL/CRUD and other data manipulation languages. The most important one, IMO is about "POST", and that while it can be used for insertion/creation, it's really a very generic method for "accept this data", which can be used to implement everything (except GET - PUT and DELETE can be negotiated). This is pretty different than SQL INSERT or CRUD "CREATE", since both are explicit operations where the invoker has explicit a priori knowledge of the state of the resource after a successful invocation. With POST, that knowledge has to be negotiated. Just something to keep in mind. MB
>>Could we all get over this whole idea of locking as necessary or desirable >>for versioning, avoiding conflict in object evolution, etc.? It's a >>side-effect of a bad storage metaphor, namely that stored entities are >>mutable. Stored entities need not be mutable: imagine a filesystem in >>which stored files are immutable, identified by OIDs (maybe hashes), and > > > Somebody I respect a lot once said "Dynamism is an illusion". This was in > reference to versioning in Groves. Kind of similar I suppose... We've wrestled with this problem for a long time. The tuplespace (in this case, javaspaces) is very core to our system. As our application evolves over time, we've found that our data evolves over time. We've had to keep good track of our Java classes so that we don't create incompatible serialization issues. Granted, this is very Java specific. What I'd love for our application to do is use XML + RDF as our information serialization. We can then become a lot more flexible with interpreting and parsing the documents (especially when using RDF). But data definitions are mutable in the real world, and in some cases (java serialization) can cause big headaches. Seth
In Sybase/Microsoft Transact-SQL EXEC is the short form of EXECUTE, which executes a stored procedure. However, (and I didn't actually know that this distinction existed until today) in SQL-92 [1] EXEC is *not* the short form of EXECUTE: EXECUTE (section 17.10) invokes stored procedures, while EXEC (section 19) is used for embedded SQL. In SQL-92 parlance I was referring to EXECUTE. My observation/question was that EXEC[UTE] is a "method for passing data to some thing for processing", which feels similar on some levels to POST. I really like the REST<->CRUD analogy, BTW. --Peter [1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt -----Original Message----- From: Mark Baker [mailto:mbaker@...] Sent: Tuesday, July 09, 2002 10:12 AM To: Peter Drayton; S. Mike Dierken; Bruce.Durling@...; rest-discuss@yahoogroups.com Subject: RE: [rest-discuss] Is REST CRUD? I didn't know SQL had "EXEC". SQL92 doesn't appear to. If it's a method for passing data to some thing for processing, then I guess it probably is the same, though the name "EXEC" doesn't suggest that it's the same. And not knowing the state after a stored procedure executes is necessary but insufficient to be the same as POST. MB -----Original Message----- From: Peter Drayton Sent: Tue 7/9/2002 2:45 AM To: Mark Baker; 'S. Mike Dierken'; Bruce.Durling@...; rest-discuss@yahoogroups.com Cc: Subject: RE: [rest-discuss] Is REST CRUD? Following the "REST as SQL CRUD" theme, would it be fair then to say that SQL's EXEC is similar to POST? As with using POST for insertion/creation, implementing a CRUD "CREATE" using a SQL stored proc may result in the state of the resource not being a priori knowable after successful invocation.
Ah, thanks for the ref. I wasn't being a smart ass, I couldn't even find "execute" in the sql92 reference I had. 8-) So after looking at it, I'd say that it's not post, because you have to provide the "statement name"; if you know a statement name, then you have an expectation of what the result will be if you execute it. If you don't know a statement name, then you can't use the method. So it appears to mean "invoke this method" (which the name indicates), and that's different than POST. MB
On 7/9/02 1:22 PM, "Seth Ladd" <seth@...> wrote: > > We've wrestled with this problem for a long time. The tuplespace (in > this case, javaspaces) is very core to our system. As our application > evolves over time, we've found that our data evolves over time. We've > had to keep good track of our Java classes so that we don't create > incompatible serialization issues. Granted, this is very Java specific. Not really that Java specific --- I've run into this issue every time I've had to wrestle with object persistence in the face of schema evolution. The old object-relational tools (i.e., Persistence - anybody remember that?) had this problem in spades, Python's pickle has this problem to a certain lesser extent, etc. It's really troublesome in statically-typed languages with what I think of as "rigid" object models, i.e. C++. Languages where objects are really just slot containers / dictionaries / etc. --- e.g. Python --- this is often less troublesome. > > What I'd love for our application to do is use XML + RDF as our > information serialization. We can then become a lot more flexible with > interpreting and parsing the documents (especially when using RDF). Wrt XML tuplespaces, sounds like a job for Ruple. :-) Wrt schema drift and RDF, one of the most significant problems with RDF is that facts can reference facts outside of a local factset / administrative domain, which can evolve in an uncoordinated and therefore destructive fashion. Until the various parties involve *deeply* address these and related problems, there will be no Semantic Web other than very local factsets. :-/ The good news is that, assuming immutability of (certain) resources i.e., true idempotency of GET over time, the problem is rather trivial... BTW, I'm a big fan of predicate calculus as a data model, but I'm not sure what RDF buys you over arbitrary n-ary tuples when you're talking about generative communication... Perhaps you could talk about that a bit? > > But data definitions are mutable in the real world, and in some cases > (java serialization) can cause big headaches. Make sure instances of some schema embed a reference to an immutable copy of their schema. It also helps to have named, declarative descriptions of transformations between schema versions that can be referenced... In XML, for instance, this could perhaps be an XSLT that transforms XML schemas. Jb
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > Yet according to some, there isn't anything that HTTP can't do. ;) True - but I don't pay the bills...
On 7/9/02 1:29 PM, "Peter Drayton" <peter@...> wrote: > > My observation/question was that EXEC[UTE] is a "method for passing data > to some thing for processing", which feels similar on some levels to > POST. Here's my problem with this analogy. First, the relational calculus per se doesn't say anything about EXECUTE, and EXECUTE by itself has no impact on any data model. IMO, whether any SQL has EXEC, EXECUTE, etc., its not really accurate to think of it as a part of CRUD. Instead, it's really a way to tunnel SQL through SQL... But more troublesome: it's perhaps dangerous to think of POST in this way, i.e. to think about it as a way to provide arbitrary data to a resource for arbitrary purposes. It's a slippery slope from there to RPC. Before "getting" REST, I used to argue that we only really needed one protocol with one method: INVOKE, or POST, or EXEC, etc. All other methods, I argued, could and should be implemented by individual objects in terms of that single primitive method. AFAICT the "correct" interpretation of POST should really be: update the state of the resource in question given the following (potentially partial) representation of what the new resource state should be. This is a subtle distinction, but IMO an important one: POST isn't an arbitrary method dispatch interface, but rather a very specific method itself that consumes a representation of the intended resource state and acts accordingly. As with many of these issues, though, this is so subtle and slippery that in practice I find myself violating it all the time. ;-) In WebKit, for instance, in our administrative UI for the current product, we're using its mechanism for binding "actions" passed in via POST to methods in particular servlet method implementations. This is the wrong way to do it: we should really be modeling things differently, but it's often not clear what the right model should be... And the arguments in favor of doing it the right way often come across as rather academic. Trying to practice what I preach, Jb
At 02:29 AM 10/07/2002, Jeff Bone wrote: >On 7/8/02 7:58 PM, "Robert Leftwich" <robert@...> wrote: > > > > Further, were you implying that immutability makes the problem of > > people/processes working out of queue go away, e.g. in the workflow sense > > that there is a shared queue of work needing to be done, with multiple > > processes being fed from the queue, how does immutability help with this > > sort of process synch'ing? > >I'm not sure it does... Explain further? I was thinking along the lines of locking for exclusivity not for versioning (the queue thing was a bit of a red herring), i.e. semaphores/resource locks, Thinking on it further, the immutability probably has no influence at all. If you use a basic lock file approach, either the file is there or not and assuming that delete actually does delete the lock file and not simply remove the mapping link (so that you end up with a multitude of unlinked old lock file versions somewhere in your file system) then all is well. Robert >Jb > > > >To unsubscribe from this group, send an email to: >rest-discuss-unsubscribe@yahoogroups.com > > > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On 7/9/02 6:01 PM, "Robert Leftwich" <robert@...> wrote: > >> I'm not sure it does... Explain further? > > I was thinking along the lines of locking for exclusivity not for versioning > (the queue thing was a bit of a red herring), i.e. semaphores/resource > locks, Thinking on it further, the immutability probably has no influence at > all. If you use a basic lock file approach, either the file is there or not > and assuming that delete actually does delete the lock file and not simply > remove the mapping link (so that you end up with a multitude of unlinked old > lock file versions somewhere in your file system) then all is well. Correct. Immutability probably doesn't do away with the need for semaphores / etc. for the purpose of synchronization where it's truly needed --- but my point is that with immutability and complete version history, you can avoid many synchronization situations. The issue becomes not "canonically right at any given instant" but rather "determination of the canonically right state on demand." BTW, please note that a combination of immutable stored files, a heuristic that says "canonical version is the latest version", and a mechanism that lets you access historical versions via various criteria gives you something that has the overt last-writer-wins semantics of filesystems absent file locking *and* CVS-like versioning, w/o explicit check-in/check-out. Cheers, Jb
At 07:37 AM 10/07/2002, Jeff Bone wrote: >AFAICT the "correct" interpretation of POST should really be: update the >state of the resource in question given the following (potentially partial) >representation of what the new resource state should be. This is using the broadest possible sense of 'resource state' is it not? I understood POST to be specifically aimed at *new* subordinate resources (from RFC2616). With your classification PUT and POST are only marginally different, in that PUT ''SHOULD be considered as a modified version' of the resource, i.e. in its entirety, but POST can be a partial representation of the resource. >This is a subtle >distinction, but IMO an important one: POST isn't an arbitrary method >dispatch interface, but rather a very specific method itself that consumes a >representation of the intended resource state and acts accordingly. Isn't that classification exactly the same as PUT? >As with many of these issues, though, this is so subtle and slippery that in >practice I find myself violating it all the time. ;-) IMHO that is a huge problem for REST and it may be an insurmountable one - there is no canonical answer. This may be symptomatic of the fact that the limited verb count means that you invariably have to overload/overlay many meanings on top of them, so many in fact that their usefulness becomes diluted. >In WebKit, ... Webkit == Webware (http://webware.sourceforge.net/) ? >Trying to practice what I preach, Trying to find something to practice! Robert
On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote: > With your classification PUT and POST are only marginally > different, in that PUT ''SHOULD be considered as a modified version' of the > resource, i.e. in its entirety, but POST can be a partial representation of > the resource. Yes, that's my understanding. The imperfect analogy I've used before: PUT ~= echo "foo" > foo POST ~= echo "foo" >> foo With the proviso that foo -- the file, the thing that's getting redirected to -- can be equivalent to a device file, i.e. could well be /dev/foo. >> This is a subtle >> distinction, but IMO an important one: POST isn't an arbitrary method >> dispatch interface, but rather a very specific method itself that consumes a >> representation of the intended resource state and acts accordingly. > > Isn't that classification exactly the same as PUT? PUT is "replace." POST is "update," "append," etc. The distinction is equivalent to the distinction between > and >>. > > >> As with many of these issues, though, this is so subtle and slippery that in >> practice I find myself violating it all the time. ;-) > > IMHO that is a huge problem for REST and it may be an insurmountable one - > there is no canonical answer. This may be symptomatic of the fact that the > limited verb count means that you invariably have to overload/overlay many > meanings on top of them, so many in fact that their usefulness becomes > diluted. My guess is it's a combination of educational / cultural bias and impedance mismatch between toolkits and model... > >> In WebKit, ... > > Webkit == Webware (http://webware.sourceforge.net/) ? > Yup! >> Trying to practice what I preach, > > Trying to find something to practice! > Keep searching, it's there. :-) (Seriously, it took me a year of acrimonious head-butting with Mark and (esp) Roy to get it... Jb
I don't like your description of POST there Jeff. POSTed data need not have anything to do with being a representation of the resource to which it's being POSTed. Like POSTing a representation of a pair of shoes to a shopping cart. It's just "take this data", with the (critical) proviso that a successful response just means that the data was accepted, nothing more. i.e. you need not tunnel with it to use it. MB -----Original Message----- From: Jeff Bone <jbone@...> To: Robert Leftwich <robert@...> CC: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com> Sent: Tue Jul 09 23:25:24 2002 Subject: Re: [rest-discuss] Is REST CRUD? On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote: > With your classification PUT and POST are only marginally > different, in that PUT ''SHOULD be considered as a modified version' of the > resource, i.e. in its entirety, but POST can be a partial representation of > the resource. Yes, that's my understanding. The imperfect analogy I've used before: PUT ~= echo "foo" > foo POST ~= echo "foo" >> foo With the proviso that foo -- the file, the thing that's getting redirected to -- can be equivalent to a device file, i.e. could well be /dev/foo. >> This is a subtle >> distinction, but IMO an important one: POST isn't an arbitrary method >> dispatch interface, but rather a very specific method itself that consumes a >> representation of the intended resource state and acts accordingly. > > Isn't that classification exactly the same as PUT? PUT is "replace." POST is "update," "append," etc. The distinction is equivalent to the distinction between > and >>. > > >> As with many of these issues, though, this is so subtle and slippery that in >> practice I find myself violating it all the time. ;-) > > IMHO that is a huge problem for REST and it may be an insurmountable one - > there is no canonical answer. This may be symptomatic of the fact that the > limited verb count means that you invariably have to overload/overlay many > meanings on top of them, so many in fact that their usefulness becomes > diluted. My guess is it's a combination of educational / cultural bias and impedance mismatch between toolkits and model... > >> In WebKit, ... > > Webkit == Webware (http://webware.sourceforge.net/) ? > Yup! >> Trying to practice what I preach, > > Trying to find something to practice! > Keep searching, it's there. :-) (Seriously, it took me a year of acrimonious head-butting with Mark and (esp) Roy to get it... Jb To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Seairth Jacobs wrote: > >... > > Now, this is something I can understand. Thanks. > > So, the basic constraints are: > > 1) Identification of resources: I am not sure about this one. In part, I > having trouble what it means to "identify a resource" in a RESTful fashion. > The most common technique, as I understand it, is the URI. However, I am > not sure that I understand what exactly makes the URI the right > identification method for the job (unless this is just because of it's > relationship to HTTP, etc.). Whether you believe the "U" stands for "universal" or "uniform", the relevant property is a good thing. Uniform is good in that you have globally understood parsing rules. Universal is good because it implies that any component may talk to any resource. > I suppose the other problem here is that this part of GTP is somewhat left > to be handled be the application that is implemented on top of it. In other > words, it is up to the application that uses GTP to determine the actual > identification process, format, etc. The main reason I did this is because > I could not see what advantage there would be to forcing all GTP-enabled > applications to use URIs (as opposed to some other identification format). Well if one GTP application used CORBA object ids and another used URIs then the universe would be split into the world of components that know how to use one kind of address and the world of components that know how to use the other kind of address. The web has this problem to a certain extent, but market pressures suppress the proliferation of variant URI schemes. My personal opinion is that non-GETTABLE URI schemes should only be used for pre-existing legacy namespaces (like "mailto:" or "isbn:"). > 2) Manipulation of resources through representations: Now, I have always had > a question about this one. How exactly can one manipulate resources over a > network any other way? In other words, it seems to me that any time I > communicate with a computer that returns a resource to me, I can only ever > get a "representation" of that resource (even if the representation contains > all known aspects of that resource). Obviously you can't really touch objects over the network. But some networking technologies might claim that clients may behave as if they are. Arguably, if you PUT a file thorugh FTP and then do an immediate GET, with some a priori knowledge that nobody else could touch the file, you should get back the exact same bits. But HTTP doesn't define the "bits" of a resource. And according to my understanding, you could PUT one second and GET back something different the next second, even if nobody else fiddled with the data. > 3) Self-descriptive messages: GTP has got this one. Since it is base on ONX > (or XML), this is a given. Note the sub-parts of "self-description" from the thesis: "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." > 4) .... > > Maybe in order for GTP to be more REST-like, I need to impose the resource > identification and hypermedia rules up front. For instance, maybe the URI > should be the only allowable format. This would certainly make this aspect > of GTP universal across implementations, but would it also impose > restrictions on what can and cannot realistically be done with GTP? A URI is just a syntax. Agreeing to use it is not much more restrictive than agreeing to use ONX. If you are reinventing the universe without worrying about practicality, you might consider whether URIs should have better support for URIs that embed URIs without escaping. For instance this is not a valid URI: http://google.com?get_cached_page=http://www.bates.com IIRC, slashes are not allowed in query strings unless escaped. A new-fangled replacement for URIs might allow something like: http://google.com?get_cached_page=(http://www.bates.com) The thing in parens is implicitly escaped and could have its own sub-parts: http://google.com?get_cached_page=(http://www.bates.com?something_else=()) -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Jeff Bone wrote: > > ... > > As with many of these issues, though, this is so subtle and slippery that in > practice I find myself violating it all the time. ;-) In WebKit, for > instance, in our administrative UI for the current product, we're using its > mechanism for binding "actions" passed in via POST to methods in particular > servlet method implementations. This is the wrong way to do it: we should > really be modeling things differently, but it's often not clear what the > right model should be... And the arguments in favor of doing it the right > way often come across as rather academic. One of the problems with teaching REST today is that deployed tools only depend strongly upon the semantics for GET. PUT, DELETE are mostly ignored except in a WebDAV context. POST is "everything that doesn't make sense as GET". In part, that's why I think that WebDAV is a good partner for HTTP in REST systems. When someone asks: "what's the practical consequence of using POST for DELETE" we can answer: "you break compatibility with Windows Explorer and MS Office." Some people will not care but others will. In a perfect world, we would all use tools like "wget", "wput", "wdelete", "wpost" every day. But really, outside of WebDAV, we only use "wget". -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On Wed, 10 Jul 2002 07:46:09 -0700, Paul Prescod wrote: > One of the problems with teaching REST today is that deployed tools only > depend strongly upon the semantics for GET. > > PUT, DELETE are mostly ignored except in a WebDAV context. POST is > "everything that doesn't make sense as GET". In part, that's > why I think > that WebDAV is a good partner for HTTP in REST systems. When someone > asks: "what's the practical consequence of using POST for > DELETE" we can > answer: "you break compatibility with Windows Explorer and MS > Office." > Some people will not care but others will. > > In a perfect world, we would all use tools like "wget", > "wput", > "wdelete", "wpost" every day. But really, outside of > WebDAV, we only use > "wget". I know that the proper semantic use of GET, PUT, POST, and DELETE is central to REST, but unfortunately a lot of us have to work in the imperfect world of HTML where GET and POST are much better supported than the other two. For me, the beauty of REST is the promise that I can architect a single, uniform, XML-based back-end infrastructure that can then be displayed and manipulated by a virtually unlimited set of client interfaces. But if I have to build this interface to depend on PUT and DELETE, then I have to somehow translate GET and POST requests from "down-level" clients (i.e. HTML, VoiceXML, WAP, etc.) to their "proper" equivalents. XML and XSLT do a great job of solving the "one source, many formats" problem, but if I can't write my back-end processing to the lowest common denominator (i.e. GET and POST), I lose a lot of the ground I gained on the transformation side. Any thoughts? Am I missing something?
Dear Sir/Ma'am:
It is significantly beneficial to your library and its patrons to have a book titled
"Complete Conduct Principles for the 21st Century" by Dr. John Newton.
Please suggest to your local library(ies) that the book be purchased. This is a great contribution you can make to your neighborhood!
"I find it heartening that you are crusading on behalf of this worthy book. It has occupied a space on our shelves for some time now. To have this book in our library is a quiet source of pride to me, the librarian." said Mr. Don Brusha, a highly respectable Librarian of Avon Park Library in Avon Park, Florida, USA, in a letter to me regarding the book.
This book is a MUST for EVERYONE to be better prepared for personal conduct for the 21st century. EVERY LIBRARY SHOULD HAVE IT.
You may ask yourself
> How to make people respect you
> How to win friends
> How to let your conduct help your health, work, job, career, relationships, spirit, mind, well-being, ...
> How to make your life smoother and happier
> How to do whatever you like without being unpleasant to other people
> How to develop good conduct in your children or students
> How to make the world peaceful and better
You (and the library patrons) can find all the answers to these questions, and much more, in this great book.
BENEFITS to each individual reader: Many! -- such as for health, work, job, career, self-improvement, education, relationships, spirit, mind, well-being, and much more -- almost all the areas that are important to you in the 21st century. People around you will benefit, too. (Please see the preface of the book for details.)
EVERYONE may find this book useful and helpful, regardless of age (from children to oldsters), occupation, rank, status, gender, religious beliefs, nationality, country, or region.
If you are a parent or a teacher, you can learn how to develop good conduct in your children or students from this book. Please advise your children or students to read the book. It will result in great benefits for both you and them.
The book's content is obvious from its title. The complete useful conduct principles cover not only what we should do, but also what we should not do -- especially those faults people make often and easily.
"The book will also be effective for violence prevention for the whole society." said some experts.
This timely, unique, and very important book is designed to suit most people, and is self-contained and user-friendly.
This book is significantly different and better than competitive works.
Some of its innovative contents may help solve problems that Western culture cannot.
The book's merit and importance have been recognized and praised by many experts, elected public officials, and world leaders.
How to make the world peaceful and better ---
You (and the library patrons) can find the solution in the book.
Let's work together to make the world peaceful and better!
The author, John Newton, holds a Ph.D. from MIT, and does researches at Harvard. His long-term research on "The personal conduct in the human society of the 21st century" resulted in this book. It is published by Nicer Century World Organization, headquartered beside Harvard University and MIT, two leading institutes of new knowledge and literature.
It has the Library of Congress Cataloging-in-Publication data. Trade hardcover (case bound, Smyth sewn; with dust jacket) ISBN 0967370574; trade paperback (perfect bound) ISBN 0967370582. Bound durably and functionally to stand up to heavy library use. 60 lb natural acid-free excellent and healthful paper. 5.5inX8.5in. 192 pages. Including Principle Index and General Index. Self-contained.
Again, please suggest to your local library(ies) that the book be purchased.
Your effort to make a great contribution to your family and neighborhood and the whole society will be highly appreciated.
Sincerely yours,
Tom Carter, Ph.D.
President, Nicer Century World Organization
Massachusetts, USA
(Nicer Century World Organization is an educational, non-profit, non-partisan organization; it endeavors to make the 21st century nicer than ever before. To accomplish its mission, Nicer Century World Organization is proud to introduce this book.)
I agree with Mark on the interpretation of POST.
From the RFC [1]:
9.6 PUT
[...]
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
Still, how might subtle differences in interpretation of the non-GET methods
effect the adoption of the REST model? If web services are built that
don't follow these guidelines strictly enough, what sorts of
problems could emerge for developers attempting to integrate with them?
[1] http://rfc.net/rfc2616.html
----- Original Message -----
From: "Mark Baker" <mbaker@...>
To: <jbone@...>; <robert@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 8:45 AM
Subject: Re: [rest-discuss] Is REST CRUD?
I don't like your description of POST there Jeff. POSTed data need not
have anything to do with being a representation of the resource to which
it's being POSTed. Like POSTing a representation of a pair of shoes to
a shopping cart.
It's just "take this data", with the (critical) proviso that a
successful response just means that the data was accepted, nothing more.
i.e. you need not tunnel with it to use it.
MB
-----Original Message-----
From: Jeff Bone <jbone@...>
To: Robert Leftwich <robert@...>
CC: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com>
Sent: Tue Jul 09 23:25:24 2002
Subject: Re: [rest-discuss] Is REST CRUD?
On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote:
> With your classification PUT and POST are only marginally
> different, in that PUT ''SHOULD be considered as a modified version'
of the
> resource, i.e. in its entirety, but POST can be a partial
representation of
> the resource.
Yes, that's my understanding. The imperfect analogy I've used before:
PUT ~= echo "foo" > foo
POST ~= echo "foo" >> foo
With the proviso that foo -- the file, the thing that's getting
redirected
to -- can be equivalent to a device file, i.e. could well be /dev/foo.
>> This is a subtle
>> distinction, but IMO an important one: POST isn't an arbitrary
method
>> dispatch interface, but rather a very specific method itself that
consumes a
>> representation of the intended resource state and acts accordingly.
>
> Isn't that classification exactly the same as PUT?
PUT is "replace." POST is "update," "append," etc. The distinction is
equivalent to the distinction between > and >>.
>
>
>> As with many of these issues, though, this is so subtle and slippery
that in
>> practice I find myself violating it all the time. ;-)
>
> IMHO that is a huge problem for REST and it may be an insurmountable
one -
> there is no canonical answer. This may be symptomatic of the fact that
the
> limited verb count means that you invariably have to overload/overlay
many
> meanings on top of them, so many in fact that their usefulness becomes
> diluted.
My guess is it's a combination of educational / cultural bias and
impedance
mismatch between toolkits and model...
>
>> In WebKit, ...
>
> Webkit == Webware (http://webware.sourceforge.net/) ?
>
Yup!
>> Trying to practice what I preach,
>
> Trying to find something to practice!
>
Keep searching, it's there. :-) (Seriously, it took me a year of
acrimonious head-butting with Mark and (esp) Roy to get it...
Jb
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark wrote: > > I don't like your description of POST there Jeff. POSTed data need not > have anything to do with being a representation of the resource to which > it's being POSTed. Like POSTing a representation of a pair of shoes to > a shopping cart. > And that's not a partial description of the desired new state of the cart...? Jb
> BTW, I'm a big fan of predicate calculus as a data model, but I'm not sure > what RDF buys you over arbitrary n-ary tuples when you're talking about > generative communication... Perhaps you could talk about that a bit? I was mostly refering to RDF being used by DAML+OIL. I want to use DAML+OIL to help describe what the XML is marking up. That way, as our schemas evolve, my code can remain flexible in handling the XML. My code would be written to understand DAML+OIL classes, instead of raw XML. It's an attempt to get away from hardcoding our application for particular schemas. I want the application to understand problem domains, not particular object hierarchies. > Make sure instances of some schema embed a reference to an immutable copy of > their schema. It also helps to have named, declarative descriptions of > transformations between schema versions that can be referenced... In XML, > for instance, this could perhaps be an XSLT that transforms XML schemas. In an all XML world, XSLT helps greatly to move me from schema to schema, especially when the data document references a schema version. Unfortunately, we're bound to C++ and its available libraries for these things seem to be sparse. But in a perfect world.... :) Seth
On Wed, Jul 10, 2002 at 02:41:41PM -0500, Jeff Bone wrote: > And that's not a partial description of the desired new state of the > cart...? Ok, sub-optimal example. 8-) There need not be any remnant of the state reflected in the POSTed entity after processing. For example, if I POSTed a picture of a hand to a dog resource, the dog may change state to "recently petted". But the fact that a hand induced the state change isn't reflected in the state of the dog. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I've been musing for a while about how to do everything you see in peer to peer with http. Bidirectional communications are a real blocking factor. What I mean by bidirectional is allow either side in a transaction to initiate requests. The way to do this in HTTP is to have both sides establish a separate connection. But this doesn't really solve the problems. The problems are: * long lasting connections. HTTP is designed around one-shot connections to pick up some hypertext. Mechanisms to get a bunch of files keep the connection open, but only until a batch of related resources have been transferred. P2P often uses an ongoing stream. Now, maybe you can argue that ongoing streams make no sense, but that's swimming upstream. You could argue that P2P designs should be rebuilt to use hypertext, but that's also swimming upstream. P2P has gotten a huge amount of thought put into it and it uses ongoing connections so often for a reason. * efficiency. Using two sockets instead of one, plus the cost of maintaining open connections, is a brutual efficiency hit. * firewall transgression. being able to able to establish a server connection to a node behind a firewall, by having the server create the TCP connection but otherwise act as a server, is a critical tool. few p2p apps could live without it. * event mechanisms. given a single unidirectional connection there is no way for a server to initiate an event, short of the knownow hack of running events along the backstream to the client. * coordinating related events on the two streams. It is much easier to do this with a single connection than with two. (Years ago I actually did write a coordinator for two connections, and it was a bear to get the details right.) I've done enough preliminary hacking in Tomcat to know that I can munge the socket layer -- exclusively stuff below HTTP -- to support long lasting connections where both parties can act as a client, server or both. But I am queasy about how this interacts with REST design. The new design would still work by resource modelling. However it would not be oriented towards hypertext, so stuff related to connection keep alive would be hairy. It would not work with existing proxies, but that's not a REST issue IMO. On the other hand, the new design would be HTTP to the letter, because HTTP doesn't say anyting about the socket layer. ...thoughts? - Lucas
On 7/10/02 3:33 PM, "Mark Baker" <distobj@...> wrote: > On Wed, Jul 10, 2002 at 02:41:41PM -0500, Jeff Bone wrote: >> And that's not a partial description of the desired new state of the >> cart...? > > Ok, sub-optimal example. 8-) > > There need not be any remnant of the state reflected in the POSTed > entity after processing. For example, if I POSTed a picture of a hand > to a dog resource, the dog may change state to "recently petted". But > the fact that a hand induced the state change isn't reflected in the > state of the dog. My point is that there's a difference between "here is a hand, update your state accordingly" and "change your state to recently petted." Subtle, but important... Actually, though, I think we're in violent agreement and my initial attempt to explain my perspective was rather poor, leading to the misunderstanding. Jb
>>There need not be any remnant of the state reflected in the POSTed >>entity after processing. For example, if I POSTed a picture of a hand >>to a dog resource, the dog may change state to "recently petted". But >>the fact that a hand induced the state change isn't reflected in the >>state of the dog. > > > My point is that there's a difference between "here is a hand, update your > state accordingly" and "change your state to recently petted." This is an excellent point that we've had to deal with. Our network application is very RESTful. All we transfer across the network are new representations of objects. We always need to know, however, who made the change, and how it was made. The fact that the dog is now being petted is not enough. We needed to know the Who and the How as well. We've wrapped up the Who, How, and What into a simple Request. Just sending the What (dog) wasn't enough. So the question becomes, when trasnfering the state of the dog, how do I also say who's responsible for that state change? Do I also send a new state of a Hand which is now Petting and hyperlink that to a Person? Or do I bundle up the Who with the What? Seth
On Wed, Jul 10, 2002 at 04:06:37PM -0500, Jeff Bone wrote: > My point is that there's a difference between "here is a hand, update your > state accordingly" and "change your state to recently petted." > > Subtle, but important... Actually, though, I think we're in violent > agreement and my initial attempt to explain my perspective was rather poor, > leading to the misunderstanding. Yup, sounds like it. I just like the, IMO simple description that I provided two emails ago about "passing data". People are going to tunnel through any method that goes through a firewall, no matter what it's defined to mean, so I wouldn't worry so much about the "slippery slope". MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On 7/10/02 7:04 PM, "Mark Baker" <distobj@...> wrote: > On Wed, Jul 10, 2002 at 04:06:37PM -0500, Jeff Bone wrote: >> My point is that there's a difference between "here is a hand, update your >> state accordingly" and "change your state to recently petted." >> >> Subtle, but important... Actually, though, I think we're in violent >> agreement and my initial attempt to explain my perspective was rather poor, >> leading to the misunderstanding. > > Yup, sounds like it. I just like the, IMO simple description that I provided > two emails ago about "passing data". People are going to tunnel through any > method that goes through a firewall, no matter what it's defined to mean, so > I wouldn't worry so much about the "slippery slope". Who the hell are you, and what have you done with Mark Baker? ;-) Jb
How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work? In other words, I'm waiting for the day when someone uses SOAP as a framework to create an application protocol like HTTP ;-) -Philip S. Mike Dierken wrote: > How about "XHTML is to XML as C++ is to programming" > Or "XHTML is to XML as InternetExplorer is to C++" > > Mark Baker wrote: > > I was trying to draw a protocol analogy to XML/XHTML. The best I could > > come up with was; > > > > XML is to XHTML as HTTP is to Yahoo.
----- Original Message ----- > How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work? > > In other words, I'm waiting for the day when someone uses SOAP as a framework to > create an application protocol like HTTP ;-) > In my 'copious free time' I was going to write a WSDL that had four methods - get, put, post, delete - and paramters for http headers & responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a vein...
Monday, July 08, 2002 9:40 PM, Seairth wrote: > I agree that HTTP has taken on a lot more over the years. However, it seems > to me that HTTP 1.1 contains a lot of features that are not necessarily > RESTful (e.g. persistant connections). In other words, I think that there is > a subset of HTTP 1.1 that is definitely RESTful. How is the persistent connections feature not RESTful? I see it as an approach defined in the standard to optimize interactions. Are there other features that you believe are "not necessarily RESTful"? Thanks, Philip
Jeffrey,
Just to add my two cents before I go to sleep, this (the RFC 2616.9.6
description) is exactly how I interpret the contrast between POST and PUT. In
REST terms: with PUT I am sending the entity as a representation to create or
replace the resource at the URI provided on the request line; and with POST, I
am sending the entity as a representation that is *subordinate* to the resource
at the URI provided on the request line.
What it means to "create" or "replace" or "send a subordinate" is up to the
server on the other side of the URI. Heck, for PUT and/or POST, the URI may not
even physically exist.
-Philip
-----Original Message-----
From: Jeffrey Winter [mailto:j.winter@...]
Sent: Wednesday, July 10, 2002 3:37 PM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Is REST CRUD?
I agree with Mark on the interpretation of POST.
From the RFC [1]:
9.6 PUT
[...]
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
Still, how might subtle differences in interpretation of the non-GET methods
effect the adoption of the REST model? If web services are built that
don't follow these guidelines strictly enough, what sorts of
problems could emerge for developers attempting to integrate with them?
[1] http://rfc.net/rfc2616.html
----- Original Message -----
From: "Mark Baker" <mbaker@...>
To: <jbone@...>; <robert@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 8:45 AM
Subject: Re: [rest-discuss] Is REST CRUD?
I don't like your description of POST there Jeff. POSTed data need not
have anything to do with being a representation of the resource to which
it's being POSTed. Like POSTing a representation of a pair of shoes to
a shopping cart.
It's just "take this data", with the (critical) proviso that a
successful response just means that the data was accepted, nothing more.
i.e. you need not tunnel with it to use it.
MB
[snip]
Then, send those messages as streams in a standard HTTP-tunnelled RMI/IIOP method invocation, and you are set to cause some serious cholesterol build-up ;-) -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Wednesday, July 10, 2002 11:27 PM To: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] XML/XHTML analogy ----- Original Message ----- > How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work? > > In other words, I'm waiting for the day when someone uses SOAP as a framework to > create an application protocol like HTTP ;-) > In my 'copious free time' I was going to write a WSDL that had four methods - get, put, post, delete - and paramters for http headers & responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a vein... To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
On Wed, Jul 10, 2002 at 08:26:46PM -0700, S. Mike Dierken wrote: > In my 'copious free time' I was going to write a WSDL that had four > methods - get, put, post, delete - and paramters for http headers & > responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a > vein... FWIW, Paul (and more recently, me) tried to get the WSDL 1.2 folks to remove the distinction between WSDL operations and HTTP verbs in the HTTP binding. Currently you need both, which pretty much mandates tunneling over HTTP. http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0053 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, Jul 10, 2002 at 04:37:39PM -0400, Lucas Gonze wrote: > * long lasting connections. HTTP is designed around one-shot connections > to pick up some hypertext. Mechanisms to get a bunch of files keep the > connection open, but only until a batch of related resources have been > transferred. P2P often uses an ongoing stream. Now, maybe you can argue > that ongoing streams make no sense, but that's swimming upstream. You > could argue that P2P designs should be rebuilt to use hypertext, but > that's also swimming upstream. P2P has gotten a huge amount of thought > put into it and it uses ongoing connections so often for a reason. HTTP supports "ongoing streams", as you describe them. Entities can be streams in HTTP. > * efficiency. Using two sockets instead of one, plus the cost of > maintaining open connections, is a brutual efficiency hit. Ok. > * firewall transgression. being able to able to establish a server > connection to a node behind a firewall, by having the server create the > TCP connection but otherwise act as a server, is a critical tool. few p2p > apps could live without it. Not sure I follow - I think you said "server" once too many times. 8-) > * event mechanisms. given a single unidirectional connection there is no > way for a server to initiate an event, short of the knownow hack of > running events along the backstream to the client. Right, but I wouldn't call it a hack. It seems a fundamental feature of the generic interface that a client can request events with GET, as long as those events stop when the connection drops. > I've done enough preliminary hacking in Tomcat to know that I can munge > the socket layer -- exclusively stuff below HTTP -- to support long > lasting connections where both parties can act as a client, server or > both. But I am queasy about how this interacts with REST design. > > The new design would still work by resource modelling. However it would > not be oriented towards hypertext, so stuff related to connection keep > alive would be hairy. It would not work with existing proxies, but that's > not a REST issue IMO. > > On the other hand, the new design would be HTTP to the letter, because > HTTP doesn't say anyting about the socket layer. I'm a bit wary of the above description. IMO, not working with existing proxies is definitely an issue. Have you considered an HTTP extension method similar to SMTP TURN/ETRN for turning the connection around? I guess that might not be sufficient, since it just flips it, it doesn't permit bi-directional comms over the same socket simultaneously - but I don't know for sure until I see some use cases. And FWIW, you could specify this as a new protocol, but it would be a new protocol, not HTTP, though you could reuse lots of HTTP. But if you read through Section 8 of 2616 while thinking about true 2-way over a single connection, you'd see that the complexity of both specification and implementation (i.e. wouldn't be able to reuse any existing HTTP library) would probably be nasty. *Much* simpler extensions, such as draft-mogul-http-ooo-01.txt (out of order responses in pipelining), had this same problem with existing libraries. Alternately, you could use CONNECT to create a tunnel, and then the server could tunnel HTTP back through. That would probably be simpler, but firewalls don't typically honour CONNECT, IIRC. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Maintaining a connection implicitly means the server itself is maintaining state. I agree that it may be a weak argument, but I am pretty sure IIS (and possibly other HTTP servers) takes advantage of this internally. Also, people tend to use the tools available if they think it will help. It is highly foreseeable that a server application would take advantage of the persistent connection to maintain state. I am not saying that someone who is mindful of REST would do such a thing. All I was saying was that HTTP 1.1 contains additional features over HTTP 1.0 that are less RESTful in nature. Another argument is that persistent connections potentially do not scale well. Yes, a persistent connection does reduce network traffic and latency, but it also means that a given server can handle fewer connections over a period of time, especially if the clients and the server are keeping the connections open, but are otherwise idle. As for another example of a part of HTTP 1.1 I feel is not RESTful (in my mind): the If-Match, If-Modified-Since, If-None-Match, If-Range, and If-Unmodified-Since header fields (14.24-28). From my understanding of these fields, the client is effectively telling the server how to act. I was under the impression that a client could submit a representation of a resource to the server, but the client has no control over what the server actually does with the resource. Likewise, I thought that the client has no control over the representation of the resource returned to it. However, these header fields appear to give the client some control over how the server receives and returns representations of resources. Of course, since I am still figuring out what REST really is, I fully admit that I may also be viewing all of this incorrectly... --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Philip Eskelin" <philip@...> To: "'Seairth Jacobs'" <seairth@...> Cc: "'rest-discuss'" <rest-discuss@yahoogroups.com> Sent: Wednesday, July 10, 2002 11:29 PM Subject: RE: [PMX:#] [rest-discuss] REST and HTTP > Monday, July 08, 2002 9:40 PM, Seairth wrote: > > I agree that HTTP has taken on a lot more over the years. However, it seems > > to me that HTTP 1.1 contains a lot of features that are not necessarily > > RESTful (e.g. persistant connections). In other words, I think that there is > > a subset of HTTP 1.1 that is definitely RESTful. > > How is the persistent connections feature not RESTful? I see it as an approach > defined in the standard to optimize interactions. > > Are there other features that you believe are "not necessarily RESTful"? > > Thanks, > Philip > > >
----- Original Message ----- From: "Seth Ladd" <seth@...> > > So the question becomes, when trasnfering the state of the dog, how do I > also say who's responsible for that state change? Do I also send a new > state of a Hand which is now Petting and hyperlink that to a Person? > > Or do I bundle up the Who with the What? > I think this is an important issue for real world applications. A simple approach is to have the request message reference the principal under whose authority the request is to be carried out - essentially the user ID (or 'was carried out' for events). A more complex approach would involve verifying the sender has the authority to act on behalf of the principal - essentially credentials/password (or sessionId or capabilities, etc.). It would be interesting to make the link to the principal a full URI - and allow for relative references, etc. I haven't seen this done though, so it's new ground. For the standby of HTTP, the Authorization header provides an extensible format for identifying principals and providing credentials. But I'm not too sure I like the handshaking/negotiating of usernames/passwords in HTTP - I don't know of a way for the server to hand out (transient) credentials to the client - at least not with Web browser user-agents.
----- Original Message ----- From: "Lucas Gonze" <lgonze@...> Cc: <rest-discuss@yahoogroups.com> Sent: Wednesday, July 10, 2002 1:37 PM Subject: [rest-discuss] socket-level mods > > I've been musing for a while about how to do everything you see in peer to > peer with http. Bidirectional communications are a real blocking factor. > * efficiency. Using two sockets instead of one, plus the cost of > maintaining open connections, is a brutual efficiency hit. I'm not so sure about this - what types/roles are the machines & what numbers of sockets are you thinking of? Good sized servers should be able to have 10K open connections without a problem. > * firewall transgression. being able to able to establish a server > connection to a node behind a firewall, by having the server create the > TCP connection but otherwise act as a server, is a critical tool. few p2p > apps could live without it. Agreed. > > * event mechanisms. given a single unidirectional connection there is no > way for a server to initiate an event, short of the knownow hack of > running events along the backstream to the client. Hey.. it's not a hack, its 'elegant'... > > * coordinating related events on the two streams. It is much easier to do > this with a single connection than with two. (Years ago I actually did > write a coordinator for two connections, and it was a bear to get the > details right.) > > I've done enough preliminary hacking in Tomcat to know that I can munge > the socket layer -- exclusively stuff below HTTP -- to support long > lasting connections where both parties can act as a client, server or > both. But I am queasy about how this interacts with REST design. This is an area I would love to work on - a networking layer that did a persistent, client-initiated connection and then consumed incoming messages and delivered them to a regular HTTP server (possibly via jserv sockets to tomcat or something) as an unsolicited incoming request. This lets you write server-apps on clients/desktops - use all the tools you are familiar with - ASP, JSP, servlets, etc. With some COM events, you can even deliver to Win32 apps. The other pieces you need are public names (host/domain), an intermediary to do the message transfer/new-protocol, and some sort of security. This would 'break' HTTP in that the messages between the client and the message server would not be visibly HTTP requests - but that's okay. > > The new design would still work by resource modelling. However it would > not be oriented towards hypertext, so stuff related to connection keep > alive would be hairy. It would not work with existing proxies, but that's > not a REST issue IMO. I don't think keep-alive is related to hypertext. I don't know why you see it as different than a persistent connection? The handshaking is still request/response (except for chunked-transfer-encoding, but I wouldn't mess with that). > > On the other hand, the new design would be HTTP to the letter, because > HTTP doesn't say anyting about the socket layer. > > ...thoughts? This is what I was talking about a while ago with the asynch-http & http+events discussion. Can't find the links right now...
before going into detail on responses, let me state the problem: I want to be able to do anything that Gnutella can do in a RESTy way. If there is a reason why this is a bad idea, I want to hear it. On Thu, 11 Jul 2002, S. Mike Dierken wrote: > > * efficiency. Using two sockets instead of one, plus the cost of > > maintaining open connections, is a brutual efficiency hit. > I'm not so sure about this - what types/roles are the machines & what > numbers of sockets are you thinking of? > Good sized servers should be able to have 10K open connections without a > problem. maybe I'm plain wrong. I'll hold off on declaring this a showstopper. ;) > > * event mechanisms. given a single unidirectional connection there is no > > way for a server to initiate an event, short of the knownow hack of > > running events along the backstream to the client. > Hey.. it's not a hack, its 'elegant'... hold the fort til you code it. man what a hairy mess. plus, requests received over a response channel are http tunnelled through http, which is a bad idea. > > > > > * coordinating related events on the two streams. It is much easier to do > > this with a single connection than with two. (Years ago I actually did > > write a coordinator for two connections, and it was a bear to get the > > details right.) > > > > I've done enough preliminary hacking in Tomcat to know that I can munge > > the socket layer -- exclusively stuff below HTTP -- to support long > > lasting connections where both parties can act as a client, server or > > both. But I am queasy about how this interacts with REST design. > > This is an area I would love to work on - a networking layer that did a > persistent, client-initiated connection and then consumed incoming messages > and delivered them to a regular HTTP server (possibly via jserv sockets to > tomcat or something) as an unsolicited incoming request. It's very doable. There are a lot of assumptions in the tomcat code that you won't do it, but I haven't hit any hard blocks so far. (Can't say the same for Jetty etc. It's a credit to tomcat's clean design that this is doable.). > > > > > The new design would still work by resource modelling. However it would > > not be oriented towards hypertext, so stuff related to connection keep > > alive would be hairy. It would not work with existing proxies, but that's > > not a REST issue IMO. > I don't think keep-alive is related to hypertext. I don't know why you see > it as different than a persistent connection? > The handshaking is still request/response (except for > chunked-transfer-encoding, but I wouldn't mess with that). I'm thinking of Roy's dissertation, where he is very clear that there was an expected granularity of content, which is the granularity of hypertext. > > > > > On the other hand, the new design would be HTTP to the letter, because > > HTTP doesn't say anyting about the socket layer. > > > > ...thoughts? > This is what I was talking about a while ago with the asynch-http & > http+events discussion. Can't find the links right now... Nice. It's what I was thinking about too. The purpose of that whole thing for me was to understand what (if anything) had to be done.
> > * firewall transgression. being able to able to establish a server > > connection to a node behind a firewall, by having the server create the > > TCP connection but otherwise act as a server, is a critical tool. few p2p > > apps could live without it. > > Not sure I follow - I think you said "server" once too many times. 8-) ack. Last time around we resorted to source/sink to have clear language in this setting. What I'm thinking of is the TURN/ETRN functionality you mention below. > > > * event mechanisms. given a single unidirectional connection there is no > > way for a server to initiate an event, short of the knownow hack of > > running events along the backstream to the client. > > Right, but I wouldn't call it a hack. It seems a fundamental feature > of the generic interface that a client can request events with GET, as > long as those events stop when the connection drops. Yes, but if the events are themselves requests you are tunnelling http in http. If that's not evil I wnat to know why not. > > On the other hand, the new design would be HTTP to the letter, because > > HTTP doesn't say anyting about the socket layer. > > I'm a bit wary of the above description. IMO, not working with existing > proxies is definitely an issue. To the degree that it matters, it is a doable change to modify (some but not all) existing proxies. One thing at a time. > Have you considered an HTTP extension method similar to SMTP TURN/ETRN > for turning the connection around? I guess that might not be sufficient, > since it just flips it, it doesn't permit bi-directional comms over the > same socket simultaneously - but I don't know for sure until I see some > use cases. As always, I really really object to adding new methods. There's a reason why I want to go _below_ HTTP to make mods like this. > > And FWIW, you could specify this as a new protocol, but it would be a > new protocol, not HTTP, though you could reuse lots of HTTP. But if you > read through Section 8 of 2616 while thinking about true 2-way over a > single connection, you'd see that the complexity of both specification > and implementation (i.e. wouldn't be able to reuse any existing HTTP > library) would probably be nasty. *Much* simpler extensions, such as > draft-mogul-http-ooo-01.txt (out of order responses in pipelining), had > this same problem with existing libraries. You have to specify it as a new protocol because it would break existing implementations. However I read the spec fairly carefully to find anything about this new protocol that was in conflict and found absolutely nothing. The RFC requires nothing at at the transport layer. My working plan is to use the HTTP Upgrade: response header with a value for the new protocol of "AC-HTTP". "AC" meaning "alternating current." > Alternately, you could use CONNECT to create a tunnel, and then the > server could tunnel HTTP back through. That would probably be simpler, > but firewalls don't typically honour CONNECT, IIRC. Plus you still have the rest of the problems to face. EG, incompatibility.
> > > > * event mechanisms. given a single unidirectional connection there is no > > > way for a server to initiate an event, short of the knownow hack of > > > running events along the backstream to the client. > > Hey.. it's not a hack, its 'elegant'... > > hold the fort til you code it. man what a hairy mess. plus, requests > received over a response channel are http tunnelled through http, which is > a bad idea. It's easy to code javascript clients for KN. Keeping the server from chewing up memory is a problem - I've stopped running mine. Why is tunneling HTTP through HTTP a bad idea? If the resource is a queue of messages - and the representation of the message is mime type "message/http" , then that is exactly what you are /supposed/ to do. Right? (This leads into my 'expanding the web onto desktops works in rest/http, but breaks in the real world' talk, which I'll have to find some time to write up fully...) > > > > > > > > The new design would still work by resource modelling. However it would > > > not be oriented towards hypertext, so stuff related to connection keep > > > alive would be hairy. It would not work with existing proxies, but that's > > > not a REST issue IMO. > > I don't think keep-alive is related to hypertext. I don't know why you see > > it as different than a persistent connection? > > The handshaking is still request/response (except for > > chunked-transfer-encoding, but I wouldn't mess with that). > > I'm thinking of Roy's dissertation, where he is very clear that there was > an expected granularity of content, which is the granularity of hypertext. Hypertext on the web has no 'bounded object set' - so the granularity is infinite. An individual message corresponds to about the size of a single portion of hypertext we normally call a document, so I don't see the problem.
Lucas Gonze wrote: > > before going into detail on responses, let me state the problem: I want > to be able to do anything that Gnutella can do in a RESTy way. If there > is a reason why this is a bad idea, I want to hear it. I'm not familiar with the Gnutella protocol. Maybe you could outline the major message types, resource types and addressing facilities or point to a good summarizing URI. To me the most fundamental problem is the same problem with all p2p apps: clients can be behind NAT and have no global addresses. So yes, you do need a TURN/ETRN and it won't be backwards compatible. My instinct is to have the client open a socket and ask for a backchannel with a POST. The server creates a "listener" and returns the port number and maybe some authentication data. The client connects *not* using HTTP but using a "reversible socket protocol". The client and server understand that on the reversed socket they have swapped roles. You can push the idea beyond HTTP. Reversable FTP would allow machines behind firewalls to publish FTP servers by pushing a reversed FTP connection to a "publishing intermediary." Same with reversable telnet. I don't have time right now to think through exactly how this differs from regular port forwarding but it feels like push versus pull. I can tell SSH: "forward FTP requests to my laptop" but I can't tell it: "wait for a signal from the laptop and then and only then should you forward FTP requests." Of course I can organize this connection out-of-band in a proprietary way. I doubt this idea is compatible with all existing infrastructure, but there is no solution that will be 100% compatible with existing infrastructure *except* tunnelling. By definition turning the existing one-way architecture into a two-way one requires either extension or tunnelling. If you care about the marketability of your protocol, it should probably provide both options. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Paul Prescod" <paul@...> > To me the most fundamental problem is the same problem with all p2p > apps: clients can be behind NAT and have no global addresses. So yes, > you do need a TURN/ETRN and it won't be backwards compatible. My > instinct is to have the client open a socket and ask for a backchannel > with a POST. The server creates a "listener" and returns the port number > and maybe some authentication data. The client connects *not* using HTTP > but using a "reversible socket protocol". The client and server > understand that on the reversed socket they have swapped roles. Yes - this sounds good. REST by its nature has 'passive resources' and 'active clients' that initiate operations upon those resources - it inherently implies direction of messaging. To implement this in the real world - as with http - you naively open a connection to the resource - but if it is behind a firewall then you can't. Hence Paul's suggestion - separate who /initiates/ the networking from the /direction/ of messages. I don't have a problem with the protocol for behind-the-firewall access being non-HTTP or at least non-sanctioned HTTP clone. I don't think it is /required/ to avoid HTTP (tunneling 'message/http' for example) for it to work - perhaps to make it more efficient, but people are at zero today, anything is an improvement.
Mike Dierken wrote: > It's easy to code javascript clients for KN. Keeping the server from chewing > up memory is a problem - I've stopped running mine. Do you mean writing the javascript client from scratch or using the KN library, Mike? > Why is tunneling HTTP through HTTP a bad idea? If the resource is a queue of > messages - and the representation of the message is mime type "message/http" > , then that is exactly what you are /supposed/ to do. Right? Anytime I've tried to work out the details things got messy. I have yet to see a situation where message-in-message made sense. It doesn't make sense because messages are about streams rather than resources. > > I'm thinking of Roy's dissertation, where he is very clear that there was > > an expected granularity of content, which is the granularity of hypertext. > Hypertext on the web has no 'bounded object set' - so the granularity is > infinite. An individual message corresponds to about the size of a single > portion of hypertext we normally call a document, so I don't see the > problem. Hm, I need to think about this. Is my sense that hypertext is a different thing just a mental block? There's a lot of blather about hypertext as a specific kind of content, but now I realize that I really don't know what it means. - Lucas
Paul Prescod said: > I'm not familiar with the Gnutella protocol. Maybe you could outline the > major message types, resource types and addressing facilities or point > to a good summarizing URI. It's totally brain dead but still hard to do with HTTP. What you need to know is that a connection is a continuous stream of message events. An outgoing message may have 0, 1, or more responses. The mechanics of store-and-forward are mashed into the message along with application functionality. Documentation for the 0.4 version of the protocol: http://www.rixsoft.com/Knowbuddy/gnutellafaq.html There are many things about it that I don't want to emulate. What I do want is how trivial it makes asynchronous messaging in a p2p context. > To me the most fundamental problem is the same problem with all p2p > apps: clients can be behind NAT and have no global addresses. So yes, > you do need a TURN/ETRN and it won't be backwards compatible. My > instinct is to have the client open a socket and ask for a backchannel > with a POST. The server creates a "listener" and returns the port number > and maybe some authentication data. The client connects *not* using HTTP > but using a "reversible socket protocol". The client and server > understand that on the reversed socket they have swapped roles. No doubt. but what is the reversible socket protocol? The most parsimonious solution to my mind is that it's 100% HTTP 1.1, except that the transport layer underneath is different. Is there any architectural reason why this wouldn't work? A total digression: the fundamental problem with p2p is that the network is self-organizing in a way that affects your moment to moment interactions. With browser-oriented applications the self-organizing macro structure is too big to be visible usually. > I doubt this idea is compatible with all existing infrastructure, but > there is no solution that will be 100% compatible with existing > infrastructure *except* tunnelling. By definition turning the existing > one-way architecture into a two-way one requires either extension or > tunnelling. If you care about the marketability of your protocol, it > should probably provide both options. It's incompatible in a wierd way. 99.99% of the thought that went into HTTP can be reused. All HTTP implementations need a little bit of hacking to be compatible. All HTTP-based applications need a total rewrite. The loss is that it's a new protocol, the win is that the new protocol is also HTTP. ...that's the idea anyway.
I may be totally off base here, and would need to do some experiments,
but given that HTTP runs over TCP, isn't it the case that a request
sent to a server can be held by the server nearly indefinitely before
it sends a reply?
If so, then one thing I learned from rubbing elbows with the old
CORBUS system at BBN is something called "futures". If a client makes
a request to a server, and that server hangs onto the request while
the client merrily goes on its way, then when the response eventually
comes, the client can treat it as an asynchronous message from the
server. If the server cleverly puts content into the reply, voila,
your client can wake up and deal with it.
If the TCP connection breaks, or the HTTP server times out and shuts
it down, the client would get a different signal/error. Then client
could then decide whether to send another future request or do
something else. In any case, you are buying time and leaving open a
means for an async notification.
This would move the problem up one level and you would not have to
muck with HTTP. The only issue is whether the breakage level is too
high, causing overconsumption of resources. Then you do have to work
on some optimizations (potentially even rewriting HTTP).
Allan
On Thursday 2002-07-11 at 19:41:29(-0400) Lucas Gonze wrote:
> Paul Prescod said:
> > I'm not familiar with the Gnutella protocol. Maybe you could outline the
> > major message types, resource types and addressing facilities or point
> > to a good summarizing URI.
>
> It's totally brain dead but still hard to do with HTTP. What you need to
> know is that a connection is a continuous stream of message events. An
> outgoing message may have 0, 1, or more responses. The mechanics of
> store-and-forward are mashed into the message along with application
> functionality.
>
> Documentation for the 0.4 version of the protocol:
> http://www.rixsoft.com/Knowbuddy/gnutellafaq.html
>
> There are many things about it that I don't want to emulate. What I do
> want is how trivial it makes asynchronous messaging in a p2p context.
>
> > To me the most fundamental problem is the same problem with all p2p
> > apps: clients can be behind NAT and have no global addresses. So yes,
> > you do need a TURN/ETRN and it won't be backwards compatible. My
> > instinct is to have the client open a socket and ask for a backchannel
> > with a POST. The server creates a "listener" and returns the port number
> > and maybe some authentication data. The client connects *not* using HTTP
> > but using a "reversible socket protocol". The client and server
> > understand that on the reversed socket they have swapped roles.
>
> No doubt. but what is the reversible socket protocol? The most
> parsimonious solution to my mind is that it's 100% HTTP 1.1, except that
> the transport layer underneath is different. Is there any architectural
> reason why this wouldn't work?
>
> A total digression: the fundamental problem with p2p is that the network
> is self-organizing in a way that affects your moment to moment
> interactions. With browser-oriented applications the self-organizing
> macro structure is too big to be visible usually.
>
> > I doubt this idea is compatible with all existing infrastructure, but
> > there is no solution that will be 100% compatible with existing
> > infrastructure *except* tunnelling. By definition turning the existing
> > one-way architecture into a two-way one requires either extension or
> > tunnelling. If you care about the marketability of your protocol, it
> > should probably provide both options.
>
> It's incompatible in a wierd way. 99.99% of the thought that went into
> HTTP can be reused. All HTTP implementations need a little bit of hacking
> to be compatible. All HTTP-based applications need a total rewrite. The
> loss is that it's a new protocol, the win is that the new protocol is also
> HTTP. ...that's the idea anyway.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle http://www.intl-interfaces.com
adoyle@...
----- Original Message ----- From: "Lucas Gonze" <lgonze@...> > Mike Dierken wrote: > > It's easy to code javascript clients for KN. Keeping the server from chewing > > up memory is a problem - I've stopped running mine. > > Do you mean writing the javascript client from scratch or using the KN > library, Mike? The javascript client isn't that hard to write from scratch - doing multiple windows communication in a browser is hard. > > > Why is tunneling HTTP through HTTP a bad idea? If the resource is a queue of > > messages - and the representation of the message is mime type "message/http" > > , then that is exactly what you are /supposed/ to do. Right? > > Anytime I've tried to work out the details things got messy. I have yet > to see a situation where message-in-message made sense. It doesn't make > sense because messages are about streams rather than resources. Yeah... I'd rather see the connection opened by the client & the roles reversed via a magic command - how about a new HTTP method of 'LISTEN'?
> The javascript client isn't that hard to write from scratch - doing multiple > windows communication in a browser is hard. cool. I didn't know that. ...figured that the interactions with the server would be too intimate to make the client-side protocol generic. > Yeah... I'd rather see the connection opened by the client & the roles > reversed via a magic command - how about a new HTTP method of 'LISTEN'? Not sure it's necessary! I think that you can use the Upgrade header -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 ' The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by the server, possibly according to the nature of the method and/or resource being requested). ' (major caveat emptor on everything I have to say here: the only actual code I have is a bunch of munged Tomcat source.)
Note that I've set followups to rest-explore - I think we're well past the introductory level here. 8-) On Thu, Jul 11, 2002 at 04:05:28PM -0400, Lucas Gonze wrote: > > Right, but I wouldn't call it a hack. It seems a fundamental feature > > of the generic interface that a client can request events with GET, as > > long as those events stop when the connection drops. > > Yes, but if the events are themselves requests you are tunnelling http in > http. If that's not evil I wnat to know why not. It is, but event notifications received on a GET aren't requests, they're responses. There's no tunneling going on. > As always, I really really object to adding new methods. There's a reason > why I want to go _below_ HTTP to make mods like this. [snip] > You have to specify it as a new protocol because it would break existing > implementations. However I read the spec fairly carefully to find > anything about this new protocol that was in conflict and found absolutely > nothing. The RFC requires nothing at at the transport layer. [snip] > My working plan is to use the HTTP Upgrade: response header with a value > for the new protocol of "AC-HTTP". "AC" meaning "alternating current." Those 3 paragraphs above seem contradictory to me. In the last one, you say that you're using the Upgrade header, and naming it akin to HTTP, both which suggest that your protocol is an application protocol. Yet your first and second paragraphs suggest that it's below an application protocol. If by "Upgrade" header, you were referring to your AC-HTTP, and using its upgrade mechanism to upgrade to HTTP, then I think we're in synch - at least I understand what you're suggesting. But it doesn't seem so. Anyhow, I believe that the application protocol idea is the right approach, and also this protocol should be an HTTP extension. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Thu, Jul 11, 2002 at 08:21:53PM -0400, Allan Doyle wrote: > If so, then one thing I learned from rubbing elbows with the old > CORBUS system at BBN is something called "futures". If a client makes > a request to a server, and that server hangs onto the request while > the client merrily goes on its way, then when the response eventually > comes, the client can treat it as an asynchronous message from the > server. If the server cleverly puts content into the reply, voila, > your client can wake up and deal with it. Right. I've built this with the HTTP 202 response, and using the Location header to return a URI that identifies the future. Then I just poll (with GET) the URI for the response. It works well. Very RESTful too. Roy likes to talk about the ability for URIs to identify resources that don't exist yet (the same way any identifier or name can, e.g. "me in 20 years"), so this is a great demonstration of that feature. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Lucas Gonze wrote: > >... > > > To me the most fundamental problem is the same problem with all p2p > > apps: clients can be behind NAT and have no global addresses. So yes, > > you do need a TURN/ETRN and it won't be backwards compatible. My > > instinct is to have the client open a socket and ask for a backchannel > > with a POST. The server creates a "listener" and returns the port number > > and maybe some authentication data. The client connects *not* using HTTP > > but using a "reversible socket protocol". The client and server > > understand that on the reversed socket they have swapped roles. > > No doubt. but what is the reversible socket protocol? The most > parsimonious solution to my mind is that it's 100% HTTP 1.1, except that > the transport layer underneath is different. Is there any architectural > reason why this wouldn't work? Right, my point was that the reversible TCP protocol would be a thin transport layer that just reverses a TCP connection. When you use an application protocol on top of a reverse TCP connection, whoever initiated the TCP connection behaves as if they had received it and vice versa. > A total digression: the fundamental problem with p2p is that the network > is self-organizing in a way that affects your moment to moment > interactions. With browser-oriented applications the self-organizing > macro structure is too big to be visible usually. That's true but I don't see it as particularly a problem that causes issues for REST. >.... > It's incompatible in a wierd way. 99.99% of the thought that went into > HTTP can be reused. All HTTP implementations need a little bit of hacking > to be compatible. All HTTP-based applications need a total rewrite. The > loss is that it's a new protocol, the win is that the new protocol is also > HTTP. ...that's the idea anyway. I'm not sure about this rewrite stuff. For Morpheus ran an HTTP server on each client to share files. You could browse someone else's share just with a browser. Clueless media people treated this as a "security hole." * http://slashdot.org/comments.pl?sid=27368&cid=0&pid=0&startat=&threshold=5&mode=flat&commentsort=0&op=Change -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
http://www.xml.com/pub/a/2002/07/10/rest.html Cool, we're even "*the* REST mailing list"! Note to Kendall; PROPFIND is unRESTful. 8-) See; http://lists.w3.org/Archives/Public/www-tag/2002Feb/0091 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On 7/11/02 9:30 AM, "Seairth Jacobs" <seairth@...> wrote: > Maintaining a connection implicitly means the server itself is maintaining > state. I agree that it may be a weak argument, but I am pretty sure IIS > (and possibly other HTTP servers) takes advantage of this internally. Also, > people tend to use the tools available if they think it will help. It is > highly foreseeable that a server application would take advantage of the > persistent connection to maintain state. I am not saying that someone who > is mindful of REST would do such a thing. All I was saying was that HTTP > 1.1 contains additional features over HTTP 1.0 that are less RESTful in > nature. Small but important point. This is a similar confusion to that with client-server, wherein the question of who initiates the TCP connection isn't really the issue but rather who makes the (app-level) request and who responds in a given interaction. Connection lifecycle does not impact RESTfulness at all --- it is VERY important to distinguish between the details of the lower level transport and sessions issues and the application semantics provided by the higher protocol stack layers. HTTP is an application-level protocol, and REST is *definitely* in the business of describing resources and which requests they service / what kind of responses they give. HTTP should not and REST does not have anything to say about the abstraction that we call a TCP connection. Now in fact, earlier revs of HTTP do in fact prescribe certain app-level semantics that are tightly tied to the TCP connection semantics, but this should be viewed as a mistake and, indeed, later versions have moved (albeit slowly) away from this tight coupling. A future, superior version of the HTTP spec will define HTTP in terms independent of its lower-layer protocols, and describe each binding of HTTP to a lower-level substrate independently of the application semantics. Short version: HTTP is conceptually independent of and REST is certainly independent of both the direction and duration of lower-level connections / sessions / what have you. > > Another argument is that persistent connections potentially do not scale > well. Yes, a persistent connection does reduce network traffic and latency, > but it also means that a given server can handle fewer connections over a > period of time, especially if the clients and the server are keeping the > connections open, but are otherwise idle. This is a detail of TCP stack implementations in various operating systems, not a limitation with the abstract notion of persistent connections. Now, it's an important practical concern --- but given the alternatives the right answer may be to reimplement or at least tune / tweak the lower-layer protocol stack. Cf. KnowNow. TCP doesn't really have so much state that it's impractical for a single device to service >10k simultaneous connections; this typical limitation is simply an example of bad engineering. > > As for another example of a part of HTTP 1.1 I feel is not RESTful (in my > mind): the If-Match, If-Modified-Since, If-None-Match, If-Range, and > If-Unmodified-Since header fields (14.24-28). From my understanding of > these fields, the client is effectively telling the server how to act. I'm somewhat inclined to agree with some of this; If-Mod* and If-Unmod* are probably okay because they are describing what they want in terms independent of some representation, but the rest presuppose some particular representation. > I > was under the impression that a client could submit a representation of a > resource to the server, but the client has no control over what the server > actually does with the resource. Likewise, I thought that the client has no > control over the representation of the resource returned to it. All they can do is ask for what they want; this should be in terms of what they want of the resource, not what they want as a representation. I.e., mod time says something about the resource; range does not. Jb
On 7/11/02 5:03 PM, "S. Mike Dierken" <mdierken@...> wrote: > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > >> To me the most fundamental problem is the same problem with all p2p >> apps: clients can be behind NAT and have no global addresses. So yes, >> you do need a TURN/ETRN and it won't be backwards compatible. My >> instinct is to have the client open a socket and ask for a backchannel >> with a POST. The server creates a "listener" and returns the port number >> and maybe some authentication data. The client connects *not* using HTTP >> but using a "reversible socket protocol". The client and server >> understand that on the reversed socket they have swapped roles. > > Yes - this sounds good. REST by its nature has 'passive resources' and > 'active clients' that initiate operations upon those resources - it > inherently implies direction of messaging. To implement this in the real > world - as with http - you naively open a connection to the resource - but > if it is behind a firewall then you can't. Yes definitely. Quick question - is the assumption of a friendly, non-firewalled / NAT'd intermediary a problem? If not, the simplest / most RESTful solution may simply be to allow the party behind the firewall to run a regular HTTP server, allow that "blocked" party to establish a tunnel (HTTP, presumably) to the third party, and subsequently adopt all of the port 80 traffic to that intermediary or, better, by engaging in a RESTful protocol *adopt* a portion of the intermediary's HTTP namespace. Requests to the intermediary are then funneled down the backchannel to the client, where they are locally dispatched onto the local HTTP server, and responses channeled back along the reverse path. This portion is a lot like mounting a filesystem from one server on another server then subsequently mounting the filesystem from the second server on some client for access --- except it deals directly with the directionality problem of HTTP. > Hence Paul's suggestion - > separate who /initiates/ the networking from the /direction/ of messages. I > don't have a problem with the protocol for behind-the-firewall access being > non-HTTP or at least non-sanctioned HTTP clone. Actually I do, but only in that I see it proliferating protocols and code where it's strictly speaking neither optimal or necessary. Jb
On 7/11/02 10:57 PM, "Mark Baker" <distobj@...> wrote: > > Note to Kendall; PROPFIND is unRESTful. 8-) Ah, this gives me such great satisfaction. *-)) Jb
> > The javascript client isn't that hard to write from scratch - doing multiple > > windows communication in a browser is hard. > > cool. I didn't know that. ...figured that the interactions with the > server would be too intimate to make the client-side protocol generic. Just take a look at the script that comes down from a KN page - essentially there is a hidden frame that receives the streaming response from the server. The response is set of <form id="msg_id"> elements - which are DOM accessible in all browsers - followed by a <script> tag which calls a parent frame callback with the msg_id - the DOM node gets passed essentially. Browsers parse the <form> and interpret the <script> in a streaming fashion - so things happen right away. Simplicity itself. The only tricky parts are the cross-frame and cross-window (and cross-domain) scripting. > > > Yeah... I'd rather see the connection opened by the client & the roles > > reversed via a magic command - how about a new HTTP method of 'LISTEN'? > > Not sure it's necessary! I think that you can use the Upgrade header -- > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 > > ' The Upgrade header field is intended to provide a simple mechanism for > transition from HTTP/1.1 to some other, incompatible protocol. It does so > by allowing the client to advertise its desire to use another protocol, > such as a later version of HTTP with a higher major version number, even > though the current request has been made using HTTP/1.1. This eases the > difficult transition between incompatible protocols by allowing the > client to initiate a request in the more commonly supported protocol > while indicating to the server that it would like to use a "better" > protocol if available (where "better" is determined by the server, > possibly according to the nature of the method and/or resource being > requested). ' > > (major caveat emptor on everything I have to say here: the only actual > code I have is a bunch of munged Tomcat source.) > I'm thinking that taking mod_jserv (or whatever the mod it that talks the apjserv protocol between apache & tomcat) and changing it to look for the new method or 'upgrade' header and responding with OK and then forwarding any further requests down the jserv connection - which what the mod_jserv already does! The jserv startup would need configuration for what host & url to 'attach/mount' and then do the http request with the method or header. All the existing security (including the 'upgrade' request) would take place in the hosted Apache server outside the firewall. Oh, for some spare time...
> > > > Yeah... I'd rather see the connection opened by the client & the roles > > reversed via a magic command - how about a new HTTP method of 'LISTEN'? > > > > Aaaargh! > > Seriously: GET, PUT, POST, DELETE are all *clearly* about the resource > named. I.e., if they're the verbs, the named resources is the *direct > object*, not the *subject.* What resource exactly does a "LISTEN" apply to? > And if you tell me it's a way to subscribe to events from the named > resource, how is that different from GET? And if you tell me it's because > those events are asynchronously delivered, potentially to some other > resource named in the original request, how does that differ from i.e. The > HTTP Events proposal and similar / related proposals? Ok... a GET probably would work with an 'upgrade' header - I'm just looking for some way to signal the role reversal that seems to be needed to assist firewalled nodes.
> Yes definitely. > > Quick question - is the assumption of a friendly, non-firewalled / NAT'd > intermediary a problem? If not, the simplest / most RESTful solution may > simply be to allow the party behind the firewall to run a regular HTTP > server, allow that "blocked" party to establish a tunnel (HTTP, presumably) > to the third party, and subsequently adopt all of the port 80 traffic to > that intermediary or, better, by engaging in a RESTful protocol *adopt* a > portion of the intermediary's HTTP namespace. Requests to the intermediary > are then funneled down the backchannel to the client, where they are locally > dispatched onto the local HTTP server, and responses channeled back along > the reverse path. Yes! I want the behind-the-firewall node to 'adopt/mount' a namespace hosted by the intermediary. Requests - after the 'mount' operation - would then flow down the connection to the firewalled node. 99% of this technology already exists. The firewalled node can attach the connection to existing HTTP/MIME parsers and dispatch accordingly - run some JSP or ASP or whatever. > > This portion is a lot like mounting a filesystem from one server on another > server then subsequently mounting the filesystem from the second server on > some client for access --- except it deals directly with the directionality > problem of HTTP. Yes! Since REST (in my opinion) has fundamental directionality associated with resources (the resource is always the 'server') in order to grow the Web by the next factor of 10,000x we need to enable more machines - desktops, etc. This is a lot more attractive at solving real world problems than the PedanticWeb. > > > Hence Paul's suggestion - > > separate who /initiates/ the networking from the /direction/ of messages. I > > don't have a problem with the protocol for behind-the-firewall access being > > non-HTTP or at least non-sanctioned HTTP clone. > > Actually I do, but only in that I see it proliferating protocols and code > where it's strictly speaking neither optimal or necessary. > If it's not necessary, I wouldn't do it either. I envision HTTP requests flowing down the connection and responses flowing back up in exactly the same fashion as non-firewalled node - only there is an out-of-phase mark when the two machines switch roles. This may confuse intermediaries, but with Lucas' upgrade header, this may be legal.
On 7/11/02 11:23 PM, "S. Mike Dierken" <mdierken@...> wrote: > > Ok... a GET probably would work with an 'upgrade' header - I'm just looking > for some way to signal the role reversal that seems to be needed to assist > firewalled nodes. Granted, that's important, desirable, and appropriate. It should IMO be a header and / or an additional server-initiated NOTIFY "response" method, latter of which should not be directed to a resource but (as certain other methods, like OPTIONS) directed to a namespace / message dispatching authority. My reasoning for the latter is a bit involved but IIRC well documented in the discussion of HTTP Events. Short version: doing it thus avoids presupposing a "model" for resources which accept events and affords much greater flexibility for server implementations. Also plays nicely with caches for the purpose of cache expiry notifications, which shouldn't be directed to a reified cache but to an authority. There might be other motivations for reifying caches, but this isn't one of them. Making subscribers authorities rather than resources avoids some nasty recursive thinking ala the problems Lucas was eluding to, but... I'm flexible on that issue. Jb
Allan Doyle wrote: > I may be totally off base here, and would need to do some experiments, > but given that HTTP runs over TCP, isn't it the case that a request > sent to a server can be held by the server nearly indefinitely before > it sends a reply? This strikes me as completely sensible. It's interesting that it's also in the bag of socket-level modifications. HTTP is exactly what it always was, but there are extensions happening underneath it in the transport layer. (Aside to Mark: I think that Allan's comment is not about a set of request/response pairs, but a single pair where the reply is sent in a time frame _completely_ different from the browser timeframe. Aside to Allan: correct me if I'm putting words in your mouth.)
On 7/11/02 7:48 PM, "S. Mike Dierken" <mdierken@...> wrote: > > Yeah... I'd rather see the connection opened by the client & the roles > reversed via a magic command - how about a new HTTP method of 'LISTEN'? > Aaaargh! Seriously: GET, PUT, POST, DELETE are all *clearly* about the resource named. I.e., if they're the verbs, the named resources is the *direct object*, not the *subject.* What resource exactly does a "LISTEN" apply to? And if you tell me it's a way to subscribe to events from the named resource, how is that different from GET? And if you tell me it's because those events are asynchronously delivered, potentially to some other resource named in the original request, how does that differ from i.e. The HTTP Events proposal and similar / related proposals? Jb
fyi - I just learned that MySQL has a 'REPLACE' SQL statement - which does a conditional insert or update (upsert). This is equivalent to PUT in HTTP-land. Oracle9i added 'MERGE' with funky conditional logic in the SQL after that to do a similar thing. Interesting that the same kind of primary data manipulation operations show up elsewhere...
Hi I think describing REST as a 'architectural style' is questionable. I think REST is more than just a style and could better be described as 'architectural principals'. In architecture (the built environment) styles are essentially fads and fashions, principals are more fundamental aspects of form and structure. Some aspects of REST are accurately described as questions style, for example the 'aesthetics of URI design' but to sum it up as a 'style' is (speaking as someone from an architectural background) a mistake that under plays it's importance. IMHO Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
On Friday 2002-07-12 at 00:48:21(-0400) Lucas Gonze wrote:
>
> Allan Doyle wrote:
> > I may be totally off base here, and would need to do some experiments,
> > but given that HTTP runs over TCP, isn't it the case that a request
> > sent to a server can be held by the server nearly indefinitely before
> > it sends a reply?
>
> This strikes me as completely sensible. It's interesting that it's also
> in the bag of socket-level modifications. HTTP is exactly what it always
> was, but there are extensions happening underneath it in the transport
> layer.
>
> (Aside to Mark: I think that Allan's comment is not about a set of
> request/response pairs, but a single pair where the reply is sent in a
> time frame _completely_ different from the browser timeframe.
>
> Aside to Allan: correct me if I'm putting words in your mouth.)
No, you got it right. The sequence is
1. Client sends request "A"
2. Server receives request "A"
3. Client does other stuff, including sending more requests
4. Server does other stuff, including servicing other requests
5. Some time later, server has something to say to client
6. Server sends what it has to say via response to "A"
The client did not have to poll. The server had to hang on to the
state. But in Marks request/202/poll to server also has to hang on to
the same state.
If the connection breaks, the client and server will each get an error
before step 5. The server should simply drop the state since there's
no way to recover w/o the client coming back. The client should go
back to step 1 if it still wants the channel open.
Allan
(And it was CRONUS, not CORBUS, I had a brain cramp on that
one. CORBUS was a CORBA wrapper on CRONUS)
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle http://www.intl-interfaces.com
adoyle@...
On Fri, Jul 12, 2002 at 01:02:22PM +0100, Chris Croome wrote: > In architecture (the built environment) styles are essentially fads and > fashions, principals are more fundamental aspects of form and structure. An architectural style is an integrated set of architectural principles. Roy talks about this in the context of patterns (principles) and pattern languages (styles). So REST, the style, encompasses such principles/patterns as "generic interface", "stateless interactions", "hypermedia as engine of application state", etc.. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Fri, Jul 12, 2002 at 09:15:13AM -0400, Allan Doyle wrote:
> 5. Some time later, server has something to say to client
> 6. Server sends what it has to say via response to "A"
>
> The client did not have to poll. The server had to hang on to the
> state. But in Marks request/202/poll to server also has to hang on to
> the same state.
Ah, well historically, futures support both poll and notify modes.
I remember the Expersoft ORB from way-back-when whose Future interface
was like this;
interface Future
{
getResponseAndBlock()
registerCallback()
checkForResponse()
}
The important feature of a Future was merely to represent the future
response, not restrict ways in which you'd expect to be able to use it.
The value of futures, in my experience, was just to simplify client
code as you didn't always have to worry about threading. So I rarely
used them in the way you mentioned, since that required threads to be
managed. I almost always just checked for a response. So you could
imagine a REST based future interface that used a local proxy to manage
your "callback mailboxes", permitting a HEAD to one of those URIs to be
"checkForResponse", GET to be "getResponseAndBlock", and
"registerCallback" would be when your app code was tightly bound with
the mailbox through APIs.
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
>> As for another example of a part of HTTP 1.1 I feel is not RESTful (in my >> mind): the If-Match, If-Modified-Since, If-None-Match, If-Range, and >> If-Unmodified-Since header fields (14.24-28). From my understanding of >> these fields, the client is effectively telling the server how to act. > I'm somewhat inclined to agree with some of this; If-Mod* and If-Unmod* are > probably okay because they are describing what they want in terms > independent of some representation, but the rest presuppose some particular > representation. I have to disagree with this. Those headers are only cache control hints. They specify ETag values that are compared against the ETag values that had been supplied by the server to represent a version of whatever underlying entity is referenced by the URL. They aren't referencing any underlying data in the reponse body (i.e., representation) itself, so the don't presuppose any representation. Also, the response may be handled by a caching proxy without ever hitting the server itself.
Mark Baker wrote:
> Ah, well historically, futures support both poll and notify modes.
> I remember the Expersoft ORB from way-back-when whose Future
interface
> was like this;
>
> interface Future
> {
> getResponseAndBlock()
> registerCallback()
> checkForResponse()
> }
>
> The important feature of a Future was merely to represent the future
> response, not restrict ways in which you'd expect to be able to use
it.
>
> The value of futures, in my experience, was just to simplify client
> code as you didn't always have to worry about threading. So I
rarely
> used them in the way you mentioned, since that required threads to
be
> managed. I almost always just checked for a response.
Would it also be possible to make a Web resource into something like
a future?
The terms in this space are very overloaded, but call it a Commitment
(in the speech act or REA sense, not in the database sense) or a
Promise (related to but not quite the same as the E-Lang creature of
the same name)?
The speech act or REA meaning of Commitment is a promise to perform
an event in the future. When the event occurs, it fulfills the
promise (or doesn't, as the case may be.) A Commitment can have a
time constraint.
The implementation could be similar to Offer-Acceptance: the
Commitment has a URI to which the promisor POSTs the promised event.
-Bob Haugen
On 7/12/02 11:07 AM, "bhaugen32" <bhaugen32@...> wrote: > Would it also be possible to make a Web resource into something like > a future? > > The terms in this space are very overloaded, but call it a Commitment > (in the speech act or REA sense, not in the database sense) or a > Promise (related to but not quite the same as the E-Lang creature of > the same name)? Future and promise both have ample historical precedent. However, the term "thunk" probably has as much precedent in lazy evaluation languages like e.g. SASL. In these languages, a thunk (alt. "suspension") is a pairing of a (possibly complex, nested) expression and an environment for which evaluation is deferred until it is needed / forced. Sort of a parameterless closure. Similar, and worth going back and digging around in the lazy eval lit... Jb
Jeff Bone wrote: > Future and promise both have ample historical precedent. However, the term > "thunk" probably has as much precedent in lazy evaluation languages like > e.g. SASL. In these languages, a thunk (alt. "suspension") is a pairing of > a (possibly complex, nested) expression and an environment for which > evaluation is deferred until it is needed / forced. Sort of a parameterless > closure. > > Similar, and worth going back and digging around in the lazy eval lit... Consider also Elephant: http://www-formal.stanford.edu/jmc/elephant/node17.html
On Fri, Jul 12, 2002 at 04:07:44PM -0000, bhaugen32 wrote: > Would it also be possible to make a Web resource into something like > a future? For sure. I tried to describe that in my last (IIRC) message. > The terms in this space are very overloaded, but call it a Commitment > (in the speech act or REA sense, not in the database sense) or a > Promise (related to but not quite the same as the E-Lang creature of > the same name)? > > The speech act or REA meaning of Commitment is a promise to perform > an event in the future. When the event occurs, it fulfills the > promise (or doesn't, as the case may be.) A Commitment can have a > time constraint. > > The implementation could be similar to Offer-Acceptance: the > Commitment has a URI to which the promisor POSTs the promised event. Yep, it would be really good for that. We need some good APIs for client web *server* integration, so that you can create these mailboxes/futures/promises really easily. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > We need some good APIs for > client web *server* integration, so that you can create these > mailboxes/futures/promises really easily. One thing Dave Winer gets right is that it's good to bootstrap these things. I asked once before, and ask again, is there (preferably light, simple and free) environment that bunch of the correspondents here could agree to use for some code experiments?
Bob Haugen said: > I asked once before, and ask again, is there (preferably light, > simple and free) environment that bunch of the correspondents here > could agree to use for some code experiments? I have found Tomcat pretty hackable, more than Libwww. YMMV. +1 on code experiments. - Lucas
----- Original Message ----- From: "Allan Doyle" <adoyle@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, July 11, 2002 5:21 PM Subject: Re: [rest-discuss] socket-level mods > I may be totally off base here, and would need to do some experiments, > but given that HTTP runs over TCP, isn't it the case that a request > sent to a server can be held by the server nearly indefinitely before > it sends a reply? Yes. > > If so, then one thing I learned from rubbing elbows with the old > CORBUS system at BBN is something called "futures". If a client makes > a request to a server, and that server hangs onto the request while > the client merrily goes on its way, then when the response eventually > comes, the client can treat it as an asynchronous message from the > server. If the server cleverly puts content into the reply, voila, > your client can wake up and deal with it. Yes - this is the 'KnowNow' approach mentioned by Lucas earlier. KnowNow has an HTTP based message server that does exactly this. > > If the TCP connection breaks, or the HTTP server times out and shuts > it down, the client would get a different signal/error. Then client > could then decide whether to send another future request or do > something else. In any case, you are buying time and leaving open a > means for an async notification. > > This would move the problem up one level and you would not have to > muck with HTTP. The only issue is whether the breakage level is too > high, causing overconsumption of resources. Then you do have to work > on some optimizations (potentially even rewriting HTTP). > There isn't any unsurmountable technical problem, the issue that several of us want to deal with is that the response from the server will look to the HTTP world like responses and not as requests. The communication between the server and the client would be a 'private http' protocol - messages initiated by the server appear as if they are merely a single response to a previous request, and this isn't that big a deal for building apps. Longer term there should be more visibility, but I'm all for testing it out and documenting/'standardizing' the approach if it becomes popular.
It's often been claimed that REST applies to all Web protocols, not just HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE into all or most of the other URI (although I suspect just URL) schemes? Cheers, -- Mark Nottingham
I'm looking for references to reading material to help me design a good set of URIs to represent a set of containers and subcontainers. Although I realize that URIs are opaque, I'm trying to have them look reasonable should people see them - the problem I'm having is how to differentiate between "give me a representation of the container", and "give me a represenation of everything inside the container", without having the URIs seem very verbose. Imagine a service that exposes a set of containers. Each container which held interesting data, and one or more subcontainers. Each subcontainer also held some interestesting data. I want to be able to support the following use cases o Get the list of containers in the service (UC1) o Get the data in a container (UC2) o Get a list of the subcontainers in a container (UC3) o Get the data in a subcontainer (UC4) One approach I've been consider is to model "Get the list of containers in the service" as: UC1: GET http://hypothetical.com/service/containers This would return a list of container URIs. These URIs could then be used to "Get the data in a container", like this: UC2: GET http://hypothetical.com/service/containers/1234 This would return the data in the container. One of the data items would be a URI to "Get the list of subcontainers in a container", like this: UC3: GET http://hypothetical.com/service/containers/1234/subcontainers This would return a list of subcontainer URIs. These URIs could then be used to "Get the data in a subcontainer", like this: UC4: GET http://hypothetical.com/service/containers/1234/subcontainers/5678 My concern is that this approach gets pretty verbose. Given that at each level there is only one class of sub-item, I have considered making the containers & subcontainers implicit. This results in a shorter set of URLs than the above four, like this: UC1: GET http://hypothetical.com/service/ UC2: GET http://hypothetical.com/service/1234 UC3: GET http://hypothetical.com/service/1234/ UC4: GET http://hypothetical.com/service/1234/5678 My concern is that the difference between the GETs for UC2 and UC3 seem so trivial to be incorrect/confusing/plain wrong. I'd appreciate any suggestions, comments, required reading or references from the group. Thanks in advance. --Peter
Peter Drayton wrote: > I'm looking for references to reading material to help me design a good > set of URIs to represent a set of containers and subcontainers. Although > I realize that URIs are opaque, I'm trying to have them look reasonable > should people see them - the problem I'm having is how to differentiate > between "give me a representation of the container", and "give me a > represenation of everything inside the container", without having the > URIs seem very verbose. > ... I'm trying to understand what the difference between a container's representation, and the container's representation of its subcontainers, is. I thought they would be the same thing. But perhaps this approach doesn't fit your situation well. Or maybe the container resource should support both? One thing I try to remember is that a URI could point to an entity that doesn't physically exist. In other words, upon receiving a GET request, the server could determine that the URI is logical and maps (in some way only known to the server) to a physical one. So you might initially do a GET /foo, which returns a representation of the server's physical container resource /foo that indicates the relative URI 'containers' would return a list of /foo sub-container representations. Then, you could do a GET /foo/containers and go from there. -Philip
Peter, If you're looking for some references, there's of course Berners-Lee's "Universal Resource Identifiers -- Axioms of Web Architecture" [1] which as a lot of good discussion and references to other articles, some specific to hierarchies. Paul Prescod's short article "Creating an Extreme Web Service in N Easy Steps" [2] might shed some light on this. I found it interesting anyway... Personally, I think the way to go is similar to what you've already outlined with a couple of changes: The initial list of containers as you have (although I think the "service" is implied so I dropped that): UC1: http://hypothetical.com/containers The list of URIs in the returned document uses the singular "container", so UC2: http://hypothetical.com/container/1234 Could return the xml document with a URI to it's subcontainer as you have: UC3: http://hypothetical.com/container/1234/subcontainer From there though, I don't see that you need to necessarily show the entire hierarchy, i.e., dereferencing UC3 returns a list of URIs of the form: UC4: http://hypothetical.com/subcontainer/5678 ... and so one down the tree. Perhaps if your model was really a graph (multiple parents) you might need to show the full chain but I haven't really thought through the implications of that. Creating a new subcontainer would be accomplished with, a POST to UC3, and the new URI returned in the Location header of the HTTP 201 response. Prescod also has some thoughts on doing this reliably [3]. Actually, just go ahead and read all his stuff [4]. As for making the containers and subcontainers implicit in the URI, unless your underlying data model is trivial, you would need something to key on in order to reasonably obtain the entity's representation. For example, suppose instead of container/subcontainer you had book/chapters and book/authors (two subcontainers); if you only had /service/1234/5678, how would you know if "5678" referred to a chapter or an author? What table would you look in if this happened to be sitting on top of a relational database? You'd be better off using: UC5: http://hypothetical.com/book/1234/chapter/5678 or better yet: UC6: http://hypothetical.com/chapter/5678 I find this an interesting subject, and if I'm off base anywhere I'd like to hear about it! Thanks, - Jeff [1] http://www.w3.org/DesignIssues/Axioms.html [2] http://www.prescod.net/rest/Steps_to_extreme.html [3] http://www.prescod.net/reliable_http.html [4] http://www.prescod.net/rest/ ----- Original Message ----- From: "Peter Drayton" <peter@...> To: <rest-discuss@yahoogroups.com> Sent: Saturday, July 13, 2002 6:13 PM Subject: [rest-discuss] URI design question > I'm looking for references to reading material to help me design a good > set of URIs to represent a set of containers and subcontainers. Although > I realize that URIs are opaque, I'm trying to have them look reasonable > should people see them - the problem I'm having is how to differentiate > between "give me a representation of the container", and "give me a > represenation of everything inside the container", without having the > URIs seem very verbose. > > Imagine a service that exposes a set of containers. Each container which > held interesting data, and one or more subcontainers. Each subcontainer > also held some interestesting data. I want to be able to support the > following use cases > o Get the list of containers in the service (UC1) > o Get the data in a container (UC2) > o Get a list of the subcontainers in a container (UC3) > o Get the data in a subcontainer (UC4) > > One approach I've been consider is to model "Get the list of containers > in the service" as: > UC1: GET http://hypothetical.com/service/containers > This would return a list of container URIs. These URIs could then be > used to "Get the data in a container", like this: > UC2: GET http://hypothetical.com/service/containers/1234 > This would return the data in the container. One of the data items would > be a URI to "Get the list of subcontainers in a container", like this: > UC3: GET http://hypothetical.com/service/containers/1234/subcontainers > This would return a list of subcontainer URIs. These URIs could then be > used to "Get the data in a subcontainer", like this: > UC4: GET > http://hypothetical.com/service/containers/1234/subcontainers/5678 > > My concern is that this approach gets pretty verbose. Given that at each > level there is only one class of sub-item, I have considered making the > containers & subcontainers implicit. This results in a shorter set of > URLs than the above four, like this: > UC1: GET http://hypothetical.com/service/ > UC2: GET http://hypothetical.com/service/1234 > UC3: GET http://hypothetical.com/service/1234/ > UC4: GET http://hypothetical.com/service/1234/5678 > > My concern is that the difference between the GETs for UC2 and UC3 seem > so trivial to be incorrect/confusing/plain wrong. > > I'd appreciate any suggestions, comments, required reading or references > from the group. Thanks in advance. > > --Peter > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
Philip Eskelin wrote: > > Peter Drayton wrote: > > I'm looking for references to reading material to help me design > > a good set of URIs to represent a set of containers and > > subcontainers. Although I realize that URIs are opaque, I'm > > trying to have them look reasonable should people see them - > > the problem I'm having is how to differentiate between "give me > > a representation of the container", and "give me a represenation > > of everything inside the container", without having the URIs > > seem very verbose. > > I'm trying to understand what the difference between a container's > representation, and the container's representation of its > subcontainers, is. I > thought they would be the same thing. But perhaps this > approach doesn't fit > your situation well. Or maybe the container resource should > support both? I'm actually working on a couple of different cases of this. One of them is where I have accounts (which have account data) that contain 0..n identities (which have identity data). Another is where I have test suites (with associated data) that have sets of client results (with result data) and server implementations (with endpoint information). The latter example doesn't fit my post 100%, since the container has 2 different classes of subcontainers. In this case I need to retain the subcontainerX/ in the URI, to distinguish which subcontainer I'm going for. The former, OTOH, fits quite well. Should my URIs be ( removed for brevity): UC1: GET http://hypothetical.com/service/accounts UC2: GET http://hypothetical.com/service/accounts/1234 UC3: GET http://hypothetical.com/service/accounts/1234/identities UC4: GET http://hypothetical.com/service/accounts/1234/identities/5678 or UC1: GET http://hypothetical.com/service/ UC2: GET http://hypothetical.com/service/1234 UC3: GET http://hypothetical.com/service/1234/ UC4: GET http://hypothetical.com/service/1234/5678 Obviously, only works if the tree has only one subcontainer at each level. > One thing I try to remember is that a URI could point to an > entity that doesn't physically exist. In other words, upon > receiving a GET request, the server could determine that the > URI is logical and maps (in some way only known to the > server) to a physical one. > > So you might initially do a GET /foo, which returns a > representation of the > server's physical container resource /foo that indicates the > relative URI > 'containers' would return a list of /foo sub-container > representations. Then, > you could do a GET /foo/containers and go from there. Understood, in my current design to get the data in a container (UC2) I do a GET http://hypothetical.com/service/container/1234/ which returns this: <Container xmlns="http://hypothetical.com/example" xmlns:x="http://www.w3.org/1999/xlink"> <ContainerData1>...</ContainerData1> ... <ContainerDataN>...</ContainerDataN> <Subcontainers x:href="subcontainers/"/> </Container> Chasing the Subcontainers link to get the list of subcontainers in a container (UC3), I do a GET http://hypothetical.com/service/container/1234/subcontainers/ which return this: <?xml version="1.0"?> <Subcontainers xmlns="http://hypothetical.com/example" xmlns:x="http://www.w3.org/1999/xlink"> <Subcontainer x:href="1234/"/> <Subcontainer x:href="5678/"/> </Container> Then going after subcontainer 5678 to get the data in the subcontainer (UC4), I do a GET on http://hypothetical.com/service/container/1234/subcontainers/5678/, which returns this: <Subcontainer xmlns="http://hypothetical.com/example" xmlns:x="http://www.w3.org/1999/xlink"> <SubcontainerData1>...</SubcontainerData1> ... <SubcontainerDataN>...</SubcontainerDataN> </Container> My concern was that these URIs get long, especially when you have several level of this pattern repeating itself. --Peter http://www.razorsoft.net/weblog
At 08:13 AM 14/07/2002, Peter Drayton wrote: >I'm looking for references to reading material to help me design a good >set of URIs to represent a set of containers and subcontainers. Although >I realize that URIs are opaque, I'm trying to have them look reasonable >should people see them - the problem I'm having is how to differentiate >between "give me a representation of the container", and "give me a >represenation of everything inside the container", without having the >URIs seem very verbose. You might find 'Resource Modeling and Names' (http://internet.conveyor.com/RESTwiki/moin.cgi/ResourceModelingAndNames) of use, particularly the use of a grammar to model a hierarchical collection of resources. Also : 'Opacity Myths Debunked' (http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityMythsDebunked) 'Opacity Reconsidered' (http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityReconsidered) 'Opacity Reconsidered Reconsidered' (http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityReconsideredReconsidered) 'Naming Isn't Navigating' (http://internet.conveyor.com/RESTwiki/moin.cgi/NamingIsntNavigating) Mark Bakers' 'An Investigation into the Opacity Properties of RFC 2396' (http://www.markbaker.ca/2002/01/UriOpacityInvestigation/) and of course the definitive source on REST, Fieldings' dissertation, in particular Section 6.2 'REST Applied to URI' (http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2). The forces at play here appear to be : Opacity - the URI should be opaque to all but the implementor Identity - a URI is by definition an identifier of a resource and that identity should be useful as an indicator of the semantics of the resource Maintainability - the URI set should be maintainable by the implementor Reliability - the URI set should remain as unchanged as possible for as long as possible and (somewhat dubiously) Discovery - it may be useful for clients (both human and machine) to utilize the nature and relationship between URIs' to discover other resources Depending on your situation one or more of these forces might influence the end result more than the others. In general it seems best practice not to reflect your resource *model* (i.e. relationships) directly in the URI and as Paul says in 'Common REST mistakes' (http://www.prescod.net/rest/mistakes/) "In other words, your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service. Those components would have hyperlinks that point to other components and so forth. Then you can introduce people to your service with a single URI and you can distribute the actual components across computers and domains however you want." HTH Robert
Mark Nottingham wrote: > > It's often been claimed that REST applies to all Web protocols, not just > HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE into > all or most of the other URI (although I suspect just URL) schemes? Here is my interpretation of the claims that have been made: the REST model is appropriate to solving all of the same problems that other Internet application protocols solve. In other words email (for example) could benefit from REST discipline and could use HTTP across the wire. If that's what you're asking about then here's one preliminary mapping I've done for email: * http://www.prescod.net/rest/restmail/ I would not say that "REST applies to all Web protocols." For one thing, I don't have a clear definition of "Web protocol." Arguably HTTP is the only widely deployed protocol that knows about "the Web" and has been adopted by the W3C as a core technology. (One could argue that SOAP fits too and it would probably be simpler to agree to disagree rather than attempt to establish a test of Web-ness) I certainly do not think of SMTP as either guided by REST or based upon the Web. "For example, the Web's primary transfer protocol is HTTP, but the architecture also includes seamless access to resources that originate on pre-existing network servers, including FTP [107], Gopher [7], and WAIS [36]. Interaction with those services is restricted to the semantics of a REST connector. This constraint sacrifices some of the advantages of other architectures, such as the stateful interaction of a relevance feedback protocol like WAIS, in order to retain the advantages of a single, generic interface for connector semantics." "If an application needs the additional capabilities of another architecture, it can implement and invoke those capabilities as a separate system running in parallel, similar to how the Web architecture interfaces with "telnet" and "mailto" resources." * http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Peter Drayton wrote: > > I'm looking for references to reading material to help me design a good > set of URIs to represent a set of containers and subcontainers. Although > I realize that URIs are opaque, I'm trying to have them look reasonable > should people see them - the problem I'm having is how to differentiate > between "give me a representation of the container", and "give me a > represenation of everything inside the container", without having the > URIs seem very verbose. Well GET should certainly be used for "representation of the container." The other thing could either be an "associated URI" or a query (which is just an associated URI that is "extensible" by the client). > One approach I've been consider is to model "Get the list of containers > in the service" as: > UC1: GET http://hypothetical.com/service/containers Great. > This would return a list of container URIs. These URIs could then be > used to "Get the data in a container", like this: > UC2: GET http://hypothetical.com/service/containers/1234 Great. > This would return the data in the container. One of the data items would > be a URI to "Get the list of subcontainers in a container", like this: > UC3: GET http://hypothetical.com/service/containers/1234/subcontainers Is there any deep reason not to combine the information here with the information above? > This would return a list of subcontainer URIs. These URIs could then be > used to "Get the data in a subcontainer", like this: > UC4: GET > http://hypothetical.com/service/containers/1234/subcontainers/5678 Great. But I would suggest that this one would be just as good: http://hypothetical.com/service/containers/1234/5678 5678 is logically a child of /1234, not of its "subcontainer index." And it solves your verbosity problem. > My concern is that this approach gets pretty verbose. Given that at each > level there is only one class of sub-item, I have considered making the > containers & subcontainers implicit. This results in a shorter set of > URLs than the above four, like this: > UC1: GET http://hypothetical.com/service/ > UC2: GET http://hypothetical.com/service/1234 > UC3: GET http://hypothetical.com/service/1234/ It's only UC2 and UC3 that I dislike. Change UC3 to /1234/subcontainers and I think you are set. > UC4: GET http://hypothetical.com/service/1234/5678 > > My concern is that the difference between the GETs for UC2 and UC3 seem > so trivial to be incorrect/confusing/plain wrong. > > I'd appreciate any suggestions, comments, required reading or references > from the group. Thanks in advance. Think of "subcontainers" as "index.html". It's just an index and doesn't need to have children of its own. Or it could be merged with the "other content" for the resource so that one GET gives you everything. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > >> As for another example of a part of HTTP 1.1 I feel is not RESTful (in my > >> mind): the If-Match, If-Modified-Since, If-None-Match, If-Range, and > >> If-Unmodified-Since header fields (14.24-28). From my understanding of > >> these fields, the client is effectively telling the server how to act. > > > I'm somewhat inclined to agree with some of this; If-Mod* and If-Unmod* > are > > probably okay because they are describing what they want in terms > > independent of some representation, but the rest presuppose some > particular > > representation. > > I have to disagree with this. Those headers are only cache control hints. > They specify ETag values that are compared against the ETag values that had > been supplied by the server to represent a version of whatever underlying > entity is referenced by the URL. They aren't referencing any underlying > data in the reponse body (i.e., representation) itself, so the don't > presuppose any representation. > I also disagree - the ETag based headers seem to be defined on resources, not representations.
We were discussing recently how it has become popular to describe XML vocabularies in terms of the infoset instead of the XML syntax. That got me to thinking: SOAP does not specify any message-exchange patterns. It mandate extremely "loose" semantics. So you're allowed arbitrary syntax and arbitrary semantics: what sort of protocol does not conform to the SOAP model? -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
I've been thinking about how to implement a Queue with HTTP. I'm not interested in uber-efficiency, just the requirement of one and only one consumer of a message. I've got two approaches to model the queue - a visible (i.e. list-able) collection of messages and as a 'head' or 'next' message. I'm not sure the 'head' approach will work. a) Visible collection A client lists the messages and tries to process them one at a time. Tricky clients can use some sort of hashing algorithm to avoid collisions with other clients, but I'm not concerned with that. But how do the clients actually 'take' a message? 1 New method - TAKE Somebody mentioned a while back a tuple-space system that had a 'take' operation - which sounds about what is needed for a queue. But I don't like this approach. 2 lock a message with PUT The listing of pending messages includes a URI for each message and a URI for a 'lock' for a message. The client does a conditional PUT that succeeds only if the lock resource doesn't already exist (something like if-none-match: * or maybe if-not-modified-since) 3 remove message from queue with DELETE The listing provides URIs which represent /links/ to messages which have URIs independent of being part of a queue. The client removed the message from the queue by doing a DELETE on the URI for the 'message in outbox' resource. It then is free to get the message (as is anybody else, like for audits, referencing, etc.). 4 others... Any others? It's interesting that #2 and #3 use two URIs for each message, but different methods. I guess the difference is #2 says "PUT the status of 'not in queue'" and #3 says "DELETE from queue". I think I llike #2 better since it depends on the value of a resource, rather than the existence of a resource.
Paul Prescod wrote: > what sort of protocol does not conform to the > SOAP model? You mentioned EDI in the subject line. Did you mean to suggest that EDI does not conform to the SOAP model? "EDI" means lots of things to lots of people. If you mean traditional EDI - ANSI X12 and EDIFACT - then: 1. The documents exchanged are not XML, but people have converted the EDI formats to XML, without much takeup. 2. The most common message exchange pattern for traditional EDI is batch over a VAN, that is, possible very large batches of documents being sent periodically, often weekly. Not very SOAPy. Or RESTful, either. 3. Some people are gravitating to a conversational-style EDI, still using the old document formats. 4. If you consider RosettaNet and ebXML to be the "next generation of EDI" (I do), then RNet is a lot like "message-oriented" SOAP, and ebXML is exactly SOAP with a lot of business extensions for state- alighnment transactions, security, etc. ebXML allows people to use traditional EDI document formats with SOAP "transport". Does that speak to your combination of subject line and question at all? It has been my contention on this list that ebXML state-alignment transactions would actually work better with REST than SOAP, but that seems like a different topic. -Bob Haugen
----- Original Message ----- From: "JulianReschke" <julian.reschke@...> > > Maybe this is too obvious... > > How about using LOCK (RFC2518) to lock the message? I hadn't thought of that... I'm not too sure I want to bring in all the DAV stuff though. Using LOCK would be the more standards-compliant approach though.
Mike Dierken wrote: > I've been thinking about how to implement a Queue with HTTP. I'm not > interested in uber-efficiency, just the requirement of one and only one > consumer of a message. > > I've got two approaches to model the queue - a visible (i.e. list-able) > collection of messages and as a 'head' or 'next' message. I'm not sure the > 'head' approach will work. Actually, this is a good problem to explore, because I it gives me a strong urge to model the solution with verbs. It's most certainly not a good idea to transfer a representation of the entire queue, modify it, and transfer it back. There must be a protocol for queue interaction that is RESTful. How about this approach: 1. A 'POST /myqueue' to enqueue a message representation. The entity is treated as a subordinate to the '/myqueue' queue resource. 2. A 'DELETE /myqueue/head' to dequeue a representation of the first message in the queue. The entity returned is a representation of the removed message. 3. A 'GET /myqueue' transfers a representation of the queue resource. This would have a list of URIs identifying each message in the queue. 4. A 'GET /myqueue/messages/123' transfers a represenation of a message resource. There doesn't seem to be any need for locking. Is this consistent with what you would need, or am I missing an issue or requirement that might make this approach invalid? -Philip
At 09:23 AM 15/07/2002, Philip Eskelin wrote: >Mike Dierken wrote: > > I've been thinking about how to implement a Queue with HTTP. I'm not > > interested in uber-efficiency, just the requirement of one and only one > > consumer of a message. > > > > I've got two approaches to model the queue - a visible (i.e. list-able) > > collection of messages and as a 'head' or 'next' message. I'm not sure the > > 'head' approach will work. > >Actually, this is a good problem to explore, because I it gives me a >strong urge >to model the solution with verbs. It's most certainly not a good idea to >transfer a representation of the entire queue, modify it, and transfer it >back. >There must be a protocol for queue interaction that is RESTful. How about >this >approach: > >1. A 'POST /myqueue' to enqueue a message representation. The entity > is treated as a subordinate to the '/myqueue' queue resource. >2. A 'DELETE /myqueue/head' to dequeue a representation of the first > message in the queue. The entity returned is a representation > of the removed message. The only problem with this is that DELETE is supposed to be idempotent . - from RFC2612 "in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request" and "Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD,PUT and DELETE share this property." I think I am leaning towards Mike's original suggestion - 3 remove message from queue with DELETE. Robert
I asked because of Mark's claims [1]. Granted, he only claims GET is universal, not other RESTful methods. 1. http://lists.w3.org/Archives/Public/www-tag/2002Jul/0136.html ----- Original Message ----- From: "Paul Prescod" <paul@...> To: "Mark Nottingham" <mnot@...>; <rest-discuss@yahoogroups.com> Sent: Saturday, July 13, 2002 8:10 PM Subject: Re: [rest-discuss] REST and non-HTTP protocols > Mark Nottingham wrote: > > > > It's often been claimed that REST applies to all Web protocols, not just > > HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE into > > all or most of the other URI (although I suspect just URL) schemes? > > Here is my interpretation of the claims that have been made: the REST > model is appropriate to solving all of the same problems that other > Internet application protocols solve. In other words email (for example) > could benefit from REST discipline and could use HTTP across the wire. > If that's what you're asking about then here's one preliminary mapping > I've done for email: > > * http://www.prescod.net/rest/restmail/ > > I would not say that "REST applies to all Web protocols." For one thing, > I don't have a clear definition of "Web protocol." Arguably HTTP is the > only widely deployed protocol that knows about "the Web" and has been > adopted by the W3C as a core technology. (One could argue that SOAP fits > too and it would probably be simpler to agree to disagree rather than > attempt to establish a test of Web-ness) > > I certainly do not think of SMTP as either guided by REST or based upon > the Web. > > "For example, the Web's primary transfer protocol is HTTP, but the > architecture also includes seamless access to resources that originate > on pre-existing network servers, including FTP [107], Gopher [7], and > WAIS [36]. Interaction with those services is restricted to the > semantics of a REST connector. This constraint sacrifices some of the > advantages of other architectures, such as the stateful interaction of a > relevance feedback protocol like WAIS, in order to retain the advantages > of a single, generic interface for connector semantics." > > "If an application needs the additional capabilities of another > architecture, it can implement and invoke those capabilities as a > separate system running in parallel, similar to how the Web architecture > interfaces with "telnet" and "mailto" resources." > > * > http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm > -- > Come discuss XML and REST web services at: > Open Source Conference: July 22-26, 2002, conferences.oreillynet.com > Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/ >
On Sat, Jul 13, 2002 at 09:49:47PM -0700, Paul Prescod wrote: > We were discussing recently how it has become popular to describe XML > vocabularies in terms of the infoset instead of the XML syntax. That got > me to thinking: SOAP does not specify any message-exchange patterns. It > mandate extremely "loose" semantics. So you're allowed arbitrary syntax > and arbitrary semantics: what sort of protocol does not conform to the > SOAP model? Telnet's my canonical example. Sure, you could wrap "a" in a SOAP envelope, but the increased latency in transmitting and processing it would make it suck. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Robert wrote: > I think I am leaning towards Mike's original suggestion - 3 remove > message from queue with DELETE. I'm not sure I totally understood Mike's description. I read the DELETE description in RFC 2616, and I did see that the returned entity should be a description of the results, but didn't really acknowledge that it needed to be idempotent. Very good point. But what did Mike mean by "doing a DELETE on the URI for the 'message in outbox' resource"? It doesn't sound idempotent the way I read it. -Philip
On Sun, Jul 14, 2002 at 05:44:32PM -0700, Mark Nottingham wrote: > I asked because of Mark's claims [1]. Granted, he only claims GET is > universal, not other RESTful methods. All HTTP methods are "universal" (in that they apply to all resources). I was just responding to Joshua's statement that GET was only relevant for http scheme URIs. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
At 11:17 AM 15/07/2002, Philip Eskelin wrote:
>Robert wrote:
> > I think I am leaning towards Mike's original suggestion - 3 remove
> > message from queue with DELETE.
>
>But what did Mike mean by "doing a DELETE on the URI for the 'message in
>outbox'
>resource"? It doesn't sound idempotent the way I read it.
The reference to outbox made me think of Pauls description of the REST
implementation of email (http://www.prescod.net/rest/restmail/), so I'm
assuming something like the following:
A 'GET /myqueue' transfers a representation of the queue resource. This
would have a list of URIs identifying each queue entry e.g.
<queue>
<queue_entry href='/myqueue/1'/>
<queue_entry href='/myqueue/2'/>
...
<queue_entry href='/myqueue/n'/>
</queue>
A GET on a queue entry ('myqueue/2') returns reference to a queue entry, the
contents of which would depend on how restrictive the queue needs to be,
e.g. if it is ok for others to discover the end message then it would return
something like:
<queue_entry message_href='/uri/to/real/message'/>
but if you want one and only one consumer to discover the message it might
return an empty entry and only return the message URI on a successful DELETE.
A DELETE on a queue entry does the obvious and removes the message from the
queue, returning the queue entry or message URI as a description of the
result, unless of course someone else has pulled the entry from the queue,
in which case it returns the appropriate status code (404?)
Robert
Robert,
I understand now - thanks for clarifying. Maybe I should have read Paul's
restmail page more closely. One of the things I need to finish in my toolkit is
a queue implementation, so I'll make sure I build it to this specification.
-Philip
Robert wrote:
> At 11:17 AM 15/07/2002, Philip Eskelin wrote:
> >Robert wrote:
> > > I think I am leaning towards Mike's original suggestion - 3 remove
> > > message from queue with DELETE.
> >
> >But what did Mike mean by "doing a DELETE on the URI for the
> 'message in
> >outbox'
> >resource"? It doesn't sound idempotent the way I read it.
>
> The reference to outbox made me think of Pauls description of the REST
> implementation of email
> (http://www.prescod.net/rest/restmail/), so I'm
> assuming something like the following:
>
> A 'GET /myqueue' transfers a representation of the queue
> resource. This
> would have a list of URIs identifying each queue entry e.g.
>
> <queue>
> <queue_entry href='/myqueue/1'/>
> <queue_entry href='/myqueue/2'/>
> ...
> <queue_entry href='/myqueue/n'/>
> </queue>
>
> A GET on a queue entry ('myqueue/2') returns reference to a
> queue entry, the
> contents of which would depend on how restrictive the queue
> needs to be,
> e.g. if it is ok for others to discover the end message then
> it would return
> something like:
>
> <queue_entry message_href='/uri/to/real/message'/>
>
> but if you want one and only one consumer to discover the
> message it might
> return an empty entry and only return the message URI on a
> successful DELETE.
>
> A DELETE on a queue entry does the obvious and removes the
> message from the
> queue, returning the queue entry or message URI as a
> description of the
> result, unless of course someone else has pulled the entry
> from the queue,
> in which case it returns the appropriate status code (404?)
>
> Robert
>
>
Mark Nottingham wrote: > > I asked because of Mark's claims [1]. Granted, he only claims GET is > universal, not other RESTful methods. > > 1. http://lists.w3.org/Archives/Public/www-tag/2002Jul/0136.html Mark wasn't saying that REST methods apply to all protocols. He was saying they apply to all URIs. i.e. GET mailto:paul@... HTTP/1.1 -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
"S. Mike Dierken" wrote: >... > 2 lock a message with PUT > The listing of pending messages includes a URI for each message and a URI > for a 'lock' for a message. The client does a conditional PUT that succeeds > only if the lock resource doesn't already exist (something like > if-none-match: * or maybe if-not-modified-since) That's my favorite. Perhaps combined with WebDAV LOCK. > 3 remove message from queue with DELETE > The listing provides URIs which represent /links/ to messages which have > URIs independent of being part of a queue. The client removed the message > from the queue by doing a DELETE on the URI for the 'message in outbox' > resource. It then is free to get the message (as is anybody else, like for > audits, referencing, etc.). I don't think this is safe. Two clients could DELETE at the same time and both of the return messages could be lost. Then nobody knows who is responsible for dealing with that message. A conditional PUT or POST allows clients to "mark" the message (e.g. with a UUID or signature) to say: "I'm in charge of this." Then they can deal with it at their leisure. The conditionality can allow the server to ensure that there is no race condition. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
At 03:56 PM 15/07/2002, Philip Eskelin wrote: >One of the things I need to finish in my toolkit is >a queue implementation, so I'll make sure I build it to this specification. Well, you might want to wait until a REST guru gives it the ok, I am still a neophyte :-) Robert
bhaugen32 wrote: > > Paul Prescod wrote: > > what sort of protocol does not conform to the > > SOAP model? > > You mentioned EDI in the subject line. > Did you mean to suggest that EDI does not conform to the SOAP model? The opposite. I mean to point out that SOAP makes no syntactic demands on protocols and almost no semantic ones. I believe that SOAP is sufficiently "flexible" that ANSI X12 are *already legal SOAP messages*. This is in contrast to REST which is much more prescriptive. >.... > 1. The documents exchanged are not XML, but people have converted the > EDI formats to XML, without much takeup. Sure, but SOAP messages do not have to be XML, according to the SOAP specification. > 2. The most common message exchange pattern for traditional EDI is > batch over a VAN, that is, possible very large batches of documents > being sent periodically, often weekly. Not very SOAPy. Or RESTful, > either. But SOAP explicitly supports any message exchange pattern. Does that clarify the question? I'm asking if SOAP is *so* flexibly descriptive (rather than prescriptive) that any arbitrary pre-existing protocol can be declared "SOAP compliant" without any change. Probably few people would be silly enough to do this (but who can see the future) but even if not, it seems to me to exemplify the opposite attidudes of the REST literature versus the SOAP model. REST expresses constraints on components and messages. SOAP seems designed to express as few constraints as possible. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > 3 remove message from queue with DELETE > > The listing provides URIs which represent /links/ to messages which have > > URIs independent of being part of a queue. The client removed the message > > from the queue by doing a DELETE on the URI for the 'message in outbox' > > resource. It then is free to get the message (as is anybody else, like for > > audits, referencing, etc.). > > I don't think this is safe. Two clients could DELETE at the same time > and both of the return messages could be lost. Then nobody knows who is > responsible for dealing with that message. Very good point. I'd forgotten to consider lost responses. > A conditional PUT or POST > allows clients to "mark" the message (e.g. with a UUID or signature) to > say: "I'm in charge of this." Then they can deal with it at their > leisure. The return message from a PUT can be lost just as much as a return message from a DELETE . But I do like the PUT, since client information can be saved by the server, and so a lost response isn't that critical - a client will eventually re-discover the state of the queue and notice that /it/ is responsible for a message - even though it never got the response. But this means clients need to know their IDs & it better be 'globally unique' for some degree of 'global'. Perhaps the server can hand out tokens to any client that asks for a message and the first client that successfully puts one of them back wins. Each time a client does a GET on the 'message-in-queue' resource a new token is generated (i know i know 'non-idempotent get', blah blah blah, i can't hear you....). The client saves that and confirms back to the server - it then has either a success response, fail response, or null response. It processes the message if a success response, drops the message on a fail response and re-tries later on the null response. This approach has the server control the id's and the clients don't need id's. > The conditionality can allow the server to ensure that there is > no race condition. I don't think the DELETE would cause a race condition any more than a conditional PUT, the origin server would be responsible for ensuring only one request is successful in either case.
We look forward to sharing exciting ideas and methods with you to help you earn more money, and have more free time and enjoyment in your work than you ever thought possible.
Sincerely,
Richard McGuire
If you would like to be removed from our database, click here.
On 14 Jul 2002 at 23:14, Paul Prescod wrote: > > SOAP seems designed to express as few constraints > as possible. Actually, SOAP 1.2 constrains XML by defining a new infoset that is incompatible with the XML infoset. XML purists could use this to claim that SOAP is not XML, but that leads us into a rather ugly (and pointless) debate.... On another topic, you mentioned that SOAP does not specify any message-exchange patterns. SOAP 1.2 defines Message Exchange Patterns (MEPs). MEPs are templates that define patterns for the exchange of messages between SOAP nodes. Part 2 of the SOAP 1.2 spec describes the MEPs provided with SOAP [1]. One of these appears to be somewhat similar to REST (based on my rather limited knowledge of REST) [2]. [1] http://www.w3.org/TR/soap12-part2/#soapsupmep [2] http://www.w3.org/TR/soap12-part2/#WebMethodFeature
I am interested in the collective thoughts of the group on the best approach to defining xml representations. Given the proliferation of standards across various areas, not to mention within those areas as well, I wonder what the most prudent approach to take is? The issues (for me at least) are: 1. Multiple standards for the same domain - how do you choose ? Should you try and choose something that answers 2 (below) first and let that determine the answer here ? 2. No standards for the domain - what is the best way to define your own ? Do you choose a component--oriented base standard such as xCBL or OAGIS and build your implementation on top of that or reinvent the wheel completely and implement everything from scratch.? If it is the first option then what is the best component-oriented standard? 3. Where does the Semantic Web/RDF/DAML/etc fit in? AFAICT none of the existing standards are implemented using this approach. Robert
Robert Leftwich wrote: > 3. Where does the Semantic Web/RDF/DAML/etc fit in? AFAICT none of the > existing standards are implemented using this approach. Robert, I don't know what kind of standards you want, but: There is a set of "Business Entity" standards being developed in UN/CEFACT that I think would be a good basis for a suite of business- oriented REST resources. An RDF representation is in the works. Here's the latest draft: http://www.collaborativedomain.com/standards/documents/BET%20Draft% 20Technical%20Specification_v008.zip You can watch for further developments at: http://www.collaborativedomain.com/standards/ UN/CEFACT grinds exceedingly slow, but the work is free for use. It's one of those cases of a verbose and seemingly complex spec with a terse and simple one wanting to get out. Disclaimer: I was involved heavily at one point.
At 10:54 AM 17/07/2002, bhaugen32 wrote: >Robert, I don't know what kind of standards you want, but: As usual, I probably ended up being too general in my earlier email. At this point in time I am looking to build a list of (preferably) component-oriented standards for further investigation into their use as the basis for REST representations. I don't as yet have any specific requirements for a particular domain, but as an example, the components in HR-XML [1] (postal address, person name, contact info, etc) are a good starting point.. Of course, it may be that none of these standards are sufficiently well advanced to be of real, practical use in the near term (2-3 months), in which case I might need to take the build it from scratch approach. My biggest fear is that betting on the wrong standard could be disastrous in the longer term. >... >Here's the latest draft: >http://www.collaborativedomain.com/standards/documents/BET%20Draft% >20Technical%20Specification_v008.zip >... Thanks. >UN/CEFACT grinds exceedingly slow, but the work is free for use. The slowness may be an issue - any thoughts on how you can position your product to take advantage of this work when it is finalized? >It's one of those cases of a verbose and seemingly complex spec with >a terse and simple one wanting to get out. So when is the terse and simple one coming out :-) I'm a big fan of terse and simple ! >Disclaimer: I was involved heavily at one point. Good - its look like I may need an interpreter if I pursue it :-/ Robert [1] http://www.hr-xml.org (registration required to download)
Amazon has both HTTP+XML and SOAP. I downloaded the sdk & one of the references is the RESTwiki --- good job guys! I think you've made a difference... ----- Original Message ----- From: "Ben Parker" <ben@...> To: <syndication@yahoogroups.com> Sent: Wednesday, July 17, 2002 7:50 AM Subject: [syndication] Amazon does SOAP > > From the Amazon affiliates newsletter: > > "Build your own Amazon.com Product Detail Page > > ...with Amazon.com Web Services! Powered by XML, this new platform > enables you to display dynamic product information and our best > merchandising features (Customer Reviews, Customers Also Bought, Add to > Shopping Cart, and more). Some software development skills are required > to use this service but help can be found on our Developers Discussion > Board. Some developers even post applications to help you get started. > Don't have time to build an XML powered feature yourself? Send your > ideas to webservices@.... ... > > We at Amazon.com want to see Web services work. We believe they are > important to the future of the Internet. To help stimulate Web service > innovation, we now offer software developers the opportunity to > integrate Amazon.com features and content directly into other web sites > using either SOAP or XML over HTTP. Partner with the leader in > e-commerce and join the Web services revolution today! > > Go to www.amazon.com/webservices here! " > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
I met these guys briefly at ETCON. Jeff Bezos was there. All week I resisted introducing myself because I figured what was the point, he would not be interested in seemingly tiny details like REST v. SOAP. But then when I met the Amazon implementors they said that they *had* discussed the issue with Jeff! Doh! I did a webex web presentation for a huge publishing conglomerate and they are very interested in REST. Also, I can't remember if I forwarded the URL for the CIO of the State of Utah? http://www.windley.com/2002/07/03.html The current SOAP specification says that the Google model was bad form so it should only be a matter of time before we can count them as REST-y also. I am also working with Laird Popkin of the ICE consortium. Even before I told him about REST they had been thinking about an HTTP-GET modality for ICE to allow RSS-like usage modes. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
I'm curious. The Amazon interface supports HTTP/URL requests with XML
returned data and some folks here refer to it as being a REST interface.
On the other hand, I've been seeing a lot of postings here and on XML-DEV
about strict adherence to the REST URL scheme (i.e.
http://.../search/isbn/123456789 vs. http://.../search?isbn=123456789).
It seems to me that as long as the service has an HTTP/URL interface vs.
SOAP packets, some folks might consider it as REST. But if you stick with
the strict URL adherence/naming scheme, neither Google nor Amazon are
strictly REST-compliant...
Any thoughts?
Best,
Ramin
---
Ramin Firoozye - Wizen Software
-----Original Message-----
From: Paul Prescod [mailto:paul@...]
Sent: Wednesday, July 17, 2002 5:46 PM
To: S. Mike Dierken; rest-discuss@yahoogroups.com
Subject: [rest-discuss] REST breaking out all over
I met these guys briefly at ETCON. Jeff Bezos was there. All week I
resisted introducing myself because I figured what was the point, he
would not be interested in seemingly tiny details like REST v. SOAP. But
then when I met the Amazon implementors they said that they *had*
discussed the issue with Jeff! Doh!
I did a webex web presentation for a huge publishing conglomerate and
they are very interested in REST. Also, I can't remember if I forwarded
the URL for the CIO of the State of Utah?
http://www.windley.com/2002/07/03.html
The current SOAP specification says that the Google model was bad form
so it should only be a matter of time before we can count them as REST-y
also.
I am also working with Laird Popkin of the ICE consortium. Even before I
told him about REST they had been thinking about an HTTP-GET modality
for ICE to allow RSS-like usage modes.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> I'm curious. The Amazon interface supports HTTP/URL requests with > XML returned data and some folks here refer to it as being a REST > interface. > > On the other hand, I've been seeing a lot of postings here and > on XML-DEV about strict adherence to the REST URL scheme (i.e. > http://.../search/isbn/123456789 vs. > http://.../search?isbn=123456789). No, actually it is strictly REST. If the client needs to generate a URI using information only known to the client (like an ISBN number or a date) then the URI should use a query string. But even if it wasn't strictly REST-y, I wouldn't fuss too much about the construction of URIs because in the web architecture URIs are typically opaque. > It seems to me that as long as the service has an HTTP/URL interface > vs. SOAP packets, some folks might consider it as REST. But if > you stick with the strict URL adherence/naming scheme, neither > Google nor Amazon are strictly REST-compliant... Some pure-HTTP services are very un-REST. * http://www.prescod.net/rest/mistakes/ But Amazon does not have this problem. During ETCON someone implied that they were using GET for things other than queries but I don't see anything about that. They use POST for mutations which is good. And the XSLT service looks really cool. Good work! -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
> -----Original Message----- > From: Paul Prescod [mailto:paul@...t] > > No, actually it is strictly REST. If the client needs to > generate a URI using information only known to the client > (like an ISBN number or a > date) then the URI should use a query string. Why is that? > But even if it > wasn't strictly REST-y, I wouldn't fuss too much about the > construction of URIs because in the web architecture URIs are > typically opaque. URIs are hardly opaque. The schemes have structure that needs to be parsed out. Bill de hra .. Propylon www.propylon.com
Bill de h�ra wrote: > > > -----Original Message----- > > From: Paul Prescod [mailto:paul@...] > > > > No, actually it is strictly REST. If the client needs to > > generate a URI using information only known to the client > > (like an ISBN number or a > > date) then the URI should use a query string. > > Why is that? http://www.w3.org/DesignIssues/Axioms.html#query > > But even if it > > wasn't strictly REST-y, I wouldn't fuss too much about the > > construction of URIs because in the web architecture URIs are > > typically opaque. > > URIs are hardly opaque. The schemes have structure that needs to be > parsed out. URIs are opaque to the client application. Obviously the client's URI-derefencing implementation needs to parse them to do the dereferencing, but the application using the implementation doesn't need to do that. http://www.w3.org/DesignIssues/Axioms.html#opaque I'm hoping those documents answer the questions but if not, ask again. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On Thu, Jul 18, 2002 at 10:03:24AM +0100, Bill de h�ra wrote: > > > > -----Original Message----- > > From: Paul Prescod [mailto:paul@...] > > > > No, actually it is strictly REST. If the client needs to > > generate a URI using information only known to the client > > (like an ISBN number or a > > date) then the URI should use a query string. > > Why is that? Well, that's how it currently is because that's the only deployed convention. It's also the simplest, because the namespace for query parameters is flat. But in the future, some new spec could come out which would allow resource publishers to communicate to clients, how to construct URIs based on other criteria ... if folks found that useful. The key being that the client never guesses, and so must always be following directions provided by the resource publisher. Otherwise it's inferring semantics from structure, and that breaks opacity. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Bill,
Your point is well made --- there *are* in fact URI structure schemes, and
hierarchical semantics in URI paths. However, it's dogmatic that we pretend
this is not the case. We've had many rather ugly battles over this fact on
this list, i.e. over the dogmatic "fundamentalist" interpretation of the
Axiom of Opacity. My suggestion to you would be: it's not worth arguing
about. Save yourself some grief, just do what you need to do.
I will make one point about the Axiom of Opacity, one I've made before but
which bears repeating: it's literally and obviously incorrect vis--vis
existing Web architecture. The axiom says that all you can do with a URI is
deference it. In fact, it is *essential* to the Web architecture that URI
support at least two other kinds of semantics, namely:
* It must be possible to compare URI for equivalence (proxies, etc.)
* It must be possible to construct a URI from another complete URI and
a relative URI.
The latter gives particular credence to your argument; it specifically
comprehends and exploits the hierarchical nature of the path part of the
URI. These two observations together undermine my ability to take the Axiom
seriously, and I believe that anyone approaching the issue with an open mind
will interpret the situation similarly.
Jb
Jeff Bone wrote: > > .... In fact, it is *essential* to the Web architecture that URI > support at least two other kinds of semantics, namely: > > * It must be possible to compare URI for equivalence (proxies, etc.) > > * It must be possible to construct a URI from another complete URI and > a relative URI. IMO, a web toolkit that properly supports the web/REST model would provide a URI object with the following three methods: uri.dereference(method, headers, representation) uri.compare() uri.create(base, relative, query_params) If *applications* stick to those three methods then you will not accidentally treat XML as HTML by sniffing the file extension, you will not accidentally infer hierarchical relationships that don't exist, you will not accidentally treat a .jsp as code rather than data, you will not accidentally make code that works with HTTP but not HTTPS (or any other REST-compliant protocol) etc. If your client or intermediary application only deals with URIs through these methods then IMO, that application properly treats URIs as opaque. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Paul Prescod wrote: > >... > > IMO, a web toolkit that properly supports the web/REST model would > provide a URI object with the following three methods: > > uri.dereference(method, headers, representation) > uri.compare() > uri.create(base, relative, query_params) Perhaps not coincidentally, these are roughly the same three things you can portably do with a C++ pointer: foo *r,*s; s->method(params); cout << (s == r); r = s+1; Java can't do the last but I think that is because it is just a performance hack in C++ and a minimization hack in the Web architecture. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
(If you're interested in this issue, please read on... Hopefully informative
w/o being inflammatory.)
On 7/18/02 10:51 AM, "Paul Prescod" <paul@...> wrote:
> ...
Paul, you and I perpetually argue about this topic, though in fact there's
more agreement than the discussion might seem to indicate. Let me see if I
can reframe my argument in terms you can agree with. First, here is the
Axiom of Opacity:
"The only thing you can use an identifier for is to refer to an object. When
you are not dereferencing you should not look at the contents of the URI
string to gain other information..."
(I eliminated "as little as possible" as it's a typical TBLism that is
neither quantifiable nor objective.)
My point is this: this is *clearly* inaccurate even with respect to
existing standardized practices. As you yourself agree, there are at least
two other semantics: comparison (a form of deconstruction) and construction
from relative URI. So URI do *not* only support dereference; it is
necessary to look at the contents of the URI string in some contexts to gain
the information necessary to use them the way they need to be used.
.:, URI are not opaque in any sense consistent with the Axiom, and perhaps
not opaque in any meaningful sense.
Despite this, you and I share and agree on an "intuitive" definition of
"opacity" that we believe is desirable for URI. A better way to put this,
rather than calling it "opacity," would be: URI do NOT have any implicit
semantics. All operations and semantics on URI *must* be explicitly
specified. I would even go further and say that these semantics must not
only be explicit, they must be universal within a given URI scheme. In this
sense, I perhaps advocate "opacity" (really, its intent) even more strongly
than you.
>
> If *applications* stick to those three methods then you will not
> accidentally treat XML as HTML by sniffing the file extension, you will
> not accidentally infer hierarchical relationships that don't exist, you
> will not accidentally treat a .jsp as code rather than data, you will
> not accidentally make code that works with HTTP but not HTTPS (or any
> other REST-compliant protocol) etc.
Here we agree on desired outcome but disagree on how to get there. We agree
that URI should not e.g. have content type semantics embedded in them. URI
are names - not type descriptions. Parsing URI to determine type is a bad
thing, and indeed it is historically the motivation for the "Axiom" in
question. In general, lots of problems result when you start assuming
things about the semantics of URI.
But that doesn't mean that URI *should* or even *do* have only the semantics
of dereference, or even the set of { deref, compare, construct-relative }.
There may well be other semantics of construction and deconstruction that
are both generic (universal) and useful / desirable. My argument is
therefore the following:
Given any universal / useful mechanism for use / construction /
deconstruction of URI beyond { deref, compare, construct-relative }, there
is *no* particular reason to reject such a mechanism out of hand on the
basis of the clearly defective "Axiom" of URI Opacity alone.
Sure, such rejection is "safe" --- if we assume just those three operations,
we can be sure that programs that use just those operations work correctly.
And this is a good thing. In general, constraints are a good thing --- the
Web gains much of its power through its constraining mechanisms. However,
constraints should not be arbitrary, and IMO rejecting the possibility of
additional explicit / universal semantics for URI is just such an
unacceptable, arbitrary constraint. By itself, the existence of the
so-called Axiom is not sufficient to reject the possibility that other
universal and useful semantics might be explicitly specified at some point.
$0.02,
Jb
PS - one other important bit. It's important to distinguish between HTTP
URI and URI in general. The Axiom of Opacity is intended to apply to all
URI, not just HTTP-scheme URI. And while it may (or may not) be desirable
to ignore the hierarchical semantics of the path part of an HTTP URI, it's
***NOT*** the case that this is desirable in all conceivable URI schemes.
Filesystem related schemes like smb:// and nfs:// absolutely *require* that
clients of those protocols be able to deconstruct and comprehend URI
according to their hierarchical structure. So another problem with the
Axiom of Opacity --- and its dogmatic interpretation --- is that it is
overly biased to the-Web-of-HTTP-and-hypertext. It assumes things that it
cannot assume about non-HTTP URI schemes.
> IMO, a web toolkit that properly supports the web/REST model would > provide a URI object with the following three methods: > > uri.dereference(method, headers, representation) > uri.compare() > uri.create(base, relative, query_params) That's what we've done for our app, actually. :) Just to make I understand the common consensus... the URI is opaque for the client and the network as a whole, but not the server? I say this because obviously the server has to be able to interpret that URI to find the object. Am I close here? Thanks, Seth
From: "Seth Ladd" <seth@...> > > > IMO, a web toolkit that properly supports the web/REST model would > > provide a URI object with the following three methods: > > > > uri.dereference(method, headers, representation) > > uri.compare() > > uri.create(base, relative, query_params) > > That's what we've done for our app, actually. :) > > Just to make I understand the common consensus... the URI is opaque for > the client and the network as a whole, but not the server? I say this > because obviously the server has to be able to interpret that URI to > find the object. Am I close here? I think he is going a step further and saying that things other than the URI owner (the server) should be able to apply the above methods. For instance, your client should be able to do the compare() method to determine if the same resource is being requested again. When you submit a form to a relative URI, the client must be able to use the create() method to generate an absolute URI from from a base and a relative (and possibly a query string). For instance, suppose you have an html form in a resource pointed to by http://site.com/foo. The form method is GET and the action is "bar/baz". When you submit the form, the client will create a URI that will look something like http://site.com/foo/bar/baz?field=value. In order to do this (or the comparison), the client must be able to understand more about the URI (within the http scheme space) than the basic ability to dereference it. At least I think that's what he is saying... --- Seairth Jacobs seairth@...
Hi all I'm just learning about REST, and reading as much as I can. Currently it's Roger Costello's tutorial [1] (thanks Roger). On slide 12 [2], I read "...allow the client to specify ... HTML ... or XML" followed by the example URL with ?flavor=xml at the end. I'm not at all trying to find fault with the tutorial, but I was wondering this: Is it more (or less?) appropriate (in a REST context) for the client to use the HTTP Accept: header to declare what it wants (e.g. text/html or text/xml) rather than modifying the URI? Thanks dj http://www.pipetree.com/qmacro [1] http://www.xfront.com/REST.html [2] http://www.xfront.com/sld012.htm
Seth Ladd wrote: > >... > > That's what we've done for our app, actually. :) > > Just to make I understand the common consensus... the URI is opaque for > the client and the network as a whole, but not the server? I say this > because obviously the server has to be able to interpret that URI to > find the object. Am I close here? I think that that is pretty much it! There is a corner case where the server is just a "file storage" and some other agent is actually inventing the URIs and storing information with them. In that case, the agent inventing the URIs is of course the one that can treat them as transparent rather than opaque. Also, Jeff says that if the client and server negotiate somehow (prose document or something else), the server could delegate the right to interpret the URIs. I don't think that this is very often necessary in practice but as long as permission was given explicitly it would be okay with me. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Yes, I think that content negotiation is more appropriate if your software supports it. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Does anybody have the requisite access to do a REST-y analysis of EBay's XML/HTTP APIs? -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On 7/18/02 2:59 PM, "Seth Ladd" <seth@...> wrote: > >> IMO, a web toolkit that properly supports the web/REST model would >> provide a URI object with the following three methods: >> >> uri.dereference(method, headers, representation) >> uri.compare() >> uri.create(base, relative, query_params) > > That's what we've done for our app, actually. :) > > Just to make I understand the common consensus... the URI is opaque for > the client and the network as a whole, but not the server? I say this > because obviously the server has to be able to interpret that URI to > find the object. Am I close here? Yup. But... Now here's the interesting question: what about intermediaries? ;-) In general "opacity" is a good thing, but intermediaries by their very nature need to have a deeper understanding of things. Jb > > Thanks, > Seth >
Jeff Bone wrote:
>
>...
>
> My point is this: this is *clearly* inaccurate even with respect to
> existing standardized practices. As you yourself agree, there are at least
> two other semantics: comparison (a form of deconstruction) and construction
> from relative URI. So URI do *not* only support dereference; it is
> necessary to look at the contents of the URI string in some contexts to gain
> the information necessary to use them the way they need to be used.
>
> .:, URI are not opaque in any sense consistent with the Axiom, and perhaps
> not opaque in any meaningful sense.
If you read the whole document, Tim BL quotes both of these
"exceptions". A more formal exposition would put all of the things you
can do with URIs together. But I've always read the document as "URIs
are opaque with the exceptions listed in this document." My concern is
that we not present these "exceptions" as evidence that the dam is
leaking and therefore why not let all of the water in? A simple
editorial change on Tim BLs part could turn those "exceptions" into just
clearly described things you ARE allowed to do with URIs.
"The only thing you can use an identifier for is to refer to an object.
When you are not dereferencing, comparing or constructing absolute URIs
from relative ones, you should not look at the contents of the URI
string to gain other information..."
> Despite this, you and I share and agree on an "intuitive" definition of
> "opacity" that we believe is desirable for URI. A better way to put this,
> rather than calling it "opacity," would be: URI do NOT have any implicit
> semantics. All operations and semantics on URI *must* be explicitly
> specified. I would even go further and say that these semantics must not
> only be explicit, they must be universal within a given URI scheme. In this
> sense, I perhaps advocate "opacity" (really, its intent) even more strongly
> than you.
If you want to make the level of opacity a scheme-specific "property"
that's okay with me. I'm pretty much the most hard-line HTTP scheme
bigot anyhow.
Do you and I also agree that the specification for HTTP URIs does not
allow you to infer that given:
http://x.com/foo/bar
that there is a resource "http://x.com/foo"?
>...
>...
> Sure, such rejection is "safe" --- if we assume just those three operations,
> we can be sure that programs that use just those operations work correctly.
> And this is a good thing. In general, constraints are a good thing --- the
> Web gains much of its power through its constraining mechanisms. However,
> constraints should not be arbitrary, and IMO rejecting the possibility of
> additional explicit / universal semantics for URI is just such an
> unacceptable, arbitrary constraint. By itself, the existence of the
> so-called Axiom is not sufficient to reject the possibility that other
> universal and useful semantics might be explicitly specified at some point.
Okay, I can agree to that. But it's very different than giving people
the advice that they should just do what they feel like when it comes to
opacity. Until someone, somewhere defines other universal operators for
URIs, as far as I know the only operations available are {deref,
compare, construct-relative}. So for now, opacity "you shouldn't do
other stuff with URIs, or at least HTTP URIs."
And of course there is an ambigious "you" in the formulation. "You"
cannot include the entity (usually a server) responsible for mapping
from URIs to real resources.
>...
> PS - one other important bit. It's important to distinguish between HTTP
> URI and URI in general. The Axiom of Opacity is intended to apply to all
> URI, not just HTTP-scheme URI. And while it may (or may not) be desirable
> to ignore the hierarchical semantics of the path part of an HTTP URI, it's
> ***NOT*** the case that this is desirable in all conceivable URI schemes.
> Filesystem related schemes like smb:// and nfs:// absolutely *require* that
> clients of those protocols be able to deconstruct and comprehend URI
> according to their hierarchical structure.
We disagree on whether these non-REST resources are first-class parts of
"the Web" but that is the sort of argument that will never terminate for
lack of clear definitions.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Sorry. Last I looked, it cost $1000+ runtime usage fees to even take a look
at their APIs. I also seem to recall there were restrictions on being able
to discuss them openly once you signed their agreement.
I'm guessing they're so strict with their terms because there are people out
there who have tried to sneak around the backdoor and run automated mass
postings and bids, so I can't say I blame them too much.
Ramin
-----Original Message-----
From: Paul Prescod [mailto:paul@...]
Sent: Thursday, July 18, 2002 1:46 PM
To: S. Mike Dierken; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Fw: [syndication] Amazon does SOAP
Does anybody have the requisite access to do a REST-y analysis of EBay's
XML/HTTP APIs?
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> There is a corner case where the server is just a "file storage" and > some other agent is actually inventing the URIs and storing information > with them. In that case, the agent inventing the URIs is of course the > one that can treat them as transparent rather than opaque. > > Also, Jeff says that if the client and server negotiate somehow (prose > document or something else), the server could delegate the right to > interpret the URIs. I don't think that this is very often necessary in > practice but as long as permission was given explicitly it would be okay > with me. I think it's actually too hard to give semantic meaning to the URI, which is probably which everyone says they should be outwardly opaque. How do you convey that meaning to a global audience? It might have meaning to some participants, but there is no way to formally publish those meanings, so no systems should be built having to understand the URI. One merely has to GET that URI and use (hopefully) RDF to understand what that object is. And to understand the encoding of that object, use the MIME type. OK, *phew*. Thanks! Seth
On 7/18/02 4:10 PM, "Paul Prescod" <paul@...> wrote:
> Jeff Bone wrote:
>>
>> ...
>>
>> My point is this: this is *clearly* inaccurate even with respect to
>> existing standardized practices. As you yourself agree, there are at least
>> two other semantics: comparison (a form of deconstruction) and construction
>> from relative URI. So URI do *not* only support dereference; it is
>> necessary to look at the contents of the URI string in some contexts to gain
>> the information necessary to use them the way they need to be used.
>>
>> .:, URI are not opaque in any sense consistent with the Axiom, and perhaps
>> not opaque in any meaningful sense.
>
> If you read the whole document, Tim BL quotes both of these
> "exceptions". A more formal exposition would put all of the things you
> can do with URIs together.
No confusion here, that's always been quite evident.
> But I've always read the document as "URIs
> are opaque with the exceptions listed in this document."
And I agree that this is the intended interpretation. BUT --- I disagree
that this interpretation is "healthy" for the overall architecture of the
Web. The Axiom of Opacity is, historically, exactly and only a reaction to
the early and broken use of filename extensions in HTTP URI to determine
filetype.
The problem I have is that it goes to far. A single axiom, particularly one
as poorly stated and overly general as the one in question, constrains the
entire architecture of the Web.
So the question is what's the "real" intent of the axiom? Is it to
constrain the semantics of all URI, HTTP and otherwise, to the one (or two,
or three...) operations explicitly called out? Or is it to say that the
semantics of URI should be minimal, explicit, and universal --- and that URI
should not be used otherwise?
IMO, in the absence of rationale for the former - in the absence of some
kind of rigorous and compelling argument that demonstrates that indeed,
those three operations form a complete and expressive operational semantics
for all URI of all types - I prefer to assume the latter intent. It
provides a framework of constraint without being overly or arbitrarily
constraining.
> My concern is
> that we not present these "exceptions" as evidence that the dam is
> leaking and therefore why not let all of the water in? A simple
> editorial change on Tim BLs part could turn those "exceptions" into just
> clearly described things you ARE allowed to do with URIs.
But in fact the dam is leaking, and it's not a matter of letting all the
water in. It's a matter of fixing the leak. The leak is the that, I
believe, the Axiom doesn't achieve its true intent.
>
> "The only thing you can use an identifier for is to refer to an object.
> When you are not dereferencing, comparing or constructing absolute URIs
> from relative ones, you should not look at the contents of the URI
> string to gain other information..."
>
So, are you talking about all URI or just HTTP URI? If all URI, I'll tell
you that you're wrong to constrain things thus, because other applications
*require* deeper semantics of names.
> Do you and I also agree that the specification for HTTP URIs does not
> allow you to infer that given:
>
> http://x.com/foo/bar
>
> that there is a resource "http://x.com/foo"?
>
I do agree that the inference above is not a safe assumption in today's
world. Whether or not that's a good or bad thing is open to debate and
rationale / justification for such debate differs between applications. In
the absence of specific knowledge that the provider x.com made such a
guarantee, making this kind of an inference is a mistake.
> Okay, I can agree to that. But it's very different than giving people
> the advice that they should just do what they feel like when it comes to
> opacity.
I think you're over-interpreting what I've said.
> Until someone, somewhere defines other universal operators for
> URIs, as far as I know the only operations available are {deref,
> compare, construct-relative}. So for now, opacity "you shouldn't do
> other stuff with URIs, or at least HTTP URIs."
>
> And of course there is an ambigious "you" in the formulation. "You"
> cannot include the entity (usually a server) responsible for mapping
> from URIs to real resources.
What of an entity that maps URI into other URI according to some
algorithm...?
jb
> ----- Original Message ----- > From: Ramin Firoozye > On the other hand, I've been seeing a lot of postings here and on XML-DEV about > strict adherence to the REST URL scheme (i.e. http://.../search/isbn/123456789 vs. http://.../search?isbn=123456789). There is no such thing as 'the REST URL scheme'. The identifier of a resource - the URI or URL - is the /whole/ text string, not just the segments with '/' characters. This is an important point and I myself didn't realize it for a long time. The resource is identifed by path+query - not just the 'path'. Appending a query string onto a path identifies a /different/ resource. There are many more resources than you would think at first. The query string (after the '?' character) is a part of the whole resource identifier. It happens to be a part that is easy to describe to developers when they want to construct the full identifier. If you can't construct the identifier, you have to harvest it from some sort of XML (or other media format) and that is just as complex as telling people how to construct the darn URI in the first place... Anyway... both formats are equally fine, but the query string approach is easier to document.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > Also, Jeff says that if the client and server negotiate somehow (prose > document or something else), the server could delegate the right to > interpret the URIs. I don't think that this is very often necessary in > practice but as long as permission was given explicitly it would be okay > with me. I would think that the HTML FORM element gives us a real-world example of this. For example: <form action='bizdocs'> <input name='doc-type' /> <input name='doc-id' /> </form> is enough for todays browsers to construct URIs: http://current-domain/bizdocs?doc-type=catalog&doc-id=72 I should be able to use this markup to know how to GET and PUT and DELETE this resource - with the major assumption that the value-space is something the client knows. Mapping value-space between systems - especially across organizational boundaries - is another ball of wax that people don't normally talk about. <flames-go-here target='/dev/null' />
----- Original Message ----- From: "DJ Adams" <dj.adams@...> > > I'm just learning about REST, and reading as much as I can. Currently > it's Roger Costello's tutorial [1] (thanks Roger). > > On slide 12 [2], I read "...allow the client to specify ... HTML ... > or XML" followed by the example URL with ?flavor=xml at the end. > > I'm not at all trying to find fault with the tutorial, but I was wondering > this: Is it more (or less?) appropriate (in a REST context) for the client > to use the HTTP Accept: header to declare what it wants (e.g. text/html or > text/xml) rather than modifying the URI? For a pure 'automatable Web' application then it is much better to use the Accept header. If you have to interoperate with browsers you may need to resort to these sorts of hacks - and if so, I'd recommend using a naming convention that can easily point to the HTTP semantics. for example: ...?do:accept=text/xml where the 'do:' part is equivalent to an HTTP header of the same name. I would have used 'http:' but that would have been really confusing... All that said, I think the separation of resource and representation is the part of REST that almost all tools (servers, clients, etc.) have the most problem with. Think of all the ASP, JSP, PHP, etc that have the content to be output hardcoded right there in the file - not very easy to switch based upon the Accept header (unless you use internal server-side redirects). I think all of todays 'visual Web' applications are doing fine at exposing /user interface/ with HTTP, but I have a sinking feeling that for an 'automatable Web' we are going to need new server environments and new clients. The new clients aren't that hard, its re-using exising server technology that might be a problem. But maybe I'm being pessimistic.
----- Original Message ----- From: "Paul Prescod" <paul@...> > Do you and I also agree that the specification for HTTP URIs does not > allow you to infer that given: > > http://x.com/foo/bar > > that there is a resource "http://x.com/foo"? There is an /identifier/ however and when you check via GET or HEAD it may or may not exist.
I am having a bit of trouble understanding how RESTful web services serve up dynamic content when using GET. For instance, suppose you have the following URL: http://www.seairth.com/time.php Now, suppose that this each time the URL is submitted, it returns the current time in GMT. From what I understand, GET is ideally suppose to have the same resource/representation returned each time it is submitted. However, this would not be the case here. So is GET not the appropriate verb to use here, or does it not matter what is returned each time? I understand that GET is not supposed to change the state of the the resource being requested. Suppose you had the following URL: http://www.seairth.com/hitcount.php Now, in this case, each time it the URL is submitted, the server increments an internal hit counter and returns the current hit count. In this case, the actual act of making the request has cause the state to change. Should GET not be used in a case like this, or is the GET request not actually the thing which is changing the resource state? --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Thursday, July 18, 2002 7:50 PM Subject: [rest-discuss] URIs, GET, and dynamic resources > I am having a bit of trouble understanding how RESTful web services serve up > dynamic content when using GET. For instance, suppose you have the > following URL: > > http://www.seairth.com/time.php > > Now, suppose that this each time the URL is submitted, it returns the > current time in GMT. From what I understand, GET is ideally suppose to have > the same resource/representation returned each time it is submitted. Actually it is supposed to be the current value of the resource - if the resource has changed, a new value will be sent. > However, this would not be the case here. So is GET not the appropriate > verb to use here, or does it not matter what is returned each time? If the resource is 'current time' then it the content will always vary over time. Using GET is just fine. If you have a resource that is a clock and you want to re-set the time to some value, then GET is not the right method. > > I understand that GET is not supposed to change the state of the the > resource being requested. Suppose you had the following URL: > > http://www.seairth.com/hitcount.php > > Now, in this case, each time it the URL is submitted, the server increments > an internal hit counter and returns the current hit count. In this case, > the actual act of making the request has cause the state to change. Should > GET not be used in a case like this, or is the GET request not actually the > thing which is changing the resource state? Kind of a catch-22 sure, but the 'not change state' constraint has to do with the intent of the GET - sending a GET request in order to modify state and as the documented mechanism for that resource is what should be avoided. The hit-counter problem is a fuzzy area of the 'GET is safe and idempotent' requirement, but I don't think the requirement is so constraining that hit-counters are not allowed. I believe a resource can be defined in terms of the history of that resource and not just some static data values somewhere.
> -----Original Message----- > From: Paul Prescod [mailto:paul@...t] > > If you read the whole document, Tim BL quotes both of these > "exceptions". A more formal exposition would put all of the > things you can do with URIs together. But I've always read > the document as "URIs are opaque with the exceptions listed > in this document." Axioms shouldn't have exceptions, axioms are necessary, foundational truths. Correct me if I'm wrong, but I thought the exception to an axiom is another contradictory axiom. That's not to dismiss the document outright, it has excellent principles within it. Bill de hra .. Propylon www.propylon.com
> The identifier of a resource - the URI or URL - is the /whole/ text
string,
> not just the segments with '/' characters. This is an important point and
I
> myself didn't realize it for a long time. The resource is identifed by
> path+query - not just the 'path'. Appending a query string onto a path
> identifies a /different/ resource. There are many more resources than you
> would think at first.
>
> The query string (after the '?' character) is a part of the whole resource
> identifier. It happens to be a part that is easy to describe to developers
> when they want to construct the full identifier. If you can't construct
the
> identifier, you have to harvest it from some sort of XML (or other media
> format) and that is just as complex as telling people how to construct the
> darn URI in the first place...
Okay, suppose you had an html form that looked something like:
<form action="http://seairth.com/getinformation">
<input name="userid" type="text">
</form>
Now, if I were to submit it using the GET method, you would have a URL that
looked like:
http://seairth.com/getinformation?userid=seairth
On the other hand, if I were to submit it using POST, you would have:
http://seairth.com/getinformation
and the content of the message would have:
userid=seairth
Now, you are saying that the two resulting URLs above are different
identifiers. On the on hand, I would say that the GET should be used here
since the intent of this request is idempotent. On the other hand, using a
GET allows the client to create it's own identifier (of which their could be
an unlimited number of variations). Using a POST would mean that the same
identifier was is every time. Also, since the client does not know whether
it's action is idempotent or not, using POST acknowledges this possibility.
However, using POST would not allow effective caching since the same URL
(identifier) may return different results for each request.
So, in REST fashion, what would be the more appropriate method here?
Part of the reason I am asking this has to do with GTP [1]. After reading
some of the discussions on this list and reading the Axioms of Web
Architecture [2] piece, I had thought that I could make the following
requirement:
In the {from} and {to} nodes, the URI used is always controlled by the owner
of the URI. In other words, the recipient of the URI is never allowed to
modify the URI and thereby create a new identifier. Instead, anything
generated by the recipient would go inside a {get}, {put}, {add}, {edit}, or
{delete} node. In this case, the difference between {get} and {put} here
are their intent, specifically that {get} should be used for idempotent
messages while {put} does not have that restriction. In the above example,
you would end up with a GTP message that looked something like:
{onx
{gtp
{to [URI "gtp://seairth.com/getinformation"]}
{get [userid "seairth"]}
}gtp
}onx
or
{onx
{gtp
{to [URI "gtp://seairth.com/getinformation"]}
{put [userid "seairth"]}
}gtp
}onx
where the actual choice of which verb is used is based on the intent (in
this case, more likely the {get}). As a note, I have no problem with the
URI containing a query string as long as the owner of the URI set the query
string (e.g. to maintain a session id). I would not expect this usage to be
common, but I don't see any reason for disallowing it.
Then you come along and pointed out that query strings (the part that the
client has the ability to create) are (or can be) part of the identifier.
So this got me to wondering if enforcing this separation in GTP was a good
thing or not. I think it helps to provide a clean and consistant set of
rules as to how URIs should be used. But, is this RESTful?
[1] www.seairth.com/web/rpc/gtp.html
[2] www.w3.org/DesignIssues/Axioms.html
---
Seairth Jacobs
seairth@...
Thinking more about the recent discussion of order changes on the ws- arch mailing list: There was a missing dimension to the discussion that points out something important about REST: Order changes have ripple effects. Orders are seldom isolated activities. Instead they are connected in networks of economic exchanges. For example, your computer order to e.g. Dell is connected to dependent demands for all of the components of the computer, none of which are manufactured by Dell, but only assembled and shipped. If all of those dependent activities have URIs, then they can be hyperlinked together. And if you change your order to Dell, the ripple effects of that change can traverse those hyperlinks. Now I know that all of those rippling notifications can happen without hyperlinks. Via expensive proprietary software. Hyperlinks could turn at least the links into infrastructure. There are similar dependencies and ripple effects of change in many other domains, e.g. software development. There should be a terrific REST story rippling through these links. -Bob Haugen
Right. This is old news, isn't it? The big story is application layer routing. You could imagine suppliers subscribed to "demand resources" via HTTP WATCH/MONITOR/SUBSCRIBE, etc.. Basically, treating the entire supply network as one huge coordination problem. MB On Fri, Jul 19, 2002 at 05:10:04PM -0000, bhaugen32 wrote: > Thinking more about the recent discussion of order changes on the ws- > arch mailing list: > > There was a missing dimension to the discussion that points out > something important about REST: > Order changes have ripple effects. > > Orders are seldom isolated activities. > Instead they are connected in networks of economic exchanges. > > For example, your computer order to e.g. Dell is connected to > dependent demands for all of the components of the computer, none of > which are manufactured by Dell, but only assembled and shipped. > > If all of those dependent activities have URIs, then they can be > hyperlinked together. > > And if you change your order to Dell, the ripple effects of that > change can traverse those hyperlinks. > > Now I know that all of those rippling notifications can happen > without hyperlinks. Via expensive proprietary software. Hyperlinks > could turn at least the links into infrastructure. > > There are similar dependencies and ripple effects of change in many > other domains, e.g. software development. > > There should be a terrific REST story rippling through these links. > > -Bob Haugen > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
rest-folks: We just released a new software package called NetGlue. It lets you turn code libraries, databases, web-sites, and web-service into 'plug-in' components. These can be invoked from a variety of languages, and via both SOAP and HTTP URLs. Services exposed using NetGlue are automatically HTTP/URL-accessible. I won't go so far as to call it REST-compliant, but its approach is closer to REST than SOAP (URL invocation vs. messaging) even though it does both. If it catches on, you should see a lot more REST-compatible web-services out there. More info is at <http://www.wizen.com> or <http://www.netglue.net>. It's free for developer and personal use. I've been following the REST discussion and would be interested in hearing your thoughts on our approach. Thanks, Ramin --- Ramin Firoozye Wizen Software. San Francisco, California. ---
Mark Baker wrote: > Right. This is old news, isn't it? Well, yeah, but who's doing it? The people who wanted to solve the problem bought i2 etc. for lots of money and implementation headaches. The people on the ws-arch and xml-dev lists assume the links go into internal proprietary systems. The idea of doing it with URI hyperlinks hasn't crossed many people's minds - except some of the people on this list, of course, and maybe some of the dist-obj gang, although I don't know there. > The big story is application layer routing. Say more? > You could imagine suppliers subscribed to "demand resources" > via HTTP WATCH/MONITOR/SUBSCRIBE, etc.. And I do, I do! http://www.supplychainlinks.com/Rea4scm.htm#REAInAction Problem at that stage is that I hadn't really grokked REST in total. (No rash claims now, but it's coming...) -Bob Haugen
On Fri, Jul 19, 2002 at 06:21:30PM -0000, bhaugen32 wrote: > Mark Baker wrote: > > Right. This is old news, isn't it? > > Well, yeah, but who's doing it? KnowNow. Some of our technology does something similar, but not with that exact problem domain in mind. KnowNow's stuff would be off-the-shelf usable for this, I expect. > > You could imagine suppliers subscribed to "demand resources" > > via HTTP WATCH/MONITOR/SUBSCRIBE, etc.. > > And I do, I do! 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
As most Web servers do, Apache (through mod_dir) automagically resolves requests for URIs with trailing slashes to contained resources, usually index.html. Shouldn't such responses have a Content-Location in the headers? E.g., GET /foo/ HTTP/1.1 Host: www.example.com --8<-- HTTP/1.1 200 OK Content-Location: index.html ... I'm thinking we should get a patch to Apache together... this would make the relationship between the resources explicit, helping Google, etc. if they want to take advantage of the info. Thoughts? -- Mark Nottingham
On 7/19/02 12:10 PM, "bhaugen32" <bhaugen32@...> wrote: > Thinking more about the recent discussion of order changes on the ws- > arch mailing list: > > There was a missing dimension to the discussion that points out > something important about REST: > Order changes have ripple effects. > That's exactly right. In fact, a general observation is in order: the mechanism by which an operation or change in one part of a system of interacting components causes operations or changes in another part, and the combinatorics of those operations or changes changes, is the heart of software architectural complexity. My late-night research project over the last year - inspired by discussion on FoRK and this list - has been an effort to come up with a generic and formal mathematical framework for characterizing and analyzing this kind of complexity. It's nowhere near done yet, but it's been an interesting endeavor so far. Current computer science gives us good tools for analyzing the time and space complexity of algorithms, but no or poor tools for analyzing software architectural complexity. My hope is that if this research bears fruit it will provide us with good tools for that purpose; my intuition, though I'm not letting it bias the research, is that generic compositional frameworks (pure functional composition, UNIX-like dataflow composition, Linda-like coordination frameworks, REST) are quantifiably "simpler" in various ways than other compositional frameworks (procedural composition with side-effects, object-oriented composition.) $0.02, Jb
----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
>
> Okay, suppose you had an html form that looked something like:
>
> <form action="http://seairth.com/getinformation">
> <input name="userid" type="text">
> </form>
>
> Now, if I were to submit it using the GET method, you would have a URL
that
> looked like:
>
> http://seairth.com/getinformation?userid=seairth
>
> On the other hand, if I were to submit it using POST, you would have:
>
> http://seairth.com/getinformation
>
> and the content of the message would have:
>
> userid=seairth
>
Good point.
The message with the GET is asking to retrieve the information.
The message with the POST method is asking the server to accept the content
of "userid=seairth" - perhaps to log it, or add it to a list or whatever.
What would happen with a FORM like this?
<form action="http://seairth.com/getinformation?userid=mike">
<input name="userid" type="text">
</form>
You would have a message sent to
http://seairth.com/getinformation?userid=mike
and the content of the message would be "userid=seairth"
The message might be asking to add 'seairth' to the contact list for 'mike'.
Many server tools have a problem with this. In Java servlets, you can say
request.getParameter("userid") - but that will automatically pull content
out of the body if the content-type is x-www-form-urlencoded. The problem
comes from the 'getParameter' method talking about a non-existent concept in
HTTP. Things become ambiguous and confusing & programmers end up creating
workarounds that move away from the power and utility of HTTP itself.
For myself, I don't care that HTML browsers do or don't do things with FORM
elements, and I don't care that server tools do or don't make it easy to get
parts of the request. For the 'automatable Web' people will be using their
own clients and talking to more intelligent server tools.
http://www.razorsoft.net/weblog/2002/07/19.html#a313 --Dilip
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > As most Web servers do, Apache (through mod_dir) automagically resolves > requests for URIs with trailing slashes to contained resources, usually > index.html. > > Shouldn't such responses have a Content-Location in the headers? E.g., > > GET /foo/ HTTP/1.1 > Host: www.example.com > > --8<-- > > HTTP/1.1 200 OK > Content-Location: index.html > > ... > > I'm thinking we should get a patch to Apache together... this would make > the relationship between the resources explicit, helping Google, etc. if > they want to take advantage of the info. > Would the content be returned or would it be a 'redirect'? Does the 200+"Content-Location" response mean that the entity body returned is actually more properly accessible via Content-Location value?
> Would the content be returned or would it be a 'redirect'? The content would be returned. > Does the 200+"Content-Location" response mean that the entity body returned > is actually more properly accessible via Content-Location value? Not more properly accessible; just also available at. From 2616: The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. [...] The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. Future requests MAY specify the Content-Location URI as the request- URI if the desire is to identify the source of that particular entity.
"S. Mike Dierken" wrote: > >... > Kind of a catch-22 sure, but the 'not change state' constraint has to do > with the intent of the GET - sending a GET request in order to modify state > and as the documented mechanism for that resource is what should be avoided. > > The hit-counter problem is a fuzzy area of the 'GET is safe and idempotent' > requirement, but I don't think the requirement is so constraining that > hit-counters are not allowed. I believe a resource can be defined in terms > of the history of that resource and not just some static data values > somewhere. I agree. Here is the way I think about it: if you make a POST operation with side effects and some stupid client calls it a million times, any side effects are THEIR fault. If you make a GET operation with side effects and some stupid client calls it a million times, any side effects are YOUR fault and YOUR problem. If you don't mind a massively inflated hit counter then go ahead, use GET. If it is important to maintain an accurate count of intentional client actions, then use POST. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Paul Prescod" <paul@...> > "S. Mike Dierken" wrote: > > > > Kind of a catch-22 sure, but the 'not change state' constraint has to do > > with the intent of the GET - sending a GET request in order to modify state > > and as the documented mechanism for that resource is what should be avoided. > > > > The hit-counter problem is a fuzzy area of the 'GET is safe and idempotent' > > requirement, but I don't think the requirement is so constraining that > > hit-counters are not allowed. I believe a resource can be defined in terms > > of the history of that resource and not just some static data values > > somewhere. > > I agree. Here is the way I think about it: if you make a POST operation > with side effects and some stupid client calls it a million times, any > side effects are THEIR fault. If you make a GET operation with side > effects and some stupid client calls it a million times, any side > effects are YOUR fault and YOUR problem. If you don't mind a massively > inflated hit counter then go ahead, use GET. If it is important to > maintain an accurate count of intentional client actions, then use POST. So... the difference between GET and POST in terms of "dynamic" resources is entirely in the intent. GET say "given this identifier, give me whatever you've got", while POST says "given this identifier and addtional data, do whatever you are going to do with it, then give me whatever you've got afterwards". Either can return a representation of a resource that changes with each request, but only POST does this by intent. Yes? --- Seairth Jacobs seairth@...
Seairth Jacobs wrote: > >... > > So... the difference between GET and POST in terms of "dynamic" resources is > entirely in the intent. GET say "given this identifier, give me whatever > you've got", while POST says "given this identifier and addtional data, do > whatever you are going to do with it, then give me whatever you've got > afterwards". Either can return a representation of a resource that changes > with each request, but only POST does this by intent. Yes? That is my understanding, yes. It sounds vaguely bogus to have a distinction with a primary goal of establishing who is at fault for a screw-up but then when you think of it, that's the whole point of standards anyhow. If I leave off quotes in an XML attribute, the other party and I can both consult the XML specification to determine who is at fault. Interoperability is achieved when the party at fault consistently corrects to line up with the party who was correct. Or vice versa, in which case the "wrong" behaviour becomes a defacto standard. Wrong behaviours seldom became defacto standards on the real Web because the browsers kind of enforce a certain level of compliance. If you use POST to mean GET then you can't use bookmarks. If you use GET to mean POST then you get users hitting "reload" or "print" and changing your database. In the XML world we don't have those natural checks so for a while it was common to use POST to mean GET with SOAP. But XSLT and other declarative languages serve a similar purpose in the XML world. Using POST to mean GET destroys compatibility with those languages. (many Web apps respond the same way to GET and POST but if the HTML interface only ever advertises one method then the other is effectively non-existent) -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Sam offers a melded REST+SOAP architecture here: http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html I am all for using SOAP syntax in REST services where it provides value. Still, I disagree on some points with the essay. ==== Resources and URIs: ================== > Start by modeling the persistent resources that you wish to expose. > By persistent resources, I am referring to entities that have a > typical life expectancy of days or greater. Ensure that each > instance has a unique URL. When possible, assign meaningful > names to resources. I *think* you mean to say that you should also assign URIs to transient resources. But I'm not sure. Of course I think that transient resources should have URIs. Merging Architectures ===================== You say that your model is different from a resource-centric REST view in these ways: 1. "POST operations explicitly have the possibility of modifying multiple resources." Actually, I would say that PUT and DELETE operations also explicitly have the possibility of modifying multiple resources. For instance if you DELETE a Toolkit then the "index" document that refers to the toolkit should also change. So I do not see this as being an extension to REST but a core REST concept. None of the lists of REST best practices I have seen have ever said that operations should only ever modify a single resource. Deleting an "account record" will probably also delete all kinds of related resources. And arguably the deletion could move the resource's associated data to a "recycle bin" container. 2. "PUT and DELETE operations are rarely used, if ever." I see no reason for that rule. If what you want to accomplish is semantically equivalent to a PUT or DELETE then why not use the standardized method for doing it? I think we need more generic, globally understood methods, not fewer. That increases interoperability. I think that this rule follows from the view that a "true" deletion or update should only change one resource. I do not hold that view so I do not think that this rule is necessary. 3. "GETs may contain query arguments." I don't think that anybody ever disputed this. I have made the point on a few occasions that a service that is query-centric rather than link-centric is not as discoverable. I can ask Google what it knows about "Prescod" but I cannot easily get the list of words that co-occurs with the word REST. In a perfect world with infinite money, Google would support both modes. I could follow hyperlinks from the page representing words that co-occur with REST to a page listing words that co-occur with REST and SOAP etc. GET with query arguments is fine. Just understand that you lose discoverability if this is the primary entry point to your resource set. "If you are encoding parameters on the URL, you are probably making an RPC request of a service, not retrieving the representation of a resource." I disagree. "It is worth reading Roy Fielding's thoughts on the subject." * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html I don't see Roy Fielding saying what Sam says about URIs and query parameters. What *I* think Roy is talking about is services that misuse POST, not query parameters. Misuse of POST is the most common REST abuse in my experience. What SOAP Gives REST ==================== You say that what SOAP adds to REST is stored procedures. I think that this falls out of the belief that REST-people think that operations should always only modify one resource. Insofar as a single POST, PUT or DELETE can have far-reaching effects, each such message is as powerful as an invocation of a stored procedure. Also, we all speak loosely sometimes about "SOAP" versus "REST" but now that SOAP is not Web antaognistic we should be more clear in our terminology. SOAP (the syntax and messaging framework) does not really add stored procedures to REST (the architecture). Everything is a GET =================== One other nit, you characterize four different points of view on REST, SOAP and web services. One of them is "Everything is a get." Actually, I do not see this as a very common point of view at all. I rarely run into state-changing GETs and anyone who uses GET in this way can usually be talked out of it in about five minutes. In other words, it isn't a "camp" in the debate, AFAIK, it is a simple misunderstanding. In fact, a much more common misunderstanding than "everything is a GET" is "everything is a POST". After all, POST is much more "flexible" in its input and output. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
I remember reading about Paul's "reduced SOAP" here, but can't find the message. In there, he said he took out MEPs, and the reason was that REST only defines one. If I understood that correctly, I disagree. REST doesn't prescribe a MEP, HTTP does. But clearly the Web benefitted from having such a simple MEP to start with since it hid some complexity from developers (e.g. request/response correlation). However, that doesn't mean it requires one. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > > I remember reading about Paul's "reduced SOAP" here, but can't find the > message. In there, he said he took out MEPs, and the reason was that > REST only defines one. No, it was an offlist discussion and the document doesn't mention REST: http://www.prescod.net/soap/simplesoap (THAT'S A VERY ROUGH IDEA SO FAR) For anyone who doesn't know, MEP means "Message Exchange Pattern". 'SOAP 1.2 describes different "message exchange patterns" and even allows the implementor to invent new ones. SimpleSOAP uses only one message exchange pattern, request-reply. On top of this you may of course build asychronous systems like the current mail system if you wish. Therefore, once you declare you are using SimpleSOAP, there is no need to also declare what MEP you are using.' > If I understood that correctly, I disagree. REST doesn't prescribe a > MEP, HTTP does. But clearly the Web benefitted from having such a > simple MEP to start with since it hid some complexity from developers > (e.g. request/response correlation). However, that doesn't mean it > requires one. I don't know whether there is really anything we disagree upon. My opinions on MEP are as follows: * request/response is the best choice of primitive MEP for a system that depends heavily on the results of dereferencing URIs. Plus, today's Internet topology makes request/response essentially always available but bidirectional asynch is much harder to roll out. Businesses and ISPs mostly do not want people outside making connections in, therefore the only way to get information in is through a response to an outgoing connection. (with the exception of email, but we know how happy businesses are with random people sending email to their employees) * A highly interoperable system like the Web could have multiple MEPs, as long as *all server implementations* support all of them. If you must "configure" your client to contact a server by informing it what MEP to use then you are starting down a slippery slope that ends in WSDL and UDDI -- not as options but as requirements for getting actual work done. This is what I object to in SOAP. * Nevertheless, if a system like the Web has only a single MEP, others can built on top of it. Whether these others are standardized or not is orthogonal to whether they are primitive. At the very least, notification should be standardized. Making new MEPs primitive is probably too difficult at this point. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
http://internet.conveyor.com/RESTwiki/moin.cgi/ExplainingRest A repository for strategies people have used to explain REST. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Paul Prescod wrote: > if a system like the Web has only a single MEP, others > can built on top of it. Whether these others are standardized or not is > orthogonal to whether they are primitive. At the very least, > notification should be standardized. I think Web business conversation patterns will become standardized, too. Certainly built on top of request-response, probably notification, I think much like the Offer-Acceptance whatchamacallit we discussed on this list. Supply chain change propagation, which we discussed more recently, could be just a hyperlinked chain of Offer-Acceptance conversations, where accepted changes get propagated to dependent links. In other words, I think REST is a good base for complex MEPs. -Bob Haugen
A while back, Don Box (of Microsoft) gave a talk in which he stated that HTTP couldn't support long-term transactions, one specific reason was because of issues with intermediaries. An article about his talk is here: http://zdnet.com.com/2100-1105-845220.html The specific comment from the article is: "...when Web services start running transactions that take some time to complete over the protocol, the model fails. "If it takes three minutes for a response, it is not really HTTP any more," Box said. The problem, said Box, is that the intermediaries--that is, the companies that own the routers and cables between the client and server--will not allow single transactions that take this long." What exactly is it about the intermediaries that wouldn't allow for a long transaction time?
On 7/23/02 11:53 AM, "Jeffrey Winter" <j.winter@...> wrote: > > The specific comment from the article is: > > "...when Web services start running transactions that take some time to > complete over the protocol, the model fails. "If it takes three minutes for > a response, it is not really HTTP any more," Box said. The problem, said > Box, is that the intermediaries--that is, the companies that own the routers > and cables between the client and server--will not allow single transactions > that take this long." > > What exactly is it about the intermediaries that wouldn't allow for a long > transaction time? > I'll admit that I'm not a Don Box fan by any stretch of the imagination, but this comment of his is so obviously braindead wrong that it's embarrassing even for him. Who said that a Web services "transaction" needs to fit in a single HTTP request-response cycle? Hmm? Jb
Personally, I have never seen this happen and I suspect it's a little bit of
a head-fake. The theory is that a TCP socket opened from client to server,
if inactive for an extended period of time, might be timed out by routers
that are doling out scarce resources. I don't think I've ever seen a
three-minute limit though.
*If* that happens AND you have a (very badly designed) transaction-oriented
web-service, the request will be dropped from the client side before the
server side has had time to respond, so the client might have to reissue the
request again and that will screw up the transaction. Again, I've never seen
this happen and I've never heard of anyone complain about this, but maybe I
don't hang around the right people (:-)
In practice, any reasonable transaction-oriented web-service will have
multiple states, so you could have it go through an 'initialize -> invoke ->
commit' cycle and if it doesn't finish all the way, you don't get the money
deducted from your bank account.
It's a little like saying 'because some web-servers return error 404 they
should not be used for serious purposes.' HTTP is very useful for
web-services. Just about any application that can do HTTP can become a
client. An easy solution to Don's problem is to design proper stateful
web-services (but I'm guessing Don and Microsoft already knew this (;-)
Ramin
---
Ramin Firoozye - Wizen Software
---
-----Original Message-----
From: Jeffrey Winter [mailto:j.winter@...]
Sent: Tuesday, July 23, 2002 9:54 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] HTTP can't support web services
A while back, Don Box (of Microsoft) gave a talk in which he stated that
HTTP couldn't support
long-term transactions, one specific reason was because of issues with
intermediaries.
An article about his talk is here:
http://zdnet.com.com/2100-1105-845220.html
The specific comment from the article is:
"...when Web services start running transactions that take some time to
complete over the protocol, the model fails. "If it takes three minutes
for
a response, it is not really HTTP any more," Box said. The problem, said
Box, is that the intermediaries--that is, the companies that own the
routers
and cables between the client and server--will not allow single
transactions
that take this long."
What exactly is it about the intermediaries that wouldn't allow for a long
transaction time?
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> An easy solution to Don's problem is to design proper stateful > web-services (but I'm guessing Don and Microsoft already knew this (;-) RosettaNet has a resource-state-alignment transaction model that works over the Web. It is very compatible with REST, as we've discussed on this list. If you know who designed the RNet transaction model, and know where they work now, you will have the confirmation of your guess.
Don was likely misquoted. It's not* the routers and other lower-layer infrastructure that will cause problems, it's HTTP application-layer intermediaries. They're unwilling to keep a persistent connection open for any period of time, because of the resources that it consumes, and their sensitivity to performance. Most common implementations will only keep a connection open for a few seconds; more radical approaches use an event loop instead of select()/poll(), enabling them to hold many thousands of connections open, but they'll still be closed if the workload is high. While it's true that you can use a separate HTTP connection to get the response back to the client, this leaves you with a sub-optimal choice; a) expose an HTTP server on the client, and hope that it is accessible and addressable (in many of the situations where there is an HTTP intermediary, this isn't the case), or b) have the client poll the server for the response. Icky. * Mostly. Firewalls also have resource limitations, especially if they're doing NAT. ----- Original Message ----- From: "Ramin Firoozye" <ramin@...> To: <rest-discuss@yahoogroups.com> Sent: Tuesday, July 23, 2002 10:35 AM Subject: RE: [rest-discuss] HTTP can't support web services > Personally, I have never seen this happen and I suspect it's a little bit of > a head-fake. The theory is that a TCP socket opened from client to server, > if inactive for an extended period of time, might be timed out by routers > that are doling out scarce resources. I don't think I've ever seen a > three-minute limit though. > > *If* that happens AND you have a (very badly designed) transaction-oriented > web-service, the request will be dropped from the client side before the > server side has had time to respond, so the client might have to reissue the > request again and that will screw up the transaction. Again, I've never seen > this happen and I've never heard of anyone complain about this, but maybe I > don't hang around the right people (:-) > > In practice, any reasonable transaction-oriented web-service will have > multiple states, so you could have it go through an 'initialize -> invoke -> > commit' cycle and if it doesn't finish all the way, you don't get the money > deducted from your bank account. > > It's a little like saying 'because some web-servers return error 404 they > should not be used for serious purposes.' HTTP is very useful for > web-services. Just about any application that can do HTTP can become a > client. An easy solution to Don's problem is to design proper stateful > web-services (but I'm guessing Don and Microsoft already knew this (;-) > > Ramin > --- > Ramin Firoozye - Wizen Software > --- > -----Original Message----- > From: Jeffrey Winter [mailto:j.winter@...] > Sent: Tuesday, July 23, 2002 9:54 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] HTTP can't support web services > > > A while back, Don Box (of Microsoft) gave a talk in which he stated that > HTTP couldn't support > long-term transactions, one specific reason was because of issues with > intermediaries. > An article about his talk is here: > > http://zdnet.com.com/2100-1105-845220.html > > The specific comment from the article is: > > "...when Web services start running transactions that take some time to > complete over the protocol, the model fails. "If it takes three minutes > for > a response, it is not really HTTP any more," Box said. The problem, said > Box, is that the intermediaries--that is, the companies that own the > routers > and cables between the client and server--will not allow single > transactions > that take this long." > > What exactly is it about the intermediaries that wouldn't allow for a long > transaction time? > > > > Yahoo! Groups Sponsor > ADVERTISEMENT > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > >
In REST, are there any rule that govern who has the ability to create URIs/identifiers? For instance, if I were to use my web browser to access http://www.seairth.com/, my browser didn't create the URI; it was already in existence (and created by the authority/owner of the server to which it points). Now, if that request returns an HTML page that has additional URIs in it (in the form of <a href=''>, for instance), then my browser can use them. Again, the browser did not create these URIs. Now, suppose I submit one of the returned URIs and get back some more HTML. This time, the html contains a form that looks like <form method='get' action='http://www.seairth.com/scripts/process.cgi'>. At this point, the URI given was not created by the browser. However, this time, when the browser submits the form, it appends a query to the end of the URI (e.g. http://www.seairth.com/scripts/process.cgi?id=seairth). According to statements made on this list, the browser has created a new URI/identifier. This means that the browser is identifying a different resource than the one that the server identified. This is unlike all other URIs it was given or used. In terms of REST, is this okay? Or is this issue delegated to the application-level (e.g. http in the example above)? It seems to me that REST would have something to say about this, but what is it? --- Seairth Jacobs seairth@...
By the way, Don is on xml-dev. I suppose we can always ask him what he meant
with that comment (;-)
Ramin
-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Tuesday, July 23, 2002 10:50 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Re: HTTP can't support web services
> An easy solution to Don's problem is to design proper stateful
> web-services (but I'm guessing Don and Microsoft already knew this
(;-)
RosettaNet has a resource-state-alignment transaction model that
works over the Web. It is very compatible with REST, as we've
discussed on this list.
If you know who designed the RNet transaction model, and know where
they work now, you will have the confirmation of your guess.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
I actually did email Box directly this morning and he did respond a moment ago.
To paraphrase him, he said that he was referring to the firewall/proxy infrastructure. So I suppose that this would be correct. If a proxy establishes a connection to some server on your behalf, then it would need to maintain information about how to route an HTTP response back to you. Eventually most proxy servers are going to have to timeout the connection.
In the article he seemed to be talking about routers specifically which don't need to maintain state, just route packets, so I wasn't sure what he was getting at.
I think the article was a bit confusing because there seem to be several issues in play: it's conceivable to construct a service that would have a very long transaction time (such as an "apply for mortgage" service) which might take a day or two to "respond" in some fashion, but Ramin pointed out in an earlier message, to do this under HTTP would require a different mode of thinking through the problem - maybe with a 202 response etc.? On the other hand, if you just have a poorly written service or one that just have "medium"-scale transaction times, maybe there are other approaches.
Is SOAP designed to handle Very Long Transactions directly, ones that could take on the order of days and not minutes?
- Jeff
----- Original Message -----
From: Ramin Firoozye
To: rest-discuss@yahoogroups.com
Sent: Tuesday, July 23, 2002 3:38 PM
Subject: RE: [rest-discuss] Re: HTTP can't support web services
By the way, Don is on xml-dev. I suppose we can always ask him what he meant with that comment (;-)
Ramin
-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Tuesday, July 23, 2002 10:50 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Re: HTTP can't support web services
> An easy solution to Don's problem is to design proper stateful
> web-services (but I'm guessing Don and Microsoft already knew this
(;-)
RosettaNet has a resource-state-alignment transaction model that
works over the Web. It is very compatible with REST, as we've
discussed on this list.
If you know who designed the RNet transaction model, and know where
they work now, you will have the confirmation of your guess.
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Hi Jeffrey, <shameless-plug> Actually, our product (NetGlue) supports this right now. You can create 'component instances' through a single HTTP or SOAP request. It returns an 'instance-id' back to you. The instance stays alive on the server for as long as you want it to (and gets the work done). You can then come back *any* time later, reference the same instance id (through HTTP or SOAP), and see how it's doing. The NetGlue client API does this behind the scenes and supports asynchronous I/O and background thread requests. NetGlue components can be Java, COM, Perl, HTTP requests, SOAP services, or Javascript so even if the underlying code doesn't have this ability, they get it for free. We're working on docs to explain this a little better... BTW: the software's free for developer and personal use. </shameless-plug> Ramin I think the article was a bit confusing because there seem to be several issues in play: it's conceivable to construct a service that would have a very long transaction time (such as an "apply for mortgage" service) which might take a day or two to "respond" in some fashion, but Ramin pointed out in an earlier message, to do this under HTTP would require a different mode of thinking through the problem - maybe with a 202 response etc.? On the other hand, if you just have a poorly written service or one that just have "medium"-scale transaction times, maybe there are other approaches. Is SOAP designed to handle Very Long Transactions directly, ones that could take on the order of days and not minutes? - Jeff
> Is SOAP designed to handle Very Long Transactions directly, ones that could take on the order of days and not minutes. This was certainly in the design goals, and is very possible with SOAP, but I don't think that it 'directly' supports them, because to me supporting 'very long transactions' means asynchronous, or intermittantly connected, messaging. As such, you'd need a message correlation ID, among other facilities, which core SOAP doesn't provide, but does leave hooks for. SOAP itself doesn't mandate any particular architectural style (unlike REST, it isn't one), but it does encourage looking at the world in terms of messages, not state transfers. Cheers,
On 7/23/02 2:55 PM, "Jeffrey Winter" <j.winter@...> wrote: > I actually did email Box directly this morning and he did respond a moment > ago. > > To paraphrase him, he said that he was referring to the firewall/proxy > infrastructure. So I suppose that this would be correct. If a proxy > establishes a connection to some server on your behalf, then it would need to > maintain information about how to route an HTTP response back to you. > Eventually most proxy servers are going to have to timeout the connection. > > ---- > > Still this issue is completely orthogonal to the issue of long-term > transactions. Bottom line, end of story. This is another half-ass Don Box > swipe at HTTP, an attempt to fool the fools into thinking that theres > something wrong with HTTP. Oh, yeah, of course it sucks for transactions, > because we cant keep a connection open. Oooh, shit, HTTP sucks! > > I guess that means that e.g. long-duration HTTP sessions, etc. dont work > either. Weve been fooling ourselves all this time. > > jb > > PS if you sense some rancor here, go reread Dons opus. Theres absolutely > no doubt at all that hes gunning for HTTP, and theres very little doubt (in > my mind anyway) why. >
[Jeff Bone] > PS � if you sense some rancor here, go reread Don�s opus. > There�s absolutely no doubt at all that he�s gunning for HTTP, > and there�s very little doubt (in my mind anyway) why. Was Cringely right? http://www.pbs.org/cringely/pulpit/pulpit20010802.html // mark -
Re: [rest-discuss] Re: HTTP can't support web services>> Still - this issue is completely orthogonal to the issue of long-term transactions. Bottom line, end of story. This is another half-ass Don Box swipe at HTTP, an attempt to fool the fools into thinking that there's something wrong with HTTP. "Oh, yeah, of course it sucks for transactions, because we can't keep a connection open. Oooh, shit, HTTP sucks!" >> I guess that means that e.g. long-duration HTTP sessions, etc. don't work either. We've been fooling ourselves all this time. Okay, on this I agree (if I understand your point): there's nothing about the HTTP protocol per se the rules out long term transactions - and even if the practical support of the protocol demands that connections time out in certain configurations (e.g., if you're using a proxy server) there are patterns of HTTP use that would have the same effect. I guess my follow up question would be then: are these patterns of use being codified anywhere by the REST community? It seems to me one of the reason, among others, why SOAP is gaining traction is that support for problems like these (e.g., routing, security) are going through some level of standardization. See ws-security [1], ws-routing [2]. And are getting built into packages solutions. By the way, I heard Box say that he thought that ws-routing is one of the more interesting/important web services specs under development right now. >> PS - if you sense some rancor here, go reread Don's opus. There's absolutely no doubt at all that he's gunning for HTTP, and there's very little doubt (in my mind anyway) why. Well it certainly seems like they'd be happy to gain control of the interoperability protocols again if that's what you're getting at. [1] http://msdn.microsoft.com/ws/2002/04/Security/ [2] http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp
I'm not sure what Don's problem with HTTP is, but if it had been coming from
someone not associated with Microsoft, I'm sure that particular opinion
would have sunk quietly into the briny deep...
When that Cringley piece first came out, I thought he had lost it. Then I
read about 'Palladium' ...
Hoo boy.
Ramin
-----Original Message-----
From: Mark McEahern [mailto:marklists@...]
Sent: Tuesday, July 23, 2002 1:58 PM
To: rest-discuss@yahoogroups.com
Subject: RE: [rest-discuss] Re: HTTP can't support web services
[Jeff Bone]
> PS � if you sense some rancor here, go reread Don�s opus.
> There�s absolutely no doubt at all that he�s gunning for HTTP,
> and there�s very little doubt (in my mind anyway) why.
Was Cringely right?
http://www.pbs.org/cringely/pulpit/pulpit20010802.html
// mark
-
By the way, I heard Box say that he thought that ws-routing is one of the more interesting/important web services specs under development right now. >> PS - if you sense some rancor here, go reread Don's opus. There's absolutely no doubt at all that he's gunning for HTTP, and there's very little doubt (in my mind anyway) why. Well it certainly seems like they'd be happy to gain control of the interoperability protocols again if that's what you're getting at. [1] http://msdn.microsoft.com/ws/2002/04/Security/ Cool, the security spec really works! I clicked on this link and it told me I don't have permission to read it! (;-) Ramin
From: Jeffrey Winter [mailto:j.winter@...] >> Is SOAP designed to handle Very Long Transactions directly, ones that could take on the order of days and not minutes? >> It's not designed not to ;) Seriously, SOAP+HTTP can be used just fine thanks with something like the ebXML reliable messaging protocol. More specifically, HTTP+SMTP are all you need. With a minute's thought this should be clear to anyone who's ever ordered a book online. There's no a priori requirement for using a single protocol to get the job done. SOAP and reliable messaging protocols are good, but they are gravy for a lot of tasks. I heard a rationale espoused recently for a very big messaging system that a proprietary MOM is a preferable and practical baseline architecture because there is no webservice-like standard for reliable messaging. Now, it's my opinion that ex-cathedra pronouncements about the unsuitability of running highly asynchronous services over the web will tend to lead you into the arms of messaging vendors. But it's for each to decide whether that is harm's way or a righteous path. Bill de hra
Bill de hra wrote: > From: Jeffrey Winter [mailto:j.winter@n...] > >> > Is SOAP designed to handle Very Long Transactions directly, ones that > could take on the order of days and not minutes? > >> > > It's not designed not to ;) > Seriously, SOAP+HTTP can be used just fine > thanks with something like the ebXML reliable messaging protocol. The ebXML/RosettaNet business transaction protocol can work with REST, too. Check this list for previous discussions about REST transactions and state transitions, or Paul Prescod's article: http://www.prescod.net/rest/state_transition.html Or this discussion and its links on Rest Wiki, which is still incomplete but at least suggestive: http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext In most of these discussions, for long transactions, we used the HTTP response as a receipt ack, and a later HTTP interaction for the transaction response. > More specifically, HTTP+SMTP are all you need. With a minute's thought > this should be clear to anyone who's ever ordered a book online. Yeah, no kidding... -Bob Haugen
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > > "...when Web services start running transactions that take some time to > complete over the protocol, the model fails. "If it takes three minutes for > a response, it is not really HTTP any more," Box said. The problem, said > Box, is that the intermediaries--that is, the companies that own the routers > and cables between the client and server--will not allow single transactions > that take this long." > > What exactly is it about the intermediaries that wouldn't allow for a long > transaction time? > DonB is mixing application-level transaction and network-socket-level connection. The problem mentioned with intermediaries refers to network socket level connections. This whole issue comes up when you map application-level concepts of request and response to protocol level concepts of request and response. It becomes worse when you try to do /generic/ requests on top of HTTP which has specific semantics for each of its request message types. Long-lived application transactions are definitely doable with HTTP - wish lists on shopping sites for example - all you have to do is try, and DonB isn't willing to do that.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > However, this time, when the > browser submits the form, it appends a query to the end of the URI (e.g. > http://www.seairth.com/scripts/process.cgi?id=seairth). According to > statements made on this list, the browser has created a new URI/identifier. > This means that the browser is identifying a different resource than the one > that the server identified. This is unlike all other URIs it was given or > used. > > In terms of REST, is this okay? Or is this issue delegated to the > application-level (e.g. http in the example above)? It seems to me that > REST would have something to say about this, but what is it? > I think this is 'okay' - but that it increases coupling between the systems. In some cases you may have no choice, but it is nice to know that there is a simpler more de-coupled approach is available for most cases. I don't think Roy's paper talks about this directly, but it does talk about the critical 'loose coupling' that URI opacity provides. The conclusion that I make from this is that whenever two system coordinate on something which should be loosely coupled, then you should try to make that area of coordination loosely coupled as well. In the case of constructing URIs, then I would interpret that to mean provide an explicit description of the construction rules.
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> > > I don't think Roy's paper talks about this directly, but it does talk about > the critical 'loose coupling' that URI opacity provides. The conclusion that > I make from this is that whenever two system coordinate on something which > should be loosely coupled, then you should try to make that area of > coordination loosely coupled as well. In the case of constructing URIs, then > I would interpret that to mean provide an explicit description of the > construction rules. Let me make sure I have this correct. If a browser were to use a URI as it was given, then this is loose coupling. This is due to the fact that the browser can be entirely brainless and will take whatever it gets. The URI is opaque. On the other hand, if the browser modifies the URI (by adding a query, for instance), then the particular system is not as loosely coupled and the URI is no longer considered to be opaque. This is because the browser and the server now have to agree on a "standard" modification practice (e.g. "?" plus a URL-encoded string where each field is separated by a "&" and each name is separated by it's associated value with a "="), which effectively binds them together. The more loosely coupled the system is, the more RESTlike it is (ignoring all other issues). If this is the case, then does it make sense to always use POST in an html form, regardless of whether the actual request is idempotent (and therefore could be handled with a GET) or not? POST would treat the URI as opaque, whereas the GET would not. POST would be more loosely coupled than GET. Frankly, I agree with this view. Quite coincidentally, I follow this this practice in my web applications. The only way a URL contains a query string is if the server created it. As far as the browser is concerned, the URL is entirely opaque. What would people who say that POST is often misused say about this? (I can already imagine...) --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > The more loosely coupled the system is, the more RESTlike it is (ignoring > all other issues). No, the more RESTlike a system is, the more RESTlike it is. You have to measure against the components identified by the REST architectural style (client, gateway, origin server, intermediary, stateless messages, resources/representations, etc. etc.) to be RESTlike. > > If this is the case, then does it make sense to always use POST in an html > form, regardless of whether the actual request is idempotent (and therefore > could be handled with a GET) or not? GET .vs. POST isn't about idempotent or not, its about read .vs. write. > POST would treat the URI as opaque, > whereas the GET would not. POST would be more loosely coupled than GET. POST treats the URI as opaque, but if the resource you want to interact with is identified by URI+message.body then you have very tight coupling going on. If you /did/ use POST all the time - then you lose the addressability aspect, since servers and clients need to know both URI + body in order to do a retrieval (and you'd need yet another piece to indicate that POST isn't trying to modify, its trying to read). In a Web browser the content of the POST is constructed according to similar rules as the URL. This also results in coupling between server and client - but it is easier to manage, since the submitted content (the message body) has a declared type identified by the Content-Type header in the request. And it isn't /required/ to be "application/x-www-form-urlencoded" you can POST text/xml or image/jpg or whatever you want . The POST and GET are values exposed in HTTP messages in order to allow at least a minimal amount of processing on /any/ message encountered by any component. > > Frankly, I agree with this view. Quite coincidentally, I follow this this > practice in my web applications. The only way a URL contains a query string > is if the server created it. As far as the browser is concerned, the URL is > entirely opaque. What would people who say that POST is often misused say > about this? (I can already imagine...) It's a better system that keeps URI construction close to the origin server. How do you provide discovery of URIs for resources that are logically related to resources on other systems? For example, if I have the UPC code for a pair of tennis shoes, and you have tennis shoes for sale, how do I learn what your URI is for that particular shoe?
["Jeffrey Winter"] > Long-lived application transactions are definitely doable with HTTP - wish > lists on shopping sites for example - all you have to do is try, and DonB > isn't willing to do that. Is Box saying that the problem with doing long-lived application transactions over HTTP that there is no standard, canonical way to do it? Or is he saying it's technically impossible? Even if he isn't saying the former, is it true? If so, are there efforts to standardize these things? // mark -
Mike Dierken wrote: > DonB is mixing application-level transaction and network-socket-level > connection. The problem mentioned with intermediaries refers to network > socket level connections. Per the recent conversation on socket-level aspects of HTTP, it strikes me that they are deliberately not a part of the protocol. There are actually two protocols, an application-level protocol defined by the HTTP RFCs and a socket-level protocol defined by standard practice. Don Box's comment refers to the socket-level protocol. At the same time, limited duration of connections is a deliberate part of the REST architectural style. It is expected that HTTP is mainly used for hypertext documents, not messages, and it is reasonable for proxies to assume that well-behaved connections will be short lived. Short lived connections follow from stateless transactions, and stateless transactions follow from HTTP's scalability requirements. HTTP web services should be architected to avoid the need for long lived streams because long lived streams expend too many server resources. Web applications that need long lived streams imply a less scalable web! - Lucas
Try: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp -- Kind Regards, Serdar K. Ramin, said: RF> Cool, the security spec really works! RF> I clicked on this link and it told me I don't have permission to read it! RF> (;-)
On Wed, 24 Jul 2002, Mark McEahern wrote: > Is Box saying that the problem with doing long-lived application > transactions over HTTP that there is no standard, canonical way to do it? > Or is he saying it's technically impossible? > > Even if he isn't saying the former, is it true? If so, are there efforts to > standardize these things? I think he's referring to the unreliability of HTTP streams, specifically the fact that proxies are free to cut off streams that last too long. The canonical approach, I think, is to keep streams and transactions orthogonal. A persistent stream has to be considered a convenience, and not be used as required support to maintain transaction state. - Lucas
I just received the latest issue in the mail - it includes a paper from Fielding and Taylor entitled "Principled Design of Modern Web Architecture". Seems to be an overview of REST principles, illustrating how other network-based architectural styles (client-server, virtual machine, etc) are merged to form a REST architectural style.
On Tue, 23 Jul 2002, Jeff Bone wrote: > I'll admit that I'm not a Don Box fan by any stretch of the imagination, but > this comment of his is so obviously braindead wrong that it's embarrassing > even for him. He's really setting himself up as an apologist for SOAP-RPC. There are probably other technical arguments against HTTP that are cluesome -- too bad he's not finding them. In my experience as a REST acolyte the biggest lesson I've learned is that you can't go around HTTP, you have to go through it. All new protocols that fail to understand why HTTP works will ultimately fail to add anything new on an architectural level.
Yah, Roy said he updated it recently. An older version is referenced from the RestResources page on the REST Wiki. MB On Wed, Jul 24, 2002 at 08:42:40AM -0400, John Evdemon wrote: > I just received the latest issue in the mail - it includes a paper from Fielding and Taylor entitled "Principled Design of Modern Web Architecture". > > Seems to be an overview of REST principles, illustrating how other network-based architectural styles (client-server, virtual machine, etc) are merged to form a REST > architectural style. > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
So close and yet so far: http://www.dentedreality.com.au/xoomle/docs/ http://xoomle.dentedreality.com.au/?key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality ==> method=doGoogleSearch.
David Orchard wrote:
>
> .... To compare, if I were to document REST as it is
> done today, I'd probably ignore HTTP PUT/DELETE and I'd say that GET/POST
> can be used interchangeably except for some bookmarking applications where
> GET is a little better.
That's a severe misrepresentation of the way the Web is used today. GET
is used whenever safe references are important. Bookmarking is a tiny
example. I can send you this link because of GET:
http://search.bea.com/query.html?qt=REST
I didn't bookmark it and probably you won't either. That fact that I can
email it to you -- communicate it to you -- is what is important. You
can interoperably, using any Web client, anywhere in the world,
dereference that link. Bookmarking is a side effect of that general
improvement in interoperability. I am confident that BEA's web designers
understand this issue because they work with these safe information
references ("hyperlinks") all day.
> ... And I'd say that CGIs are great.
CGIs *can be* great. I may be wrong, but I think that you're
interpreting something from this mail by Roy Fielding. I've seen this
post misinterpreted (IMO) in other places so I'm going to address it
once and for all.
* http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html
Note the last sentence: 'The fact of the matter is that
most CGI scripts are not HTTP compliant. Most CGI scripts, in fact,
provide interfaces to applications that suck. The "G" stands for
Gateway.
What people should realize is not that "CGI scripts should be banned",
but rather that if the CGI script is written such that it behaves
like a proper Web interface, then it won't suck.'
CGI is a *gateway* interface. You can either use it to just publish some
functionality through a URL (tunnelling) or you can use it to build a
proper gateway between your software and the Web: URIs for all
resources, hyperlinks as the engine of application state, etc. Some of
the most REST-ful applications in the world are CGI and many of the
least are not.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Xoomle is really cool!
Here are some of my ideas for improvement in order of importance.
* Rather than "method=", I'd say that there should be three top-level
URIs. Among reasons this is better in theory, it is easier to build HTML
forms that have different ACTION= attributes. This is the only thing
that would stop the REST community from using XooMLe as a perfect case
study. It's a tiny thing to change but sort of goes to the heart of REST
philosophy. Priority = 8 out of 10.
* I'd suggest that the key should be passed using HTTP authentication
(at least as an option). Then developers could share references without
sharing their keys. As I recall, if you really want, you can embed HTTP
authentication information in URIs *anyhow*. Priority = 7/10
* <?xml-stylesheet?> could be used to provide a nice HTML-based
rendition. I would be happy to provide this XSLT stylesheet. Priority =
6/10
* I'd use a namespace on the returned XML (with default prefix) so that
it is a little easier to associate namespace-triggered behaviour with
the XML. It would just take one attribute value to be "namespace aware".
6/10
* It would be great if you would publish a schema. I believe there is
one embedded in Google's WSDL but you could extract that modulo
copyright issues. You could also use a schemaLocation attribute to point
to it. 6/10
* <url>...</url> could become <url xlink:href="...">...</url>. I have
mixed feelings about XLink but it *is* the standard way to do linking in
XML. More or less this will endear you to people who have developed
XLink processors. 5/10
* You could build on the way HTTP/REST works to add some interesting
features.
1. For instance you could embed a link to the cached page in each item:
<URL>http://www.cse.unsw.edu.au/~norman/</URL>
<cached>http://xooomle..../cached?url="http://www.cse.unsw.edu.au/~norman/"</cached>
2. You could have a link from each page that is a "sub-query". So let's
say I send you a link like
"http://.../?hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul", it would
embed within it a link like this:
* <subquery
xlink:href="http://.../doGoogleSearch/hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul/"/>
Then I could do a *subquery* just by appending "?q=Prescod". By subquery
I mean that it would be interpreted as the same as "Paul+Prescod". This
somewhat goes back to the first issue: you need a way for the method to
be part of the path, not part of the query, but you also need a way for
a representation for the "query" to be part of the path. Once it is
moved into the path it is opaque so it doesn't matter if you use some
compression scheme or something:
* <subquery
xlink:href="http://.../doGoogleSearch/fj4fjefe0fa9e8w09i03fj/"/>
====
Now that you can think of the Google database as a set of resources,
you'll find that there are a bunch of ideas like this where we can do
interesting things by associating these resources.
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
I am very interested in the subquery idea. I am working on something similar. PPrescond mentioned three top level urls to expose the different functionality like spellchecking and searches and I'd definitely agree. Something like: http://xoomle.../searches/Paul+Prescond would be very nice. You might imagine a folder on a hard drive called 'searches' and in this folder is a 'file' corresponding to every conceivable Google search. It would be nice to be able to search this folder--that is search searches. Especially if information can be stored about searches indicating how successful they are. (Find me searches containing the word Prescond where the last time the search was performed X condition was met). This makes no sense, but that's okay. I just like the idea of making every search a real URL and being able to dynamically extend a search by appending to a URL. Keep up the good work. - codaland @ http://codaland.blogspot.com --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > Xoomle is really cool! > > Here are some of my ideas for improvement in order of importance. > > * Rather than "method=", I'd say that there should be three top- level > URIs. Among reasons this is better in theory, it is easier to build HTML > forms that have different ACTION= attributes. This is the only thing > that would stop the REST community from using XooMLe as a perfect case > study. It's a tiny thing to change but sort of goes to the heart of REST > philosophy. Priority = 8 out of 10. > > * I'd suggest that the key should be passed using HTTP authentication > (at least as an option). Then developers could share references without > sharing their keys. As I recall, if you really want, you can embed HTTP > authentication information in URIs *anyhow*. Priority = 7/10 > > * <?xml-stylesheet?> could be used to provide a nice HTML-based > rendition. I would be happy to provide this XSLT stylesheet. Priority = > 6/10 > > * I'd use a namespace on the returned XML (with default prefix) so that > it is a little easier to associate namespace-triggered behaviour with > the XML. It would just take one attribute value to be "namespace aware". > 6/10 > > * It would be great if you would publish a schema. I believe there is > one embedded in Google's WSDL but you could extract that modulo > copyright issues. You could also use a schemaLocation attribute to point > to it. 6/10 > > * <url>...</url> could become <url xlink:href="...">...</url>. I have > mixed feelings about XLink but it *is* the standard way to do linking in > XML. More or less this will endear you to people who have developed > XLink processors. 5/10 > > * You could build on the way HTTP/REST works to add some interesting > features. > > 1. For instance you could embed a link to the cached page in each item: > <URL>http://www.cse.unsw.edu.au/~norman/</URL> > > <cached>http://xooomle..../cached? url="http://www.cse.unsw.edu.au/~norman/"</cached> > > 2. You could have a link from each page that is a "sub-query". So let's > say I send you a link like > "http://.../?hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul", it would > embed within it a link like this: > > * <subquery > xlink:href="http://.../doGoogleSearch/hl=en&ie=ISO-8859- 1&method=doGoogleSearch&q=Paul/"/> > > Then I could do a *subquery* just by appending "?q=Prescod". By subquery > I mean that it would be interpreted as the same as "Paul+Prescod". This > somewhat goes back to the first issue: you need a way for the method to > be part of the path, not part of the query, but you also need a way for > a representation for the "query" to be part of the path. Once it is > moved into the path it is opaque so it doesn't matter if you use some > compression scheme or something: > > * <subquery > xlink:href="http://.../doGoogleSearch/fj4fjefe0fa9e8w09i03fj/"/> > > ==== > > Now that you can think of the Google database as a set of resources, > you'll find that there are a bunch of ideas like this where we can do > interesting things by associating these resources. > -- > Come discuss XML and REST web services at: > Open Source Conference: July 22-26, 2002, conferences.oreillynet.com > Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Mark McEahern" <marklists@...> > > Even if he isn't saying the former, is it true? If so, are there efforts to > standardize these things? There is something called AS2 which is a 'standard' mechanism for exchanging busines documents with MIME over HTTP. AS1 is MIME over SMTP. I haven't spent much time examining AS2 - perhaps BobH can fill us in - but it looks like a protocol on top of HTTP. It probably can be easily re-factored into a more REST-like approach, but until I get paid to do that sort of thing, I don't have the time right now to attempt that... http://www.uc-council.org/news/ne_081401.html
Seairth Jacobs wrote: > >... > > In terms of REST, is this okay? Or is this issue delegated to the > application-level (e.g. http in the example above)? It seems to me that > REST would have something to say about this, but what is it? This is related to the ongoing debate on opaque URIs. I think that the rough concensus is that this is okay but you lose some benefits of the Web if you rely on it too heavily. In particular, hyperlinks are great because they are discoverable. Query parameters require a little more a priori knowledge of how to construct the query values. On the other hand, rendering everything as hyperlinks can be unacceptably inefficient sometimes. For instance, to find the kinkos in a particular zip code, you could either use a query parameter or build a big hypertext document that associates zip codes with documents. The former is better from a performance point of view. The latter is better from a discovery and "semantic web" point of view. Given sufficient time and money, I would suggest you do both. Otherwise, just weigh the costs and benefits and do what makes sense. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Lucas Gonze" <lucas@...> > > Short lived connections follow from stateless transactions, and stateless > transactions follow from HTTP's scalability requirements. I don't believe that stateless transactions imply short lived connections. Short lived connections are allowable as a resource saving optimization without impacting the logic of the application sending the messages. Stateless transactions allow you to do multiple request/response on a single network connection - without being stateless, the protocol designer might be tempted on associated security credentials with the socket connection, which prevents that resource being used by multiple users at once (I think IMAP has a problem like this, where you have to close the socket & reopen it to view a different inbox). > HTTP web > services should be architected to avoid the need for long lived streams > because long lived streams expend too many server resources. Web > applications that need long lived streams imply a less scalable web! I sort of agree - apps that just won't work without long-lived streams are going to suffer, but allowing long-lived streams is a nice optimization that improves scalability (from a performance point of view).
----- Original Message ----- From: "nixerman" <nixerman@...> To: <rest-discuss@yahoogroups.com> Sent: Wednesday, July 24, 2002 1:53 PM Subject: [rest-discuss] Re: Xoomle review > > I am very interested in the subquery idea. I am working on something > similar. PPrescond mentioned three top level urls to expose the > different functionality like spellchecking and searches and I'd > definitely agree. Something like: > > http://xoomle.../searches/Paul+Prescond > You'd probably want to use %20 rather than '+' if it is part of a path segment (if you mean that the '+' is a space character).
me: > > services should be architected to avoid the need for long lived streams > > because long lived streams expend too many server resources. Web Mike Dierken: > > applications that need long lived streams imply a less scalable web! > I sort of agree - apps that just won't work without long-lived streams are > going to suffer, but allowing long-lived streams is a nice optimization that > improves scalability (from a performance point of view). Interesting. Don't know if my interpretation of Roy's thesis(*) is right then. My reading was that 'scalability' meant the quantity of clients that a single server can handle. - Lucas (*) Can't this get another name by now? This one is awkward. I don't know Roy, so I don't like saying "Roy's thesis" with a first name, but "Roy Fielding's thesis" is too formal, and quoting the whole title makes no sense, and "The Thesis" is funny but too biblical. Also, I think that attributing REST purely to the thesis is wrong -- the idea is really a group invention of the HTTP 1.1 drafters.
Paul,
You didn't refute my point at all, which is that REST is not used
appropriately in many ways on the web but we don't document all the
inappropriate usages in the web architecture document and Roy's thesis. We
still can talk about the architectural principles that the web embodies, as
described by REST. Mark is proposing that the w3c web services group should
only document those architectures that have running code, and it should
document all the usages. And he's specifically pointing out areas where
SOAP is used in different ways that he finds "sucky". If the criteria is
running code, I would argue that a web architecture (aka REST) description
would include all the inappropriate uses. And the "running code criteria"
precludes things like SOAP 1.2 which don't have much running code yet. So
the running code criteria doesn't seem useful to specify architectures to
help people build better web/web services systems and standards.
So it's my opinion that the w3c web services architecture group should spend
some of it's time working on web services architectural principles, not
simply documenting what current systems do. And the same goes for the TAG
wrt web principles.
Just because I mention REST usage (the generic method usage) and CGI usage
does not mean I want a REST vs whatever discussion. In fact, I'm utterly
and completely exhausted by that particular topic area. Roy's quote is the
reason why I mentioned CGI and I think his quote supports the notion that
some running code "sucks". And I again assert that w3c groups shouldn't
document the sucky usages in our architecture documents, except perhaps as
being sucky. But again again again, this is not a REST discussion per se.
I don't intend to follow through much more with this discussion about what
the group is going to do. I'm more interested in writing up text to
describe the architecture and discussing the text of such. "Do stuff rather
than talk about doing stuff".
Cheers,
Dave
> -----Original Message-----
> From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On
> Behalf Of Paul Prescod
> Sent: Wednesday, July 24, 2002 10:31 AM
> To: David Orchard
> Cc: 'Mark Baker'; www-ws-arch@...; rest-discuss@yahoogroups.com;
> fielding@...
> Subject: Clarification on REST, GET and CGI
>
>
>
> David Orchard wrote:
> >
> > .... To compare, if I were to document REST as it is
> > done today, I'd probably ignore HTTP PUT/DELETE and I'd say
> that GET/POST
> > can be used interchangeably except for some bookmarking
> applications where
> > GET is a little better.
>
> That's a severe misrepresentation of the way the Web is used
> today. GET
> is used whenever safe references are important. Bookmarking is a tiny
> example. I can send you this link because of GET:
>
> http://search.bea.com/query.html?qt=REST
>
> I didn't bookmark it and probably you won't either. That fact
> that I can
> email it to you -- communicate it to you -- is what is important. You
> can interoperably, using any Web client, anywhere in the world,
> dereference that link. Bookmarking is a side effect of that general
> improvement in interoperability. I am confident that BEA's
> web designers
> understand this issue because they work with these safe information
> references ("hyperlinks") all day.
>
> > ... And I'd say that CGIs are great.
>
> CGIs *can be* great. I may be wrong, but I think that you're
> interpreting something from this mail by Roy Fielding. I've seen this
> post misinterpreted (IMO) in other places so I'm going to address it
> once and for all.
>
> * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html
>
> Note the last sentence: 'The fact of the matter is that
> most CGI scripts are not HTTP compliant. Most CGI scripts, in fact,
> provide interfaces to applications that suck. The "G" stands for
> Gateway.
> What people should realize is not that "CGI scripts should be banned",
> but rather that if the CGI script is written such that it behaves
> like a proper Web interface, then it won't suck.'
>
> CGI is a *gateway* interface. You can either use it to just
> publish some
> functionality through a URL (tunnelling) or you can use it to build a
> proper gateway between your software and the Web: URIs for all
> resources, hyperlinks as the engine of application state, etc. Some of
> the most REST-ful applications in the world are CGI and many of the
> least are not.
> --
> Come discuss XML and REST web services at:
> Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
> Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
>
>
Not having picked up a copy of Software Development magazine for a while, I recently stumbled across David Carlson's series of articles on 'Modeling XML Applications with UML' [1]. From there I read more on MDA [2], [3] and additional papers by Carlson [4] as well as the OMG's release of the EDOCS (Enterprise Distributed Object Computing) UML profile [5] which, as is mentioned below is undergoing a platform specific mapping (PSM) to Web Services. This got my interest and I wondered if it might be worth looking into further from the perspective of using a REST approach as a PSM. So before I get too carried away I thought I would ask for the groups input on this, has anyone with a deeper understanding of MDA/EDOC/etc had thoughts along these lines? Robert PS Sometimes I wish Fielding had coined a name other than REST, as it makes Google searching somewhat more difficult! [1] http://www.sdmagazine.com/documents/sdm0202f/ (registration required) or the Feb, Apr, May Jun 2002 issues of SD [2] MDA home page - http://www.omg.org/mda [3] Model Driven Architecture - A Technical Perspective - http://www.omg.org/cgi-bin/doc?ormsc/01-07-01.pdf [4] http://www.xmlmodeling.com/articles/ [5] http://www.omg.org/cgi-bin/doc?ptc/02-02-05.pdf (The UML Profile for EDOC is used to build PIMs (Platform Independent Model) of enterprise applications. It defines representations for entities, events, process, relationships, patterns, and an Enterprise Collaboration Architecture. As a PIM profile, it needs mappings to platform-specific profiles. A mapping to Web Services is underway now; additional mappings will follow. )
On Tue, Jul 23, 2002 at 09:03:31AM -0700, Paul Prescod wrote: > No, it was an offlist discussion and the document doesn't mention REST: Eek, sorry. That explains why I couldn't find it in my rest-discuss folder. 8-) > I don't know whether there is really anything we disagree upon. My > opinions on MEP are as follows: Yah, we're in agreement. Just a couple of observations ... > * request/response is the best choice of primitive MEP for a system > that depends heavily on the results of dereferencing URIs. Plus, today's > Internet topology makes request/response essentially always available > but bidirectional asynch is much harder to roll out. Businesses and ISPs > mostly do not want people outside making connections in, therefore the > only way to get information in is through a response to an outgoing > connection. (with the exception of email, but we know how happy > businesses are with random people sending email to their employees) Maybe just a terminology issue, but I don't know that anybody's questioning request/response. All messages can be characterized as one of those. I think the simplicity you're referring to, has to do with the implicit correlation of requests and responses by virtue of them reusing the same connection, and that each request has a single response. I concur with that. > * A highly interoperable system like the Web could have multiple MEPs, > as long as *all server implementations* support all of them. If you must > "configure" your client to contact a server by informing it what MEP to > use then you are starting down a slippery slope that ends in WSDL and > UDDI -- not as options but as requirements for getting actual work done. > This is what I object to in SOAP. MEPs don't do anything except describe ways in which the underlying protocol can be used. So there's no issue of extended agreement, since by virtue of using a protocol, you already know what needs to be known in order to support any MEP that fits. This isn't quite as straightforward as it sounds. For example, one could built a multicast MEP with HTTP. Obviously HTTP doesn't support that by itself, but by using a URI to identify a multicast group, then defining what the HTTP methods should do on it (e.g. GET blocks until all members of the group have responded, then returns a multipart message/http envelope - or whatever), you have built something new that can be deployed without new agreement. > * Nevertheless, if a system like the Web has only a single MEP, others > can built on top of it. Whether these others are standardized or not is > orthogonal to whether they are primitive. At the very least, > notification should be standardized. Making new MEPs primitive is > probably too difficult at this point. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Fri, Jul 19, 2002 at 11:43:43AM -0700, Mark Nottingham wrote: > I'm thinking we should get a patch to Apache together... this would make > the relationship between the resources explicit, helping Google, etc. if > they want to take advantage of the info. > > Thoughts? Yah, for sure. Let me know how I can help. I'd love to learn how to develop an Apache module. I've got other ideas for them too. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
David Orchard wrote: > > Paul, > > You didn't refute my point at all, which is that REST is not used > appropriately in many ways on the web but we don't document all the > inappropriate usages in the web architecture document and Roy's thesis. I didn't intend to refute your point. I wanted to correct a persistent misinterpretation that Roy Fielding said something against CGI or against "excessive gatewaying". Hopefully he'll correct me if I'm wrong but I think that his opinion is that gatewaying (CGI or whatever) is the right way to integrate non-Web systems with the Web and is a core part of web architecture. You have repeatedly cited that message in a manner I believe to be incorrect and I felt it was necessary to inform you (no matter what the topic of discussion). -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
----- Original Message ----- From: "Lucas Gonze" <lucas@...> > > Interesting. Don't know if my interpretation of Roy's thesis(*) is right > then. My reading was that 'scalability' meant the quantity of clients > that a single server can handle. For me - and this isn't directly reflecting the wording in The Thesis (tm) - scalability has technology aspects and social/organizational aspects. Pure performance, number of clients or 'participating nodes', amount of data, differing data types, etc. are some of the technical scalability areas, whereas the number of organizational domains that can participate in another aspect of scalability. Anyway... as long as multiple messages on one connection is a performance enhancement, rather than a requirement for basic functionality, I'm not too worried about it. As a note - which you are probably familiar with - it's not too difficult to get on the order of 10K concurrent connections on a good size machine. This isn't the same as 10K full-bore, saturated data streams, but it is a boundary condition to be aware of.
hmm. Roy said that many CGI scripts suck because they don't implement REST properly. Don't think I'm misquoting him. I'm pointing out that we don't look at the sucky CGI scripts when determine web architecture because, well, they suck. Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On > Behalf Of Paul Prescod > Sent: Wednesday, July 24, 2002 9:13 PM > To: David Orchard > Cc: www-ws-arch@...; rest-discuss@yahoogroups.com; > fielding@... > Subject: Re: [rest-discuss] RE: Clarification on REST, GET and CGI > > > > David Orchard wrote: > > > > Paul, > > > > You didn't refute my point at all, which is that REST is not used > > appropriately in many ways on the web but we don't document all the > > inappropriate usages in the web architecture document and > Roy's thesis. > > I didn't intend to refute your point. I wanted to correct a persistent > misinterpretation that Roy Fielding said something against CGI or > against "excessive gatewaying". Hopefully he'll correct me if > I'm wrong > but I think that his opinion is that gatewaying (CGI or > whatever) is the > right way to integrate non-Web systems with the Web and is a core part > of web architecture. You have repeatedly cited that message > in a manner > I believe to be incorrect and I felt it was necessary to > inform you (no > matter what the topic of discussion). > -- > Come discuss XML and REST web services at: > Open Source Conference: July 22-26, 2002, conferences.oreillynet.com > Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/ > >
Hmm, I've got an old book that explains them... will dig... ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Wednesday, July 24, 2002 8:45 PM Subject: Re: [rest-discuss] Content-Location and Apache's mod_dir > On Fri, Jul 19, 2002 at 11:43:43AM -0700, Mark Nottingham wrote: > > I'm thinking we should get a patch to Apache together... this would make > > the relationship between the resources explicit, helping Google, etc. if > > they want to take advantage of the info. > > > > Thoughts? > > Yah, for sure. Let me know how I can help. I'd love to learn how to > develop an Apache module. I've got other ideas for them too. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
As I was thinking about whether long-lived transactions can be done with HTTP or not - from that message with DonB's comments - I thought of some ideas that may help communicate the ideas behind REST. A business protocol - like sending and receiving purchase orders and invoices - looks like a really simple thing to do with HTTP. You just send the purchase order in a request and get the purchase order acknowledgement in the response. The problem with this is that the idea that you are sending documents with HTTP is incorrect. A /messaging/ protocol would be appropriate to send documents with. For HTTP, what you are sending are messages /about a resource/. A business protocol is an abstract conceptual thing - with concepts like purchase order, invoice, etc. Resources are also abstract conceptual things - they can represent anything, even things /before/ they actually 'exist'. When you use HTTP to implement business protocols, the messages you send will be about resources that you and your partners have agreed are necessary in order to conduct business. The HTTP message will be /about/ a purchase order, it won't /be/ a purchase order. For example, a business protocol may specify that a PO has a PO-ACK to confirm its receipt and an Invoice to request payment (ignoring the role-dependent document naming issues). Rather than describe who sends what and when, an HTTP based business protocol would describe what documents (and other pieces) are resources and who is responsible for creating them and what operations are legal at certain points in the transaction. With this approach the resource can have an identifier regardless of how many messages have been exchanged and the resource can 'exist' independent of the exchange of content. For example, a big partner could pre-allocate a range of document IDs for their small partners and over time these would be echoed back to the big partner - the resource identifier exists and is valid to talk about and message about independent of any exchange of content. I have a growing sense that systems built on REST principles tend to not look like document messaging systems - you tend to interact with documents, rather than send and receive documents (where 'document' is a higher level concept like purchase order, etc.). Anyway... just some thoughts.
> From: David Orchard [mailto:dorchard@...] > > hmm. Roy said that many CGI scripts suck because they don't > implement REST properly. Don't think I'm misquoting him. > I'm pointing out that we don't look at the sucky CGI scripts > when determine web architecture because, well, they suck. David, Yes, on the other hand worst practices and antipatterns are highly valuable guides to developers in the trenches, especially given the amount of trench and the way people tend to cut and paste web systems together (CGI being a prime example). For example, saying it's better to not invent a new URI scheme is not quite the same as saying an arbitrary new scheme sucks (cue: reason). As one example, the OO world has learned much via antipatterns. Today, I suggest that saying non RESTful CGIs suck is less useful that concrete examples; REST is not exactly mainstream thinking yet. There's a good amount of physical architecture in the world that is based on what not to do as much as what to do. One thing the TAG could say to the web community is, look we can't do it all, you guys start writing the anti-patterns down and let us concentrate on the architecture in a positive form. regards, Bill de hra .. Propylon www.propylon.com
I apologize for cross-posting. It's just that the CGI misunderstanding has come up in other forums by people who watch rest-discuss. Bill, David was not discussing CGI in his role on the TAG. I proposed no action item for him. I just wanted to correct a misunderstanding. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > > As I was thinking about whether long-lived transactions can be done with > HTTP or not - from that message with DonB's comments - I thought of some > ideas that may help communicate the ideas behind REST. > > A business protocol - like sending and receiving purchase orders and > invoices - looks like a really simple thing to do with HTTP. You just send > the purchase order in a request and get the purchase order acknowledgement > in the response. The problem with this is that the idea that you are sending > documents with HTTP is incorrect. A /messaging/ protocol would be > appropriate to send documents with. For HTTP, what you are sending are > messages /about a resource/. > A business protocol is an abstract conceptual thing - with concepts like > purchase order, invoice, etc. Resources are also abstract conceptual > things - they can represent anything, even things /before/ they actually > 'exist'. > > When you use HTTP to implement business protocols, the messages you send > will be about resources that you and your partners have agreed are necessary > in order to conduct business. The HTTP message will be /about/ a purchase > order, it won't /be/ a purchase order. > For example, a business protocol may specify that a PO has a PO-ACK to > confirm its receipt and an Invoice to request payment (ignoring the > role-dependent document naming issues). Rather than describe who sends what > and when, an HTTP based business protocol would describe what documents (and > other pieces) are resources and who is responsible for creating them and > what operations are legal at certain points in the transaction. With this > approach the resource can have an identifier regardless of how many messages > have been exchanged and the resource can 'exist' independent of the exchange > of content. > > For example, a big partner could pre-allocate a range of document IDs for > their small partners and over time these would be echoed back to the big > partner - the resource identifier exists and is valid to talk about and > message about independent of any exchange of content. > > I have a growing sense that systems built on REST principles tend to not > look like document messaging systems - you tend to interact with documents, > rather than send and receive documents (where 'document' is a higher level > concept like purchase order, etc.). > > Anyway... just some thoughts.
My apologies for the previous message which was due to my inexperience with Yahoo. The comment I wished to make with respect to the question of processing documents is : My understanding of the model is : The resource is the "trade" between the purchaser and the supplier. The "trade" records progressively more and more information as the state of the "trade" changes over time. The puchase order, payments, etc, are messages that change the state of the trade. The trade can also contain at any one time, information that describes how to make a valid state change from the current state. In other words, it can contain information that allows the customer to acknowledge receipt of the item, or for the supplier to send the bill, or for either to cancel the trade. The question that this raises in my mind is that if the "trade" is addressed through a single URI, how is the view of each party, the supplier or the purchaser, restricted to the state changes that they can make. Bill
"S. Mike Dierken" wrote: > As I was thinking about whether long-lived transactions can be done with > HTTP or not - from that message with DonB's comments - I thought of some > ideas that may help communicate the ideas behind REST. Mike, these are really interesting ideas. Your ideas and mine are getting much close to convergence. I'll try some tweaks below and see if we can do a complete mind meld. > A business protocol - like sending and receiving purchase orders and > invoices - looks like a really simple thing to do with HTTP. You just send > the purchase order in a request and get the purchase order acknowledgement > in the response. The business protocol for purchase orders is Offer-Acceptance. Sending and receiving is only the beginning of the business protocol. A purchase order is an offer to buy. You do want to get a receipt acknowledgment, but the receipt acknowledgment may or may not constitute formal acceptance. Thus the discussions we've had on this list about acceptance as a separate-but-related possibly much later interaction. When you send a PO in a request and get a receipt ack in the response, the PO resource is in the "Offered" state, but most likely not yet in the "Accepted" state. > The problem with this is that the idea that you are sending > documents with HTTP is incorrect. A /messaging/ protocol would be > appropriate to send documents with. For HTTP, what you are sending are > messages /about a resource/. > A business protocol is an abstract conceptual thing - with concepts like > purchase order, invoice, etc. This is a really important insight. A purchase order is an economic contract. Each purchase order line item represents two or more economic commitments: usually a commitment from one party to deliver some goods or services, and a commitment from the other party to pay for them. In a negotiation situation, there could be several messages or documents-sent-over-the-wire involved in coming to agreement on those commitments. The resource would represent the current states of those commitments - although the audit trail of documents sent over the wire could also be saved as dependent resources. > When you use HTTP to implement business protocols, the messages you send > will be about resources that you and your partners have agreed are necessary > in order to conduct business. The HTTP message will be /about/ a purchase > order, it won't /be/ a purchase order. Yes! Excellent! I think of each message as a speech act in a conversation about an economic exchange. The speech acts may change the states of resources involved in the exchange. The economic exchange conversation has stages, for example: * agreeing on commitments - promises to deliver goods and services and to pay for them; * delivering the goods or services and payments and agreeing that the commitments were fulfilled (or not). > Rather than describe who sends what > and when, an HTTP based business protocol would describe what documents (and > other pieces) are resources and who is responsible for creating them and > what operations are legal at certain points in the transaction. I think the preceding statement needs some rewording, but the idea is correct. "Legality" and "certain points" would best be defined in terms of states of resources involved in the economic exchange. For example, don't deliver the goods if the order is in the Rejected state. Or, you can't cancel the order if the goods have been shipped. > Anyway... just some thoughts. Good ones! Thanks, Bob Haugen
"S. Mike Dierken" wrote: > > From: "Mark McEahern" <marklists@m...> > > are there efforts to standardize these things? > > There is something called AS2 which is a 'standard' mechanism for exchanging > busines documents with MIME over HTTP. AS1 is MIME over SMTP. I haven't > spent much time examining AS2 - perhaps BobH can fill us in - but it looks > like a protocol on top of HTTP. I'm most familiar with the efforts in ebXML and UN/CEFACT to standardize business protocols. AS2 was a predecessor. For example, the Drummond group, conductor of the test in the UCC press release, was heavily involved in ebXML. And UCC has said that they are migrating to ebXML, too. I've followed (with increasing personal involvement) several generations of standardization efforts for business protocols. As far as I know, those efforts began in the Telecommunication Management Forum, then moved to RosettaNet, then to UN/CEFACT and ebXML, and then to UN/CEFACT eBTWG. Here is a document that describes UN/CEFACT transaction and interaction patterns: http://www.gefeg.com/tmwg/files/Chapter%208%20MetamodelR10.pdf UN/CEFACT intends for their patterns to be technology-independent. I think those transaction patterns can be refactored into REST. For example, one aspect they discuss with some transaction patterns is "residual effects", as in the formation of business contracts and commitments. I think REST resources are the embodiment of those residual effects. UN/CEFACT eBTWG is also developing a standard set of economic elements for business exchanges that could be the basis for a standard set of REST resources. It's not soup yet, but I'll post something here and on REST-Wiki when it is. > It probably can be easily re-factored into a > more REST-like approach, but until I get paid to do that sort of thing, I > don't have the time right now to attempt that... Same for me. I just finished helping a company develop a demo of Web contract negotiation that was fairly RESTful, so we'll see if they can sell it to their prospects. It will be proprietary, though - unfortunately. In the meantime, I pick away at the problem in these discussions...but would also be interested in a group development project using simple free tools. -Bob Haugen
> Here is a document that describes UN/CEFACT transaction and > interaction patterns: > http://www.gefeg.com/tmwg/files/Chapter%208%20MetamodelR10.pdf Wrong, wrong wrong! This is the patterns section: http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf Now, if I could do a PUT to revise the previous message, ... Sorry about that, Bob Haugen
"oldieshome2002" <bill.oldroyd@b...> wrote: > The comment I wished to make with respect to the question of > processing documents is : > > My understanding of the model is : > > The resource is the "trade" between the purchaser and the supplier. > The "trade" records progressively more and more information as the > state of the "trade" changes over time. The puchase order, payments, > etc, are messages that change the state of the trade. Yes! > The trade can also contain at any one time, information that describes > how to make a valid state change from the current state. In other > words, it can contain information that allows the customer to > acknowledge receipt of the item, or for the supplier to send the bill, > or for either to cancel the trade. Yes! > The question that this raises in my mind is that if the "trade" is > addressed through a single URI, how is the view of each party, the > supplier or the purchaser, restricted to the state changes that they > can make. The "trade" will be one URI, but there will be several sub-resources hyperlinked to it for the order, each line item, each shipment, each payment, etc. and possibly each conversation or transaction about each of those resources. The view of each party depends on the configuration: * if centralized, either in a marketplace or in the extranet of the dominant trading partner, there will be one set of resources. * if P2P, each trading partner will maintain their own set of resources. It's like a HOPP or Half-Object Plus Protocol pattern, where each corresponding resource is a half-object and the business transaction protocol keeps their states aligned. We've already discussed on this list several times different ways to implement state alignment transactions in REST. -Bob Haugen
"oldieshome2002" wrote: > The question that this raises in my mind is that if the "trade" is > addressed through a single URI, how is the view of each party, the > supplier or the purchaser, restricted to the state changes that they > can make. I neglected to speak to the "restrictions" issue in my previous reply. These issues are also being addressed by UN/CEFACT. Their goal is to be able to conduct legally-binding business trades electronically. In general, the rules for electronic business trades need to be spelled out in a computable form that is published and accessible to both trading partners. ebXML has a SOAPy version of such rules in XML documents in their Business Process Specification Schema. Version 1.01 was accepted by UN/CEFACT and OASIS and can be found here: http://www.ebxml.org/specs/index.htm Version 2 just went into public review. UN/CEFACT is refining the rules in terms of states of business resources as we speak, due to be published in the fall. That's the stuff that I think will be suitable for REST. -Bob Haugen
I didn't realize it, but HTTP already has a CONNECT method which could be used for tunneling. Anybody know anything more about this? http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.9 == 9.9 CONNECT This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).
On Thu, Jul 25, 2002 at 11:10:46AM -0700, S. Mike Dierken wrote: > > I didn't realize it, but HTTP already has a CONNECT method which could be > used for tunneling. Yah, exactly. I've pointed it out a couple times here. It's a Good Thing, because you have to *ask* to tunnel. > Anybody know anything more about this? See RFC 2817 for a good example. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> > > > I didn't realize it, but HTTP already has a CONNECT method which could be > > used for tunneling. > > Yah, exactly. I've pointed it out a couple times here. > > It's a Good Thing, because you have to *ask* to tunnel. > > > Anybody know anything more about this? > > See RFC 2817 for a good example. > It seems like Upgrade is all that is needed to deal with the 'client behind firewall' situation. The CONNECT is an end-to-end thing, which isn't what I was looking for. Thanks for the bits.
Bill, Very interesting suggestion, thank you for taking the time to write it. I take it from your comments that you are at least pleased that we, the TAG, can write architecture in the positive sense. One of the mechanisms we have been using is the difference between the architecture document and the findings. We are trying to put "the positive" into the architecture doc, and have the extended discussion in the findings. I think this goes partway to what you are looking for, but not as far as you'd like. I wonder how we could get an ongoing, useful and open discussion going. Thinking aloud (electronically so to speak), maybe we could have TAG findings refer to well written patterns or anti-patterns.. At any rate, the TAG is certainly open to ideas on how to better communicate with the various constituents, and how to receive feedback/input. Much of a successful architect's job is communicating. FWIW, I believe that we have a real disconnect and inability to talk about various architectural styles in a detailed and positive manner. I know I'll get into trouble saying this on the REST discussion list, but none of us are really shrinking violets... Any architecture, REST or otherwise, makes certain trade-offs that hinder some users or agents, and help others. There may be a REST anti-pattern - such as methods in the SOAP body anybody? - that are patterns in another architecture. Now there are trade-offs to either. One of Roy's points about why methods are bad in the body is because it adds another element to the security context, particularly encumbering the firewall admin. On the ws-arch list, I wrote up 3 various ways that a simple GET/SET stockquote could be done using 1) method names in body, 2) GET/POST; 3) different URLs. And then I drilled into the way the firewall admin would administer each of the designs. This unfortunately didn't spark much discussion. When I've spent time with others - such as Mark Baker - and tried to drill into this issue, it's not clear to me how significant the down side is. So I admit that even though I can quote scripture - even wrote up some REST/shared information space scripture for the TAG bible - I haven't gotten the "faith" that there is only one acceptable architecture for what we want to do with much of machine to machine communications. What I would ask from the REST community is that it be open to rationale, detailed and reasoned discussion about the trade-offs associated with diverse architectural styles. Too much of the debate so far has been simply n party broadcast monologues, to paraphrase MLK. Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On > Behalf Of Bill de h�ra > Sent: Thursday, July 25, 2002 12:25 AM > To: 'David Orchard'; 'Paul Prescod' > Cc: www-ws-arch@...; rest-discuss@yahoogroups.com; > fielding@... > Subject: RE: [rest-discuss] RE: Clarification on REST, GET and CGI > > > > > > > From: David Orchard [mailto:dorchard@...] > > > > hmm. Roy said that many CGI scripts suck because they don't > > implement REST properly. Don't think I'm misquoting him. > > I'm pointing out that we don't look at the sucky CGI scripts > > when determine web architecture because, well, they suck. > > David, > > Yes, on the other hand worst practices and antipatterns are highly > valuable guides to developers in the trenches, especially given the > amount of trench and the way people tend to cut and paste web systems > together (CGI being a prime example). For example, saying > it's better to > not invent a new URI scheme is not quite the same as saying > an arbitrary > new scheme sucks (cue: reason). As one example, the OO world > has learned > much via antipatterns. Today, I suggest that saying non RESTful CGIs > suck is less useful that concrete examples; REST is not exactly > mainstream thinking yet. > > There's a good amount of physical architecture in the world that is > based on what not to do as much as what to do. One thing the TAG could > say to the web community is, look we can't do it all, you guys start > writing the anti-patterns down and let us concentrate on the > architecture in a positive form. > > regards, > Bill de h�ra > > .. > Propylon > www.propylon.com > >
I knew it was there but I've never actually seen it used in practice. Anyone knows if it's even implemented by various user-agents? On a separate but related topic, I re-read the document, especially the "partial GET" directive. I'm wondering if it makes sense, in light of the growing use of GET to return XML data, to have the Range Header specify an XPath filter (or a begin-end XPath pair). Any thoughts? Ramin -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] I didn't realize it, but HTTP already has a CONNECT method which could be used for tunneling . Anybody know anything more about this?
[ Please tell me to shut-up if I start sounding too much like a TV pitchman
(:-) ]
Get NetGlue (http://www.netglue.net). Install it. Crank up the server.
Assuming you already have a Google key. Point your browser at:
http://localhost/netglue/factory$Google.GoogleSearch.glu?key={google-key}&q=
{query}
and let it rip.
Or just browse through http://localhost/netglue and drill down to the Google
API which you can invoke visually from the browser itself. All the Google
parameter options are there. The package already comes with the Google HTTP
to SOAP component (there's also a two-way Amazon SOAP to HTTP bridge we're
releasing in a day or two).
If you want to format the result using XSLT or filter it using XPath, call
the same 'function' inside the Stage II pipeline, then drop in a 'transform'
action after it (or a 'Select' filter action) and format it into HTML or WML
or whatever. It should take about 30-seconds to set up (minus XSLT transform
writing time, of course (;-) It runs on your own box, so *you're* the
gateway not some remote site.
You can build your own bridge for other web-services with the provided
tools. It took us all of a minute to put together the Google (and Amazon)
bridges.
Okay, I'll shut-up now.
Ramin
So close and yet so far:
http://www.dentedreality.com.au/xoomle/docs/
http://xoomle.dentedreality.com.au/?key=YourGoogleDeveloperKey&method=doGoog
leSearch&q=dented+reality
==> method=doGoogleSearch.
Python? (You do realize that rest-discuss is the secret Python Illuminati list, right Ramin? :-) Jb
On Thu, 25 Jul 2002, Ramin Firoozye wrote: > I knew it was there but I've never actually seen it used in practice. Anyone > knows if it's even implemented by various user-agents? It's there for HTTPS, so it's used constantly. It's implemented in proxies, not user-agents. - Lucas
Hi Folks, I am working on creating a step-by-step, hands-on tutorial on creating XML-based REST web services. My tutorial guides the reader through the creation of an actual set of Web services. Things have been proceeding fine for all of the services that involve clients getting something (i.e., doing an HTTP GET). I am now at the point where I want to provide a service to allow clients to submit a Purchase Order (PO). Presumably, before a client submits a PO he/she - gets "something" from the Web service, - takes some actions (e.g., fills in a form), and then - responds with a completed PO. I am stuck on what that "something" should be. I need your help in identifying what that "something" should be. A relevant side note: One fundamental doctrine of my tutorial is that you should design for maximum usability of your web services. That is, web services should be usable both by browser-based clients, and by machine-based clients (i.e., machine-to-machine processing). Furthermore, the document that is served up by a Web service should be usable by both types of clients. Thus, I recommend serving up XML documents containing a stylesheet processing instruction (PI). Browsers will automatically style the XML using the stylesheet PI (I am gearing this towards the latest versions of the browsers. I realize earlier versions don't support this). Machines will simply consume the raw XML. Okay, back to the Purchase Order. What resource does a client access prior to submitting a PO? My tutorial says "Step 1. Identify the resources you wish to make available". Hmm, it is not clear to me what the resource is. I don't think that the resource is "PurchaseOrder". That is what the client is composing. Clearly the resource is not "MakePurchaseOrder" as resources are nouns not verbs. Perhaps it is "PurchaseOrderTemplate"? I don't like that but it's the best that I can think of at the moment. What do you think the resource is? Let's suppose that the resource is "PurchaseOrderTemplate". My tutorial says "Step 2. Create a logical URL to the resource". I propose this URL: (this is a purchase order for a company, parts-depot, which sells auto, bicycle, and rollerblade parts) http://www.parts-depot/purchase-order-template That seems like a reasonable logical URL. What do you think? Now the question is: if a client enters this URL what does he/she get back? Clearly, if the client is sitting at a browser then he/she would like to see an HTML form that can be filled in. What about the machine-based client, what does it want? Do we want to send to it an empty PO XML document (i.e., tags but no data)? Do we want to send to it a pointer to a DTD/Schema? Any either case, recall that I want to send the same XML to all clients; with a stylesheet PI for browser clients. The last step, what the client returns, is easy - a completed PO. So, to summarize my questions: 1. What should be the resource in this scenario? 2. What should be the URL to that resource? 3. I want to serve up an XML representation of the resource, so that I can be consistent to all clients. What XML should I serve up? Thanks! /Roger
Roger L. Costello wrote: > My tutorial guides the reader through the > creation of an actual set of Web services. Things have been proceeding > fine for all of the services that involve clients getting something > (i.e., doing an HTTP GET). I am now at the point where I want to > provide a service to allow clients to submit a Purchase Order (PO). > Presumably, before a client submits a PO he/she > - gets "something" from the Web service, > - takes some actions (e.g., fills in a form), and then > - responds with a completed PO. > I am stuck on what that "something" should be. I need your help in > identifying what that "something" should be. i suggest that the something is a 'catch-all' resource in the form web page where you can create purchase orders, search for purchase orders, browse indexes of purchase orders, and so on. if you would like to see a prototype of this email me and i will create one. however this is only really relevant for human user agents. at the risk of tossing around unsubstantiated buzzwords, i think that for machine user agents this is a question of service discovery. (see zeroconf.org for one definition of service discovery, e.g. finding a printer on an IP network). > A relevant side note: One fundamental doctrine of my tutorial is that > you should design for maximum usability of your web services. That is, > web services should be usable both by browser-based clients, and by > machine-based clients (i.e., machine-to-machine processing). > Furthermore, the document that is served up by a Web service should be > usable by both types of clients. Thus, I recommend serving up XML > documents containing a stylesheet processing instruction (PI). Browsers > will automatically style the XML using the stylesheet PI (I am gearing > this towards the latest versions of the browsers. I realize earlier > versions don't support this). Machines will simply consume the raw XML. i have been thinking about this issue as well. i think it basically boils down to the (jaded) topic of content negotiation. i see the Accept-Encoding (sp?) header as a reasonable way to achieve this. i think its difficult to support with existing httpd server tools though. from a seperate perspective, i don't think xml support is adequate in human user agents. e.g. take mozilla. the xlink support is dodgy (am i the only one who thinks xlink is way too complicated?). don't even ask about IE. i'm rambling on here. basically, i think that at this stage it's better to have human-only and machine-only representations. for machine user agents to use human-oriented (HTML/flash/etc) representations you need screen scraping, which is a short-term kludge; for human user agents to use machine-oriented (XML) representations, you need decent XML infrastructure in the browsers; frankly i don't think the technology is anywhere near mature enough. clearly the way forward is to migrate human user agents to XML, but this isn't where it needs to be for REST to use just XML representations, IMHO. sorry if i come across as a pessimist; i welcome challenges to this point of view. > Okay, back to the Purchase Order. What resource does a client access > prior to submitting a PO? My tutorial says "Step 1. Identify the > resources you wish to make available". Hmm, it is not clear to me what > the resource is. I don't think that the resource is "PurchaseOrder". > That is what the client is composing. Clearly the resource is not > "MakePurchaseOrder" as resources are nouns not verbs. Perhaps it is > "PurchaseOrderTemplate"? I don't like that but it's the best that I can > think of at the moment. What do you think the resource is? referring to my first point above, i would call it http://www.parts-depot.com/purchase-orders (you could make it purchaseOrders, purchaseorders, or whatever, but that's 'just' a question of style.) further PUTs or POSTs that create purchase orders can create URIs of the form http://www.parts-depot.com/purchase-orders/foo incidentally, i can't decide which is more appropriate here; a POST or a PUT. arguably, a POST makes sense as you are inserting a purchase order into the set of all purchase orders. i think a PUT could make a lot of sense as well though. i haven't investigated whether contemporary HTML user agents support PUT either; anyone have any input on this? > Let's suppose that the resource is "PurchaseOrderTemplate". My tutorial > says "Step 2. Create a logical URL to the resource". I propose this > URL: (this is a purchase order for a company, parts-depot, which sells > auto, bicycle, and rollerblade parts) > > http://www.parts-depot/purchase-order-template > > That seems like a reasonable logical URL. What do you think? i prefer mine. :) i don't know whether 'template' is too specific. i would have envisaged this resource as something more general, a 'portal' (if you'll forgive the use of that dot-com era word) into everything you could want to do with purchase orders, and i think my name better reflects such generality. > Now the question is: if a client enters this URL what does he/she get > back? Clearly, if the client is sitting at a browser then he/she would > like to see an HTML form that can be filled in. What about the > machine-based client, what does it want? Do we want to send to it an > empty PO XML document (i.e., tags but no data)? Do we want to send to > it a pointer to a DTD/Schema? Any either case, recall that I want to > send the same XML to all clients; with a stylesheet PI for browser > clients. see my point re: service discovery. prescod's web pages (thanks paul!) refer to an ongoing effort to provide a mechanism for describing REST web services, if you could call them that. > The last step, what the client returns, is easy - a completed PO. agreed. however the devil is in the details. for me the details are like this: the client returns a specific /representation/ of the resource it created; in this case a completed PO. for machines this can be XML, for humans (X)HTML. > So, to summarize my questions: i'll summarise my (entirely subjective, nowhere near definitive) answers.. > 1. What should be the resource in this scenario? a portal to everything to do with purchase orders. indexes, search forms, other forms, everything. > 2. What should be the URL to that resource? http://www.parts-depot.com/purchase-orders or equivalent. > 3. I want to serve up an XML representation of the resource, so that I > can be consistent to all clients. What XML should I serve up? i would serve up seperate (X)HTML/XML representations based on content negotiation. i just think that is the more pragmatic way forward given the status quo in browser technology, and glacial progress in adopting new technology (though my hope is that mozilla will breath new life into user agent innovation if it becomes more mainstream). however if you want to serve up a single XML representation, one approach i have which i haven't experimented with yet is to use XML namespaces; leave XHTML using the default root namespace, and use your own namespace for the XML bits. > Thanks! /Roger and thank you being an effective REST pioneer.. -vincent
> further PUTs or POSTs that create purchase orders can create URIs of the > form > > http://www.parts-depot.com/purchase-orders/foo > > incidentally, i can't decide which is more appropriate here; a POST or a > PUT. arguably, a POST makes sense as you are inserting a purchase order > into the set of all purchase orders. i think a PUT could make a lot of > sense as well though. i haven't investigated whether contemporary HTML > user agents support PUT either; anyone have any input on this? My impression is that PUT would only make sense if the client is specifying the URI of the resource-to-be-created. That's what PUT means, doesn't it? I'm still learning this, of course. // mark
----- Original Message ----- From: "Roger L. Costello" <costello@...> > > A relevant side note: One fundamental doctrine of my tutorial is that > you should design for maximum usability of your web services. That is, > web services should be usable both by browser-based clients, and by > machine-based clients (i.e., machine-to-machine processing). After building things in a nearly-REST way at a previous company for a few years, I've come to the conclusion that the 'application resource model' will be different for the two situations. I would honestly build the machine-to-machine system without regard to user interface, browser idiosyncrosies, etc. This is similar to muli-tier application development. If you build one system to satisfy two goals - automation and user interaction - then when the implementations conflict, the user interaction will win out, mainly because it is visible and touchable by 'decision makers'. Just as J2EE has entity-beans (data layer) and session-beans (logic) separate from user interface, I think Web applications also should be built with this separation. There are many ways of building user interface based apps across the Web - not the most architecturally pure things, but they work - but the new territory for me is building automation based apps across the Web. > Furthermore, the document that is served up by a Web service should be > usable by both types of clients. The representations of resources can certainly be used by both clients - but I believe that the set of resources that the two types of clients interact with will be different. However, there will be many cases where the user interface needs 'blended' information that is not available in one representation of one resource - which gives rise to a different resource, which is why I believe the 'visual web' results in interaction with a different set of resources than an 'automatable web'. > Okay, back to the Purchase Order. What resource does a client access > prior to submitting a PO? My tutorial says "Step 1. Identify the > resources you wish to make available". When I talk about resources, I often get confused between 'resource instance' and 'resource type' - with REST, there are no resource types, so we have to be careful to say what we mean. The automation-oriented client does not need to access any resource prior to submitting a PO. The only fore-knowledge it needs to have is - does it use POST or PUT? - if it uses PUT, who decided what the URI was? - if it uses POST, how does it acquire the URI to POST to? - what content-type values are acceptable by the server? I like the idea of using PUT, and the client asking the server for the URI of an empty business document. This allows the client to commit that URI to persistent data for its own tracking. If the PUT fails, its okay to keep trying against the same URI. If a POST failed, retrying might cause the server to think there were /two/ documents submitted. > > 3. I want to serve up an XML representation of the resource, so that I > can be consistent to all clients. What XML should I serve up? Try xCBL. It's pretty full-featured and covers most business document types (po, po-ack, invoice, etc.). [BobH hopefully will correct me if I'm wrong here...]
"S. Mike Dierken" wrote: > > 3. I want to serve up an XML representation of the resource, so that I > > can be consistent to all clients. What XML should I serve up? > Try xCBL. It's pretty full-featured and covers most business document types > (po, po-ack, invoice, etc.). > [BobH hopefully will correct me if I'm wrong here...] There is no wrong at this stage of the game. It depends on who you want to do business with, and what they already have implemented, if anything. If you're trading in a particular vertical industry, you should look around for industry standards. Just Google "industryName XML". xCBL is a reasonable default choice today. The global standards situation is murky. You might watch UBL, which is sort-of the next generation xCBL, but I don't think they have any documents ready yet: http://www.oasis-open.org/committees/ubl/ Or UN/CEFACT's eBTWG Core Components project, the successor the the ebXML Core Components group, but they don't have any documents ready yet either: http://www.ebtwg.org/projects/core.html There have been signs of convergence between UBL and UN/CEFACT Core Components and ANSI X12, but as far as I know, it hasn't happened yet and there are plenty of counter-indications, too. One thing I learned from working with standards orgs is that they are almost (?) as competitive as software vendors. -Bob Haugen
> xCBL is a reasonable default choice today. Where was my head at? If you're doing anything remotely technical, and maybe not even, use RosettaNet: http://www.rosettanet.org Another one to consider is OBI: http://www.openbuy.org/ I forget the exact quote, but this is the place to say, the great thing about standards is that there are so many of them! -Bob Haugen
I have actually wondered about a different approach (at least I think it's
different) to this "submitting a PO" example that have been mentioned in a
couple of different threads. Suppose the following:
CompanyA wants to submit an Purchase Order to CompanyB. CompanyB must first
be able to review (according to it's internal business rules) the PO request
before is creates a matching order in it's own system. Upon reviewing the
PO request, CompanyB must indicate to CompanyA what it's decision was.
Now, here is the process I have been mulling over...
CompanyA creates a PO in their system. The system assigns the following URI
(please ignore the whole http thing, in case you are also reading the
xml-dev list lately) to it:
http://CompanyA.com/PurchaseOrders/12345
The system then connects to a pre-arranged URL
(http://CompanyB.com/Orders/Requests) at CompanyB. It POSTs the above URI
to CompanyB. CompanyB returns the following URI as an ack response:
http://CompanyB.com/Orders/Requests/12123
CompanyB now turns around and submits a GET request to CompanyA at
"http://CompanyA.com/PurchaseOrders/12345". CompanyB goes off to think
about it. At any time, CompanyA can submit a GET request at
"http://CompanyB.com/Orders/Requests/12123" to determine the current status
of the request.
A bit later, CompanyB agrees to the PO. It creates a matching sales order
in their system and assign the following URI to it:
http://CompanyB.com/Orders/55824
CompanyB then submits a POST request to
"http://CompanyA.com/PurchaseOrders/12345", where the content is the URI of
the new sales order in their system. CompanyA now updates their internal
records to indicate that the PO has been accepted. From this point on,
CompanyA can submit GET requests to "http://CompanyB.com/Orders/55824" to
determine the status of the order.
Now, here is why I have been thinking about this pattern... We talk about
the PO that CompanyA submits to CompanyB. In other discussions, we have
thought of POSTing the PO to a URL at CompanyB, where the URL represented...
well.. no one can really agree what it represents. However, in the flow I
illustrated above, the resources are very clear:
http://CompanyA.com/PurchaseOrders/12345 : This is the URI of the PO
resource. Period. The PO is owned by CompanyA and so is the URI.
http://CompanyB.com/Orders/Requests : This is the URI of the resource
that PO requests are submitted to. This is owned by CompanyB, as is the
URI.
http://CompanyB.com/Orders/Requests/12123 : This is the URI of the
specific request made be CompanyA. It is owned by CompanyB, as is the URI.
At this point, both parties have the URIs necessary to query each other as
needed. Once CompanyB makes the decision and creates new resource (the
sales order), it then give the associated URI to CompanyA. Again, at this
point, both parties have the URIs necessary to query each other.
Another thing I should point out here is that at no time was any data POSTed
other than URIs. CompanyA never POSTed their PO to CompanyB. This is
because they are sending a representation of their resource to another
resource owned by CompanyB. Likewise, CompanyB did not return a status. It
returned a URI. Later, CompanyB POSTs a URI, not the order itself. At all
times, CompanyA and CompanyB exclusively use GET to get the representation
of the resource they want.
As I think about this model, it seems extremely clean to me. There is no
ambiquity about what is the resource, what is the representation of a
resource, etc. I would think this approach to be quite flexible, scalable,
easy to implement, etc. So, what am I missing? ;~)
---
Seairth Jacobs
seairth@...
Seairth Jacobs wrote: > I have actually wondered about a different approach (at least I > think it's different) to this "submitting a PO" example that have > been mentioned in a couple of different threads. Suppose the > following: i really like this model. i think the crux of the matter is that there are really two resources involved in the purchase order scenario. companyA looks at its order as a purchase order, and companyB looks at the same order as a /sales/ order. after all companyB could in turn be purchasing from companyC, in which case its resource would be a purchase order rather than a sales order. the point here is that in general, companys purchase stuff and they sell stuff. they have different ordering systems for the two scenarios because different rules and semantics apply in the business protocol. i really like this model because i think it reflects the reality of company buying and selling better. there is clear delineation of which resources exist, and who owns them. as an aside, this is pretty the much the first time i have seen POST used just to send a resource a URI rather than a full representation of the resource. how does this fit into the semantics of HTTP? should the URI be in a header, with /no/ representation in the POST body? this also raises another issue; now the issuer needs to 'own' a HTTP server where they didn't before. one more point: because there are more resources involved i think it may take a while longer to 'grok' this resource model if you were trying to explain it to somebody. from a pedagogical perspective, i think maybe it would be better to show a simpler version first, point out the ambiguity, and then show this as a 'refinement' of the simpler one. either way, thanks for sharing the model; it's certainly food for thought. thanks, -vincent
Actually, I had never heard of REST until Dave Winer posted that to scripting.com. I am currently working with Paul Prescod to make XooMLe "REST-compliant" and the first revision should be up today, with a few more additions (XSLT etc) being included over the next week or so. Thanks for your feedback tho guys. Beau (DentedReality) --- In rest-discuss@y..., lucas@g... wrote: > > So close and yet so far: > http://www.dentedreality.com.au/xoomle/docs/ > > http://xoomle.dentedreality.com.au/? key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality > ==> method=doGoogleSearch.
Vincent D Murphy wrote: > Seairth Jacobs wrote: > > I have actually wondered about a different approach (at least I > > think it's different) to this "submitting a PO" example that have > > been mentioned in a couple of different threads. Suppose the > > following: > > i really like this model. i think the crux of the matter is that there > are really two resources involved in the purchase order scenario. > companyA looks at its order as a purchase order, and companyB looks at > the same order as a /sales/ order. I like it too, but a single-Web-resource model will also work. Regardless of what it was called, the single-resource would actually be an "Order", and the Purchase Order would be internal to the buyer and the Sales Order internal to the seller. One consequence of having two resources is that their states are logically connected, that is, you need state-alignment transactions for subsequent interactions. (This is not a killer requirement, you need a protocol for agreement on changes in a single-resource model, too.) Another aspect of Seairth's approach that I like is that it starts to follow the Offer-Acceptance business protocol that we've discussed previously on this list. Orders are contracts and there are rules and customs for contract formation that need to be re-interpreted slightly for electronic business, but still apply. One of them is that a contract must be explicitly agreed to by both parties. (Same for changes.) The submission of a PO in any form is an Offer to buy. It is not the end of the conversation. The seller may or may not accept it, for any of many reasons. See also PurchasingBusinessRequirements on RestWiki: http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi rements -Bob Haugen
From: "Vincent D Murphy" <vdm@...>
>
> as an aside, this is pretty the much the first time i have seen POST
> used just to send a resource a URI rather than a full representation of
> the resource. how does this fit into the semantics of HTTP? should the
> URI be in a header, with /no/ representation in the POST body?
I'm not sure, really. I guess this is an application-level decision. You
may choose to do put the URI in a header, or you could put the URI in the
content, or you may even wrap the URI inside of XML in the content.
Personally, I would go with the second option (mostly since that is how I
think of the format/layout of a POST).
> this also raises another issue; now the issuer needs to 'own' a HTTP
> server where they didn't before.
I would rather say "now each party needs to 'own' a HTTP server". I see
this as no different than each party needing to own a phone. Fortunately,
with the proliferation of inexpensive and dependable ASPs, this is not as
much an issue as it used to be.
> one more point: because there are more resources involved i think it may
> take a while longer to 'grok' this resource model if you were trying to
> explain it to somebody. from a pedagogical perspective, i think maybe
> it would be better to show a simpler version first, point out the
> ambiguity, and then show this as a 'refinement' of the simpler one.
Certainly. I think part of the reason that this may be more difficult to
grasp is that this requires thinking about URIs in a more REST-like manner,
which it seems that most people using the web do not.
>
> either way, thanks for sharing the model; it's certainly food for thought.
Of course, I don't see this model applying to all RESTful applications (not
yet, anyhow). The main reason for this is that, as you point out above,
this requires server-to-server interaction. And while that may be
increasingly possible for the business sector, the consumer sector is still
a bit of a ways off from having always-on, broadband, static IP connections
with HTTP servers sitting at the end of them. :)
However, it may be possible to work around this problem with a hybrid
system, where individuals follow a client-server model with an HTTP server
they have access to, then the server itself uses the peer-to-peer model
(passing around URIs as discussed in the original post) with remote servers.
For instance, I may have access to the following server/URI space:
http://www.seairth.com/users/seairth/
I have near unrestricted access to use PUT, POST, GET, etc to any URI within
that space. I may install and map a messaging system to:
http://www.seairth.com/users/seairth/message/
I would then be able to PUT messages there (since I have 'absolute' control
of that space). For instance:
PUT http://www.seairth.com/users/seairth/message/out/12345
The internal messaging system would then turn around and POST the URI for
that message to the remote HTTP server of the user I am 'sending' the
message to (as discussed in the original post):
POST http://www.seairth.com/users/sjacobs/messages/in
In turn, the remote user would query their own server using GET:
GET http://www.seairth.com/users/sjacobs/messages/in
which would return to them a list of new messages including my original URI.
They would then be able to directly access the message on my server using
the above URI. All of the resources would stay 'local'. Then, when Bob
Haugen had realized that he forgot RosettaNet in [1], he would have been
able to do the PUT to correct it instead of posting [2].
[1] http://groups.yahoo.com/group/rest-discuss/message/1990
[2] http://groups.yahoo.com/group/rest-discuss/message/1991
---
Seairth Jacobs
seairth@...
From: "bhaugen32" <bhaugen32@...>
>
> I like it too, but a single-Web-resource model will also work.
> Regardless of what it was called, the single-resource would actually
> be an "Order", and the Purchase Order would be internal to the buyer
> and the Sales Order internal to the seller.
Yes, but if CompanyA submits the PO to CompanyB such that both companies
use:
http://CompanyB.com/Orders/55824
then who owns the resource? How do each control what can be done to the
resource? What keeps CompanyB from altering the Purchase Order? And if
they do, how can CompanyA prove this if they don't even control the resource
pointed to by the above URI?
I am not saying that the single-resource approach is wrong. I just don't
think I understand it as well as you do...
> One consequence of having two resources is that their states are
> logically connected, that is, you need state-alignment transactions
> for subsequent interactions. (This is not a killer requirement, you
> need a protocol for agreement on changes in a single-resource model,
> too.)
I'm not sure I follow you here. What would be considered a "state-alignment
transaction" here?
While I wait for an answer to that, here might be a scenario for a revision
(a subsequent interaction):
Suppose that CompanyA wanted to move the "Ship By" date forward a week. In
their system, they may create the updated PO and assign it the following
URI:
http://CompanyA.com/PurchaseOrders/12345/A
(though it could just has easily have been
http://CompanyA.com/PurchaseOrders/12346)
This would then be submitted to CompanyB just as the original URI was
submitted. CompanyB would then GET the new PO (it's important to note that
the original URI is still valid and still returns a representation of the
original PO). This new PO would contain the original URI, which would allow
CompanyB to see that this is a revised PO and not a new one. CompanyB will
issue an ack response:
http://CompanyB.com/Orders/Requests/12136
At this point, CompanyB will determine what to do. Supposing it can meet
the new deadline, it creates a new Sales Order (internally, it may be the
original order with a revision attached to it). This new order will be
submitted back to CompanyA as:
http://CompanyB.com/Orders/55824/A
(though it could just as easily have been http://CompanyB.com/Orders/55833)
And we are now back to where we started from. You will note that the
revision process was nearly identical to the initial process. Also, the
URIs are still as 'opaque' as they were to start with. Other than the need
of each company to keep track of the relationship of their own URI to the
other companie's URI, no additional state information is necessary.
Further, the creator of a given URI always pushes it to the other company
and it is always being pushed to the related URI (either as a POST or as a
response to a POST). This make for easy management of related URIs between
two parties.
As a side note, would this approach address some of Mike's concerns in [1].
---
Seairth Jacobs
seairth@...
[1] http://groups.yahoo.com/group/rest-explore/message/86
Thanks for putting up this excellent service.
First let me explain what I've been doing, and then at the end I have a
question about how it might work if you were to employ the HTTP
authentication mechanism that Paul Prescod had suggested in an earlier
message.
I've been putting together a few XSLT templates
that encapsulate calling your service in order to demonstrate some of the
benefits of a REST-style approach to some colleagues at work.
Even though the examples are trivial, people get pretty excited by what can
be done.
With a REST interface one can create a stylesheet that can be
imported and called without a lot of unnecessary code, allowing multiple
services to be combined in interesting ways. For example, I did a similar
thing with the Amazon interface in order to obtain an "$author" from a book
title, then pass that into a template called "search-for-url" in the Google
templates which returns the first URL found for that author name. Granted,
it's probabilistic, but it's just a simple demo.
<xsl:import href="amazon.xsl"/>
<xsl:import href="google.xsl"/>
<!-- ... get "author" from amazon ... -->
<a>
<xsl:attribute name="href">
<xsl:call-template name="search-for-url">
<xsl:with-param name="search-term" select="$author"/>
</xsl:call-template>
</xsl:attribute>
<xsl:value-of select="$author"/>
</a>
With Google's SOAP interfaces, I'm basically cut off from doing this.
Both the Amazon and Google template use the XSLT document() function in
order to call the service and obtain results. I'm not sure how that
function
would react to an HTTP Authentication request, so I would ask that you allow
keys to be used in the query for the time being.
I'd be happy to share this work with anyone that is interested; just send me
an
email. Thanks again.
- Jeff
----- Original Message -----
From: "borkazoid" <beau@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, July 27, 2002 5:44 AM
Subject: [rest-discuss] Re: xoomle
> Actually, I had never heard of REST until Dave Winer posted that to
> scripting.com. I am currently working with Paul Prescod to make
> XooMLe "REST-compliant" and the first revision should be up today,
> with a few more additions (XSLT etc) being included over the next
> week or so.
>
> Thanks for your feedback tho guys.
>
> Beau (DentedReality)
>
>
> --- In rest-discuss@y..., lucas@g... wrote:
> >
> > So close and yet so far:
> > http://www.dentedreality.com.au/xoomle/docs/
> >
> > http://xoomle.dentedreality.com.au/?
> key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality
> > ==> method=doGoogleSearch.
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
"Seairth Jacobs" wrote: > From: "bhaugen32" <bhaugen32@y...> > > > > I like it too, but a single-Web-resource model will also work. > > Regardless of what it was called, the single-resource would actually > > be an "Order", and the Purchase Order would be internal to the buyer > > and the Sales Order internal to the seller. > > Yes, but if CompanyA submits the PO to CompanyB such that both companies > use: > > http://CompanyB.com/Orders/55824 > > then who owns the resource? Before we get too deep into this subject, let me clarify: I am not recommending a single-resource configuration. Or a two-resource config. I've seen both. Both can work. Logically, you are correct, there are two sides of a contract. For orders, they're often called purchase order and sales order. Each trading partner will keep their own private copy. We're just talking about what's published in the external shared space as Web resources, which could be two or one order resources. Who owns it? I've seen a marketplace (Commerce One, Ariba, etc.) and also the dominant trading partner. > How do each control what can be done to the > resource? What keeps CompanyB from altering the Purchase Order? And if > they do, how can CompanyA prove this if they don't even control the resource > pointed to by the above URI? Company A digitally signs the offer, Company B adds their acceptance and digitally signs the combination of offer and acceptance. Needless to say, Company A archives a copy of the combined signed resource. > I am not saying that the single-resource approach is wrong. I just don't > think I understand it as well as you do... I'm still working out some of the details in REST, and so am very interested in different people's approaches. The most practice I've seen with this stuff is with: (a) two-resource configurations using the EDI mailbox approach, and (b) Web form interfaces for small companies selling to large customers, where the customer posts the PO on an extranet and the supplier accepts or maybe is allowed to negotiate timing, quantity, number of deliveries, etc. > > One consequence of having two resources is that their states are > > logically connected, that is, you need state-alignment transactions > > for subsequent interactions. (This is not a killer requirement, you > > need a protocol for agreement on changes in a single-resource model, > > too.) > > I'm not sure I follow you here. What would be considered a "state- alignment > transaction" here? If you have two order resources (PO and Sales Order), they are actually two sides of the same contract. So if you change the state of one in some way that changes the contract, the other needs to be changed too, and both parties should agree to and digitally sign the changes. Offer-Acceptance as practiced by RosettaNet and ebXML is a business protocol for coming to agreement on contract formation and changes in a two-resource configuration. In a state-alignment transaction, the resources begin in state X, the initiator of the transaction requests a change to state Y. If the other party agrees, the resource state is changed to Y. If not, or if there is a technical failure, the state remains at X. No rollback, no locking. Pretty simple. This is an instance of the HOPP pattern, for Half-Object Plus Protocol, because in this case the two resources are actually halves of the same contract. For a verbose description of business state alignment transactions, see: http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf We've been working out a RESTful Offer-Acceptance protocol on this list. It's still missing a couple of features, e.g. time constraints, security and non-repudiation features. But it's pretty close. -Bob Haugen
// Thanks for putting up this excellent service. not a problem, I'm glad that it is useful to someone, even if only as a "case study" or something like that. I hope the recent changes haven't messed up your work too much (change to unique URIs for each method). // I've been putting together a few XSLT templates // that encapsulate calling your service in order to demonstrate some of the // benefits of a REST-style approach to some colleagues at work. sounds interesting - i'd like to see what you've done if i could :) in the near future, i am planning on allowing the XML output to include a ref to an XSL, probably by just including t=http://your.xsl in the request (URL-encoded of course). this shouldn't affect any existing use of XooMLe as it will just not include any reference to it if not requested. // Both the Amazon and Google template use the XSLT document() function in // order to call the service and obtain results. I'm not sure how that // function // would react to an HTTP Authentication request, so I would ask // that you allow // keys to be used in the query for the time being. as far as the keys go, my plan is this; 1. XooMLe will look for &key=GoogleAPIKey in the request, 2. if that's not found, it will also check for the key value using a 401 Header (HTTP Auth Required) which could potentially be sent in the form http://key:GoogleAPIKey@.../search/ (username will be "key", password will be your key). Apart from that, you can use whatever HTTP Authentication manager you have access to depending on the language being used. Hope that works out for you ;) // I'd be happy to share this work with anyone that is interested; // just send me // an // email. Thanks again. I'd like to see what you've done!
REST folks,
I'm trying to spec out something and I thought I'd take a survey of the REST
folks for opinions and ideas. I've tried to find postings or articles on
standard practices but haven't found anything.
Here's the problem: Let's say you have a mechanism that allows you to invoke
SOAP requests via HTTP. Let's say the SOAP request takes parameters str,
num, and bool. So to invoke it from HTTP (I'll use GET as an example, but it
would be similar for POST, you would issue:
http://host.com/soapfunction?str=hello&num=12&bool=true
But SOAP lets you build complex nested structures with named fields (think
of a C struct or a Java class with only public data members). If you want to
invoke one of these guys via HTTP, one way would be to use a 'dot' notation
like C or Java:
http://host.com/soapfunction?struct.str=hello&struct.num=55
The place where it hits a bit of a snag is when you have the notion of
arrays to tackle:
http://host.com/soapfunction?str[1]=hello&str[2]=world
The first problem is how the bracket '[]' characters are handled. Some
browsers just urlencode the whole thing and ship it down to the server to
let it deal with it. Some older browsers barf on it. Some server-side
toolkits are cool with it. Others aren't. It's pretty inconsistent out
there. I also came across one case where the stuff before the '=' could
*only* be alpha/numeric/dash/underline if it was a form-POST (I'll try to
remember where I saw it).
I've thought of trying '{}' (braces), '()' (parens), or '<>' (lt/gt)
characters but I'm guessing it'll have similar problems with brackets. Ugly,
but workable is to use something like "str_1" as a stand-in for "str[1]" but
it kinda gives me the willies.
Anyway, if anyone has already done some work on this, or if there's a
standard spec I've missed, please point me at it. I'd rather not reinvent
the wheel. Barring that, are there any opinions on what's the friendliest
way to encode structs and arrays in URL parameters?
The easy way out would be to say "if you need to use structs and arrays go
SOAP -- for simple params, use HTTP" but I think it's good to keep REST-like
interfaces applicable for more complex interfaces.
Thanks,
Ramin
---
Ramin Firoozye
Wizen Software
---
Thanks for all the excellent comments! I have been carefully analyzing
each response. I have limited time to write, but I wanted to send out
some comments and my latest thinking (influenced heavily by your
comments)
1. Mike suggested that a Web service should treat visual clients (i.e.,
a client sitting at a browser) different from automation clients (i.e.,
a client that is a program - no eyes involved). Mike may be right, but
I hope not. My vision is an HTML-less Web. I envision a Web in which
the only documents flying across the Web are semantic-rich XML
documents. If the consumer of one of those XML documents happens to be
a visual client then automatically the client's browser fetches the XSLT
stylesheet and produces a nice visual rendition of the XML data. If the
consumer is a machine, then the raw XML is just fine.
2. Seairth made a very nice exchange protocol. However, there are
several things that bother me about that:
a. Seairth wrote in his initial message:
> [The first thing that happens is] CompanyA creates a PO in their system.
But wait, if I am the client and I am sitting at a browser I don't want
to create a PO from scratch. I want CompanyB to provide me a nice order
form to fill out.
b. The second objection I have is that CompanyA needs a Web server (or
access to some Web server). The typical client isn't going to know what
a web server is, let alone how to stand one up, and put the PO into the
correct location on the server.
c. I don't agree with calling it a purchase order on the CompanyA side
and a sales order on the CompanyB side. In my business, when a client
sends me a purchase order I still call it a purchase order. How I treat
the PO may be different than how the client treats the PO. But I still
call it a PO.
Seairth's approach may be the correct REST one but I would like
something more applicable to the masses. Here's the idea that is
currently brewing in my head:
A client (the client could be a visual or automation client) is
interested in purchasing something from CompanyB. So, the client
requests an <<order form>> by issuing this GET:
http://www.CompanyB.com/orderForm ------>
Prior to giving the client an orderForm CompanyB requests
identification, so it responds with a login form, loginForm.xml
<---------------- loginForm.xml
(Note, for visual clients the browser will automatically grab the XSLT
stylesheet that the XML document references and provide a nice visual
rendition of the login form, i.e., a login screen)
The loginForm.xml specifies what data the client must provide to create
an idCard.xml. The client thus returns idCard.xml to CompanyB:
------------------> idCard.xml
(Note, for visual clients idCard.xml is automatically generated using,
say, JavaScript, from the info that the user enters at the browser)
Now CompanyB gives the client the order form. However, the order form
has a customized return address (based upon data in idCard.xml)
<------------------- orderForm.xml (with customized return address)
The orderForm.xml describes what data the client must provide in his
PO. For example, it tells the client that he must provide the ID of
each part desired and the quantity desired, and he must provide credit
card info - type of card, card number, expiry date. [This is quite
interesting - the data in orderForm.xml is data about the data (i.e.,
metadata) that must be provided in the PO. Likewise for loginForm.xml
above.] The client constructs a PO using the info in orderForm.xml.
The client submits (PUTs) the completed PO to the URL provided in
orderForm.xml:
PO.xml ----> http://www.CompanyB.com/PurchaseOrders/costello -->
{Note, for visual clients the XSLT stylesheet provides a nice form that
the client simply fills in. When the client hits Submit some Javascript
code harvests all the data that the user entered and constructs PO.xml)
I hope this makes sense. I apologize for not writing more explicitly.
Hopefully, you can get the gist of what I am saying. /Roger
A suggestion: Google supports site specific searching, i.e., if you include the term "site:www.microsoft.com" in the Search field, the results are filtered so that only those in the www.microsoft.com domain are returned. You don't even have to fully qualify the criteria, so if you just say "site:au" you get only "au" domain results, or "site:com.au" you get only "com.au" domains. You could take advantage of this to create an interface such as this: [search the world for "xml" (what you have now)] http://xoomle.dentedreality.com.au/search?q=xml [search only .com sites] http://xoomle.dentedreality.com.au/search/com?q=xml [search only .au sites] http://xoomle.dentedreality.com.au/search/au?q=xml [search all of microsoft.com] http://xoomle.dentedreality.com.au/search/com/microsoft?q=xml [search only the www.microsoft.com subdomain] http://xoomle.dentedreality.com.au/search/com/microsoft/www?q=xml [search only the msdn.microsoft.com subdomain] http://xoomle.dentedreality.com.au/search/com/microsoft/msdn?q=xml The "site:" syntax is such that you should be able to write an http filter that walks down the hierarchy appending the terms after "search" until you hit the ? character and use them to build up a "site:" qualifier. This would work no matter how many subdomains there are. This seems like a cool REST-ian approach. What do others think? - Jeff
Roger, I resequenced some clips from your message in order to comment. "Roger L. Costello" wrote: > Seairth's approach may be the correct REST one but I would like > something more applicable to the masses. Here's the idea that is > currently brewing in my head: I don't think there is any consensus on a correct REST approach yet. Several people are exploring ideas. Maybe there will never be one single correct approach. It will depend (as usual) on context and conditions. For example: > if I am the client and I am sitting at a browser I don't want > to create a PO from scratch. I want CompanyB to provide me > a nice order form to fill out. But if you are CompanyA's computer system and you and CompanyB have a regular business relationship, you already know the format to use and what to do with it. So just shoot them a PO. -Bob Haugen
I should point out that my post was not targeted at any current thread. The transaction idea came to me a couple days back. The frequent PO example seemed like a good way to convey it. Having said that.... From: "Roger L. Costello" <costello@...> > > > [The first thing that happens is] CompanyA creates a PO in their system. > > But wait, if I am the client and I am sitting at a browser I don't want > to create a PO from scratch. I want CompanyB to provide me a nice order > form to fill out. I agree. This approach will not necessarily work for the basic browser environment you were talking about. > b. The second objection I have is that CompanyA needs a Web server (or > access to some Web server). The typical client isn't going to know what > a web server is, let alone how to stand one up, and put the PO into the > correct location on the server. Well, I would not expect someone expecting to use nothing more than a browser to deal with a web server. However, suppose instead that you worked for a company (CompanyA) that did have a web server (or access to one). Instead of pointing your browser to CompanyB's server, you could point it to your own, where a PO form(s) would take you through the process to create a PO for CompanyB. The resultant PO would be stored on ServerA and you would then be able to use the scenario I mentioned. Okay, this may still be more complicated than you are looking for, but I think there are a number of extensions to / variations on the theme that would allow the technique to be used at some level... > c. I don't agree with calling it a purchase order on the CompanyA side > and a sales order on the CompanyB side. In my business, when a client > sends me a purchase order I still call it a purchase order. How I treat > the PO may be different than how the client treats the PO. But I still > call it a PO. But my model does not disagree with your view. There is no reason you can't call it a purchase order on your side. Regardless, your PO is a different resource than your client's related PO. I chose to use PO and SO to make the separation of resources more clear (within my example). More important than PO's, though, is the fact that they model itself is quite generic. The use of two servers like this is quite clean (IMO), whether implementing ordering systems, mail systems, collaboration systems, etc. The only real issue I have not been able to resolve is how to effectively handle access and security issues. > Seairth's approach may be the correct REST one but I would like > something more applicable to the masses. Heh. I doubt my model is the "correct" one. As you point out above, there are scenarios (e.g., browser only) that do not fit this model. And it is not realistic (yet) to have everyone use the model I gave. Maybe years from now, when everyone is "always on", have their own web servers, etc., then this model might be more universally applicable... but that's still a big maybe. :) --- Seairth Jacobs seairth@...
From the department for useful web services. http://www.kokogiak.com/amazon/ is a usability wrapper around Amazon, using the web services api. regards, Bill de hra .. Propylon www.propylon.com
Well, we could build in dynamic DNS domain name support (!) :-) (And now, back to REST . . .) Seth Johnson Seairth Jacobs wrote: > > Heh. I doubt my model is the "correct" one. As you > point out above, there are scenarios (e.g., browser > only) that do not fit this model. And it is not > realistic (yet) to have everyone use the model I > gave. Maybe years from now, when everyone is "always > on", have their own web servers, etc., then this > model might be more universally applicable... but > that's still a big maybe. :) > > --- > Seairth Jacobs > seairth@... -- [CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights.
Roger and other PO-interest-group participants, This is just a curiosity question about the very limited issue of what to name the resources in a 2-resource REST order configuration. I'm not trying to promote a 2-resource model, just got to thinking about Roger's assertion below: "Roger L. Costello" wrote: > c. I don't agree with calling it a purchase order on the CompanyA side > and a sales order on the CompanyB side. In my business, when a client > sends me a purchase order I still call it a purchase order. How I treat > the PO may be different than how the client treats the PO. But I still > call it a PO. Questions for Roger and others: 1. When you place POs with your suppliers, do you call them POs too? How do you differentiate in normal conversation or computer systems between your POs to your suppliers and POs from your customers? 2. If you take the POs from your customers into your internal business apps, are they still called POs? The larger context for these questions is that I think in all cases of business exchanges between trading partners, there is a set of matched resources on each side that have different names but are logically related to the same business commitment or event. In other words, each of them could be managed either by a 2-resource HOPP configuration or a one-resource config. Other examples, with 2 resources and (1 resource): * Product shipment and receipt (product transfer). * Cash disbursement and cash receipt (cash transfer). * Accounts Payable and Receivable (claims). -Bob Haugen
On Mon, Jul 29, 2002 at 11:35:56AM +0100, Bill de h�ra wrote: > >From the department for useful web services. > > http://www.kokogiak.com/amazon/ > > is a usability wrapper around Amazon, using the web services api. Using the XML/HTTP "API", even. REST 1, RPC 0. 8-) Note to Amazon; next stop, RDF. That would totally rock. Integration possibilities up the wazoo. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
bhaugen32 wrote: >>if I am the client and I am sitting at a browser I don't want >>to create a PO from scratch. I want CompanyB to provide me >>a nice order form to fill out. > > > But if you are CompanyA's computer system and you and CompanyB have a > regular business relationship, you already know the format to use and > what to do with it. > So just shoot them a PO. the other important point is that this use case is on the 80 side of the 80-20 rule (IMHO).
From: "Vincent D Murphy" <vdm@...> > > bhaugen32 wrote: > >>if I am the client and I am sitting at a browser I don't want > >>to create a PO from scratch. I want CompanyB to provide me > >>a nice order form to fill out. > > > > > > But if you are CompanyA's computer system and you and CompanyB have a > > regular business relationship, you already know the format to use and > > what to do with it. > > So just shoot them a PO. > > the other important point is that this use case is on the 80 side of the > 80-20 rule (IMHO). Which case? Bob's or Roger's? And what do you mean by "on the 80 side"? --- Seairth Jacobs seairth@...
Seairth Jacobs wrote: >>>But if you are CompanyA's computer system and you and CompanyB have a >>>regular business relationship, you already know the format to use and >>>what to do with it. >>>So just shoot them a PO. >> >>the other important point is that this use case is on the 80 side of the >>80-20 rule (IMHO). > > > Which case? Bob's or Roger's? And what do you mean by "on the 80 > side"? sorry; i think i fired that brain dump off a bit too quickly without enough elaboration. i was saying that bob's case is the more common one. at least with my experience of ordering (in manufacturing/engineering companies), you have established relationships with a 'core' of suppliers. you are far more likely to be purchasing from a supplier who you have already purchased than from a complete 'stranger', so to speak. you do occasionally order from a supplier you haven't ordered from before, but this is less common than the other case. i think a "pretty order form" is geared towards strangers, when a relationship is established you just "shoot them a PO" and the two-resource model is a better match for this. i had the concern roger voiced about the purchaser needing a web server, but i think in the long-term this wouldn't be a problem. might affect how easy it is to adopt a two-resource approach though. hope this cleared that up. i am conscious that "doing is better than talking about doing". :)
Warning: abstract theory ahead! Properties in semantic web languages differ from properties in programming languages in that they are global. The http://foo/bar/baz#prop property is the same whether it appears on a resource of type "X" or a resource of type "Y". but different resources can support different subsets of the global set of properties. Methods in REST differ from methods in programming languages in that they are global. The POST or PROPFIND method are the same whether they appear on a resource of type "X" or a resource of type "Y". Is this just a coincidence or a revelation of something deep in the nature of the web architecture? -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
It was great to meet so manyu REST followers at OSCON 2002. For those who couldn't be there, I had a couple of fairly well attended talks on REST topics, Matt Seargent did a talk which concluded that REST is a better model than SOAP RPC if you can get your boss to agree to let you use it and generally it seems like the REST meme is spreading well. A year ago REST was a FORK phenomenon. Six months ago it was an FORK, rest-discuss and xml.com phenomenon. Now it's worldwide baby! Furthermore, the addition of WebMethods to SOAP allows a change in tactics. Rather than attacking SOAP we can offer REST as an architectural style to make your SOAP services scalable, interoperable, discoverable and all that other good stuff. -- Come discuss XML and REST web services at: Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
On Tue, Jul 30, 2002 at 05:47:08AM -0700, Paul Prescod wrote: > Is this just a coincidence or a revelation of something deep in the > nature of the web architecture? It's just a side effect of "all important resources should have a URI". A property has identity, and in many cases is important, ergo it gets a URI (mumble URIref mumble). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
While it's encouraging to see the WebMethods feature being adopted by SOAP
1.2, I question how often a REST architecture will actually be adopted.
Even the GET examples that are shown in the SOAP spec don't really encourage
a REST approach.
For example:
http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio
ns.html#L26854
Shows an example HTTP GET,
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html, application/soap+xml
The returned envelop contains a UUID reference for the named reservation
code.
Which is all well and good, but a subsequent POST is done to a generic
"Reservations"
resource, and the 'real' resource is referenced using the UUID buried in the
posted envelope,
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<!--- soap envelope elided -->
I get the sense that most SOAP-base services will continue to simply follow
the path of least resistance and disappear behind generic URLs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeffrey Winter wrote: > While it's encouraging to see the WebMethods feature being adopted by SOAP > 1.2, I question how often a REST architecture will actually be adopted. > > Even the GET examples that are shown in the SOAP spec don't really encourage > a REST approach. > > For example: > > > http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio > ns.html#L26854 > > Shows an example HTTP GET, > > GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1 > Host: travelcompany.example.org > Accept: text/html, application/soap+xml > > The returned envelop contains a UUID reference for the named reservation > code. > > Which is all well and good, but a subsequent POST is done to a generic > "Reservations" > resource, and the 'real' resource is referenced using the UUID buried in the > posted envelope, > > POST /Reservations HTTP/1.1 > Host: travelcompany.example.org > Content-Type: application/soap+xml; charset="utf-8" > Content-Length: nnnn > > <!--- soap envelope elided --> > > I get the sense that most SOAP-base services will continue to simply follow > the path of least resistance and disappear behind generic URLs. Here's an analogy I've been toying with when thinking about the likely shape of SOAP 1.2 deployment. POST-only SOAP services may be the HTML Frames of the next generation Web. Just as framed Web sites became popular for a few years after frames-capable browsers were deployed, we'll probably see a lot of POST-only SOAP services in the near future. But if the REST critique of POST-only services is right, we can expect to see these replaced by more addressable, GET-accessable SOAP services, just as we saw Frames pretty much vanish from mainstream use. Most Web sites don't use HTML Frames, because using them turns out to be a pain. The critiques we're hearing about POST-only SOAP have a lot in common with the various critiques of frames (URIs, addressability etc). Maybe we'll see a similar adoption/migration curve...? Dan ps. my sense that frames were quite widely adopted and then slowly abandoned is based on memory, anecdote etc. Does anyone know of a survey that puts hard figures to this claim? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9RsblPhXvL3Mij+QRAhh6AJ9TmYrau7XASsOF7e11vb4pgCVDsACdFik/ lACzD6ycTr6MkFrkUniks9c= =mxqH -----END PGP SIGNATURE-----
Semantic web languages must be global because their underlying data model is
simply the elements and attributes of markup that can be mapped to objects,
whereas
programming languages typically employ markup to hold object mappings.
What it says is that forcing object-property metaphors on web
resources breaks down when pushed too far.
Consider this "property" reference:
http://foo/bar/baz#xpointer(bookstore//title)
Is this even a "property" at all? This is a legitamate URI,
but it is essentially a "discovered" property (i.e., resource)
that the base resource implementer could not ever have
anticipated.
It's up to the user of the resource to say what that resource "is".
Simon St. Laurent had this to say recently:
"For years, writing programs has meant identifying a set of structures and
writing code around those structures. Information comes later, and is made
to conform to those structures. (Non-conformant data is often simply
rejected.) Working with markup offers developers a different option, though
one that takes some getting used to: applying labels and structure to data,
perhaps 'painting' on the structure, rather than breaking the data into
strictly pre-defined pieces.
This is a large leap to make, and a path rather different from many of the
data-binding and data-modeling tools offered for developers wanting to use
XML. This approach sees the information and the markup as primary, and not
as a mere serialization of an object, table, or other predefined container.
This approach is more open to non-deterministic styles of markup, and
requires a different style of working with information. Mapping information
between one set of fixed structures and another is a start, but only a small
step." [1]
[1] http://monasticxml.org/humility.html
----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, July 30, 2002 8:47 AM
Subject: [rest-discuss] Coincidence or correspondance?
Warning: abstract theory ahead!
Properties in semantic web languages differ from properties in
programming languages in that they are global. The
http://foo/bar/baz#prop property is the same whether it appears on a
resource of type "X" or a resource of type "Y". but different resources
can support different subsets of the global set of properties.
Methods in REST differ from methods in programming languages in that
they are global. The POST or PROPFIND method are the same whether they
appear on a resource of type "X" or a resource of type "Y".
Is this just a coincidence or a revelation of something deep in the
nature of the web architecture?
--
Come discuss XML and REST web services at:
Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Tue, Jul 30, 2002 at 05:03:32PM +0000, Dan Brickley wrote: > Just as framed Web sites became popular for a few years after > frames-capable browsers were deployed, we'll probably see a lot of > POST-only SOAP services in the near future. But if the REST critique of > POST-only services is right, we can expect to see these replaced by more > addressable, GET-accessable SOAP services, just as we saw Frames pretty > much vanish from mainstream use. Most Web sites don't use HTML Frames, > because using them turns out to be a pain. The critiques we're hearing > about POST-only SOAP have a lot in common with the various critiques of > frames (URIs, addressability etc). Maybe we'll see a similar > adoption/migration curve...? I'd like to believe that it was this easy, but at least frames were retrievable without prior coordination. They broke a handful or architectural principles, but they didn't try to reinvent the entire architecture like the vast majority of POST based Web services do. > ps. my sense that frames were quite widely adopted and then slowly > abandoned is based on memory, anecdote etc. Does anyone know of a survey > that puts hard figures to this claim? That's my recollection too, but I don't know of any studies. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
>> ps. my sense that frames were quite widely adopted and then slowly >> abandoned is based on memory, anecdote etc. Does anyone know of a survey >> that puts hard figures to this claim? > That's my recollection too, but I don't know of any studies. Architectural issues aside, the reason that I saw frames being dropped was a purely pragmatic one: managing state between the different frames turned out to be so cumbersome that using server-side includes was actually easier. The bottom line was, building dynamic websites was easier without frames. Unfortunately, the exact opposite motivation seems to be at play with SOAP; the toolkits make it easier to ignore the issues of URI design and simply deal with a generic URI.
> From: Jeffrey Winter [mailto:j.winter@...] > > It's up to the user of the resource to say what that resource "is". In a REST system, the naming authority says what resource is named. A user can only make claims. regards, Bill de hra .. Propylon www.propylon.com
The bottom line was, building dynamic websites was easier without frames. Unfortunately, the exact opposite motivation seems to be at play with SOAP; the toolkits make it easier to ignore the issues of URI design and simply deal with a generic URI. There will come a point in time when there are many publicly accessible services and finding the right one becomes an issue. The UDDI behemoth is one way, but I bet Google (or something like it) will have a way of offering the same functionality through their existing interface. Having a generic URI means that many functions are going to get slammed into a single bucket. The REST naming approach has an added advantage that you can uniquely identify each function using existing URL index/search technology. -ramin
>> It's up to the user of the resource to say what that resource "is". > In a REST system, the naming authority says what resource is named. A > user can only make claims. Paul seemed to be noodling on an interesting observation about the difference in the scope of properties and methods between web semantic languages and programming languages. Properties and methods in web semantic languages are global; in programming languages (00 languages anyway) they are typically scoped by the owning resource. My main point was that this difference really highlights the major difference between a web seen as a collection of markup that can be mapped to objects (by the receiver), and a web seen as a collection of objects that have been mapped to markup (by the sender). [Here I'm speaking of xml-based services.] If, when dereferencing a URI, a service chose to provide a deep level of detail about the resource, that included subordinate resource (property) details, it would be entirely up to me to ignore whatever implied object mapping the sender had in mind and build up a view of those details that suited me, by say using an XPointer fragment in the reference. I could then send that XPointer reference to somebody else in an email. That person could dereference the URI that I constructed. The resource returned by that URI may bear little resemblance to what the service provider originally had in mind. Granted, I'd be constrained to work with whatever data is provided by a GET and could only POST/PUT/DELETE in a manner that the service dictates, but it's up to me to interpret that data to suit my needs.
Jeffrey Winter wrote: > > While it's encouraging to see the WebMethods feature being adopted by SOAP > 1.2, I question how often a REST architecture will actually be adopted. I think that that's up to us. The SOAP juggernaut is mindless. It will roll happily towards or away from REST as long as everybody can certify their products "SOAP Compliant." There are still many specs in the web services world that are not very REST-y but SOAP is the spec with the most cachet. >... > Which is all well and good, but a subsequent POST is done to a generic > "Reservations" > resource, and the 'real' resource is referenced using the UUID buried in the > posted envelope, I agree that's a problem but there is an example in the primer that is a little better. Look at "Example 13": POST /Reservations?name=John%20Q.%20Public HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:Header> ... It still uses a UUID inside which it should not. It is not too late to submit suggestions to the SOAP Primer. Here are my comments that address the prose more than the examples: * http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0050.html You could submit some about the examples. UUIDs do not make much sense even from a pure-SOAP anti-REST point of view because HTTP URIs can have SOAP messages sent to them but UUIDs cannot. UUIDs only make sense when you realize that SOAP is supposed to be "transport independent" which means that you cannot depend upon a reliable addressing model. So you have to build your own. You can imagine how great that is for interoperability. -- Come discuss XML and REST web services at: Open Source Conference: July 22-26, 2002, conferences.oreillynet.com Extreme Markup: Aug 4-9, 2002, www.extrememarkup.com/extreme/
Paul Prescod wrote: > >... > > I think that that's up to us. The SOAP juggernaut is mindless. Which is not to say that individual SOAP advocates are mindless. The point is that the spec is outside of the control of individuals. There is no individual strongly associated with SOAP who can answer questions about right ways and wrong ways to use it. That's a void that REST advocates can step into. -- XML, Web Services Architecture, REST Architectural Style Consulting, training, programming: http://www.constantrevolution.com Come discuss XML and REST web services at the Extreme Markup Conference
----- Original Message ----- From: "Paul Prescod" <paul@...> > That's a void that REST advocates can step into. "..step into.." is definitely the right analogy... just ask "what does a URI identify?"
Long, but *well* worth the read. Every time I talk to Roy, I learn
something new and useful.
MB
----- Forwarded message from "Roy T. Fielding" <fielding@...> -----
Date: Wed, 31 Jul 2002 23:48:05 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "www-tag" <www-tag@...>
To: "Tim Berners-Lee" <timbl@...>
From: "Roy T. Fielding" <fielding@...>
In-Reply-To: <031301c23721$5661e5a0$84001d12@...>
Message-Id: <A2224494-A51A-11D6-8895-000393753936@...>
Content-Transfer-Encoding: 7bit
Subject: Re: httpRange-14 , what's the problem
X-Mailing-List: <www-tag@...> archive/latest/1886
Sender: www-tag-request@...
List-Id: <www-tag.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-tag-request@...?subject=unsubscribe>
X-Spam-Status: No, hits=-1.8 required=5.0
tests=IN_REP_TO,DOUBLE_CAPSWORD,PORN_3
version=2.30
X-Spam-Level:
Status: O
Content-Length: 34095
Lines: 681
On Monday, July 29, 2002, at 09:59 AM, Tim Berners-Lee wrote:
> http://www.w3.org/DesignIssues/HTTP-URI.html
> Tim Berners-Lee
> Date: 2002-07-27, last change: $Date: 2002/07/31 20:15:46 $
> [...]
> This question has been addressed only vaguely in the specifications.
> However, the lack of very concise logical definition of such things had
> not been a problem, until the formal systems started to use them. There
> were no formal systems addressing this sort of issue (as far as I know,
> except for Dan Connolly's Larch work [@@]), until the Semantic Web
> introduced languages such as RDF which have well-defined logical
> properties and are used to describe (among other things) web operations.
There has been quite a lot of work outside the W3C regarding the Web
architecture, both in formalisms and mere descriptions. Google is a
good way to find them, though most are intended more as a way of showing
off the properties of some variation on a formalism than they are of
actually modeling the Web.
> The efforts of the Technical Architecture Group to create an architecture
> document with common terms highlighted this problem. (It demonstrates the
> ambiguity of natural language that no significant problem had been
> noticed
> over the past decade, even though the original author or HTTP , and later
> co-author of HTTP 1.1 who also did his PhD thesis on an analysis of the
> web, and both of whom have worked with Web protocols ever since, had had
> conflicting ideas of what the various terms actually mean.)
Tim, when you invented HTTP it only allowed one method (GET), did not
have header fields, and interpreted every response as HTML. HTTP has
changed considerably over time.
I don't think we have conflicting ideas about the terms. I think that
the changes introduced in 1995 for the sake of HTTP caching and content
negotiation are absent from your model of how the Web works because we
needed to change the model in order for it to work at all. Furthermore,
the community made a very conscious decision to stop referring to
resources as documents because they simply do not always fit the mental
model of the English word "document".
> This document explains why the author find it difficult to work in the
> alternative proposed philosophies. If it misrepresents those others'
> arguments, then it fails, for which I apologize in advance and will
> endeavor to correct.
>
> 1. Web Concepts as proposed
>
> The WWW is a space of information objects. The URI was originally called
> a
> UDI, and originally all URIs identified information objects. Now, URI
> schemes exist which identify more or less anything (eg uuids) or
> emailboxes (mailto:) but is we look purely at HTTP URIs, they define a
> web
> of information objects. Information objects -- perhaps in Cyc terms
> ConceptualWorks -- are normally things which
>
> * Carry some sort of message, and
What does that mean? Information objects are things that carry
information?
All objects carry information by virtue of having state.
> * Can be represented, to a greater or lesser authenticity, in bits
Any object's state can be represented in bits. The state doesn't have
to be stored in bits -- it can merely be observed at the time that a
method is applied.
> I want to make it clear that such things are generic (See Generic
> Resources) -- while they are documents, they generally are abstractions
> which may have many different bit representations, as a function of, for
> example:
>
> * Time -- the contents can vary with revision --
> * Content-type in which the bits are encoded
> * Natural language in which a human-readable document is written
> * Machine language in which a machine-processable document is written
> * and a few more
>
> but the philosophy is that an HTTP URI may identify something with a
> vagueness as to the dimensions above, but it still must be used to refer
> to a unique conceptual object whose various representations have a very
> large a mount in common. Formally, it is the publisher which defines the
> what an HTTP URI identifies, and so one should look to the publisher for
> a
> commitment as to the exact nature of the identity along these axes.
Yes, no argument there.
> I'm going to refer to this as a document, because it needs a term and
> that
> is the best I have to date, but the reader should be sure to realize that
> this does not mean a conventional office document, it can be for example
>
> * A poem
> * An order for ball bearings
> * A painting
> * A Movie
> * A reveiw of a movie
> * A sound clip
> * A record of the temperature of the furnace
> * An array a million integers, all zero
>
> and so on, as limited only by our imagination.
None of which are similar to the examples I gave, wherein an http URI
is being used to identify the I/O control-system for a physical robot
or a gateway to SMS-enabled phone devices. Nor does it lend appropriate
significance to the properties of a Web-enabled refrigerator or a
car radio, both of which I have personally interacted with via HTTP.
It is therefore far more reasonable to refer to the thing identified
by an http URI as a resource that is accessible via HTTP.
> The Web works because, given an HTTP URI, one can in a large number of
> cases, get a representation of the document. For a human readable
> document, the person is presented with the information by virtue of some
> gadget which is given the bits of a representation. In the case of a
> hypertext document, a reference to another document is encoded such that,
> upon user request, the referenced document can in turn be automatically
> presented. In the case of a machine-readable document, identifiers of
> concepts, being HTTP URIs, will often allow definitive reference
> information about those concepts to be pulled in to guide further
> actions.
>
> The web, then, is made of documents as the internet is made of cables and
> routers. The documents can be about anything, so when we move to talk
> about the contents of documents we break away from talking about
> information space and the whole universe of human -- and machine --
> discourse is open to us. Web pages can compare a renaissance choral works
> with jazz pop hits, and discuss whether pigs have wings.
> Machine-processable documents can encode information about shoes, and
> ships, and sealing-wax. Until recently, the Internet protocol standards
> out of which the Web is built had little to say about such things. They
> were concerned only with the human-readable side, so it was people,
> reading natural language (not internet specs) who formed and communicated
> the concepts at this level. Nowadays, however, semantic web languages
> allow information to be expressed not only about URIs, TCP ports and
> documents, but also about arbitrary concepts - the shoes, and ships and
> sealing wax, and whether pigs have wings. Simple semantic web application
> allow one to order shoes and travel on ships, and determine that, given
> the data, pigs do not have wings.
>
> For these purposes it is of course quite essential to distinguish between
> something described by a document and the document itself. Now that we -
> -
> for the first time -- have not only internet protocols which can talk
> about document but also those which talk about real world things, we must
> either distinguish or be hopelessly fuzzy.
No argument there either, except that I don't think that this is
anything new. The solution is to use a formalism that understands
the difference between an identifier and *use* of that identifier.
In order for HTTP caching to work, there needs to be a distinction
between the attributes of a resource (whatever is identified by *any*
scheme accessed via HTTP) and the attributes of one particular
representation of that resource obtained via GET. Assertions in
the form of HTTP metadata (header fields) are made about each,
independently, and without ambiguity because they are defined by
a shared standard, albeit without syntactic clarity and independent
extensibility due to the limitation of mixing them all together
in a MIME-like header. Apparently, RDF is capable of the same
distinctions, so there is no technical issue here.
> And is this bad, is it an inhibition to have to work our way though
> documents before we can talk about whatever we desire? I would argue not,
> because it is very important not to lose track of the reasons for our
> taking and processing any piece of information. The process of publishing
> and reading is a real social process between social entities, not
> mechanical agents. To be socially responsible, to be able to handle
> trust,
> and so on, we must be aware of these operations. The difference between
> a
> car and what some web page says about it is crucial - not only when you
> are buying a car.
Correct, but in those circumstances we would not be using the "http"
URI to define the identity of the car. Instead, we use the http URI
to provide access via HTTP to a representation of a car that is ALSO
identified by a VIN (without any URI form being necessary). A legal
document that would later be drawn up, or even a transaction via
contract passed through a cashier (also identified via a http URI),
would use the VIN for physical identification of the car, not
because it is an inherently better string than one beginning "http:",
but because the VIN has been permanently affixed to the dashboard and
engine block for precisely this purpose.
If car producers wished such a thing, they could all agree to stamp
each car with a unique http URI instead and achieve the same
purpose: unique identification within the class of objects under use.
The fact that we could also use that URI to access information about
that specific car via the Web, which is a different resource from the
car itself, doesn't change the fact that it uniquely identifies the
car within the realm of cars.
However, it is a bit of a waste of time to talk about this in terms
of cars when the real objective, or at least that of the vocal
minority, is to distinguish between the abstract concept of a
namespace and a document describing that namespace. It is the same
problem, but is easier to think about. When used within an xmlns
attribute of an XML document, an http URI identifies the namespace.
When used within an xlink:href attribute of an XML document or a
browser's URI entry field or similar construct, an http URI
identifies the namespace by providing a consistent view of that
namespace in the form of representations.
The URI still identifies an unambiguous resource precisely because
we do not say that the result of a GET is the thing that is
identified, and we do not say that the thing identified is a
document just because access is allowed via HTTP by way of documents.
People who use the Web don't care about that difference, but the
technology of distributed caching absolutely depends on it.
In other words, just because a URI only identifies one resource
does not mean that every use of that URI is equivalent, just as
using an http URI as a cache key is not equivalent to using it
as the target of an anchor href.
I say an http resource is a conceptual object that has state and
identity and behavior, just as you define it in your own design notes
prior to getting involved in this debate, but I do not generally refer
to it as an object because all of the OOP developers get hot and
bothered when I do so -- it is a term that is inextricably linked
with a common implementation, just like document is a term that is
inextricably linked to words/images on renderable media. HTTP is
designed to hide all details of the implementation, so saying http
URI identify resources is the most accurate statement.
> Some have opined that the abstraction of the document is nonsense, and
> all
> that exists, when a web page describes a car, is the car and various
> representations of it, the HTML, PNG and GIF bit streams. This is however
> very weak in my opinion. The various representations have much more in
> common than simply the car. And the relationship to the car can be many
> and varied: home page, picture, catalog entry, invoice, remote control
> panel, weblog, and so on. The document itself is an important part of
> society - to dismiss its existence is to prevent us being aware of human
> and aspects of information without which we are impoverished. By
> contrast,
> the difference between different representations of the document (GIF or
> PNG image for example) is very small, and the relationship between
> versions of a document which changes through time a very strong one.
That argument is weird. No one has opined that the abstraction of
a document is nonsense -- it is merely insufficient to describe all http
resources. Furthermore, if the same URI is used to identify a resource
whose representations are a home page, picture, catalog entry, invoice,
remote control panel, weblog, and so on, then that URI obviously does
not identify the car. It might be said to identify a bunch of random
things related to a car of that type, but certainly not the car.
URI in general identify a resource -- one concept, one identity, one
sameness that might be observable via its representations. The vast
majority of URI do identify documents. HOWEVER, the architecture is
not defined by what is true of the vast majority -- it is defined by
what is true of ALL resources that fit the given criteria. And if the
criteria is "all http URI", your definition of "document" simply does
not fit. That does not in any way prevent people from using unambiguous
identifiers in http or the semantic web, nor does it somehow reduce
the value of a document as an abstraction.
> 2. Trying out the Alternatives
>
> The folks who disagree with the model do so for a number of different
> arguments. This article, therefore will have to take them one by one but
> the ones which come to mind are as follows:
Why didn't you simply refer to the arguments that others made, rather
than your interpretation of what they meant to say? My messages have
been a lot more carefully worded than this document.
> 1. Every web page (or many of therm) are in fact themselves
> representations of some abstract thing, and the URI really identifies
> that thing, not a document at all.
Not *necessarily* a document.
> 2. There are many levels of identification (representation as a set of
> bits, document, car which the web page is about) and the URI
> publisher, as owner of the URI, has the right to define it to mean
> whatever he or she likes;
They can define it to mean anything, but it only has meaning if it is
used according to that definition. Likewise, it may take on meaning
that wasn't intended by the publisher if it can be consistently used
as such, and may take on a temporary meaning if the temporal period is
sufficient to be usable. That's because the meaning of a URI is
insignificant when compared to the reason why the reference is
being made (the meaning of the resource in context of its use), and
not all references are made by the publisher of the URI.
It is possible, though not at all desirable, that the meaning of a
resource will at some point differ from the intended meaning that
a person had in mind when they used the URI as a reference. That
is a well-known problem that will affect the Semantic Web just as
much as it does the current Web. It is a social problem of any
system that allows identifiers to exist independent of the entity
being identified. Yes, it has drawbacks, but try identifying a concept
that has no current realization within a system that depends on
the realization for identity.
> 3. Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate using common sense
> and logic
> 4. Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate using the fact that
> different properties will refer to different levels.
> 5. Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate using extra
> information which will be provided in other ways along with the URI
> 6. Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate them by context: A
> catalog card will talk about a document. A car catalog will talk about
> a car.
None of the above. I have consistently stated that the URI identifies
the same resource as far as the architecture is concerned, even if the
people using that URI are only partially aware of its real sameness
over time, and even if its meaning changes over time. The only thing
that differs by context is the RESULT of using that URI. That is the
separation of concerns between methods and identifiers which has been
central to the architecture since HTTP/1.0 was introduced.
> 7. They may have been used to identify documents up till now, but for
> RDF
> and the Semantic Web, we should change that and start to use them as
> the Dublin Core and RDF Core groups have for abstract concepts.
IMO, there is only one Web.
> 2.1 Identify abstract things not documents
>
> Let's take the alternatives in order. These alternatives all make sense.
> Each one, however, has problems I can't see any way around when we
> consider them as a basis as
>
> The first was,
>
> Every web page (or many of them) are in fact themselves representations
> of some abstract thing, and the URI really identifies that thing, not a
> docuemnt at all.
>
> Well, that wasn't the model I had when URIs were invented and HTTP was
> written. However, let's see how it flies. If we stick with the principle
> that a URI (or URIref) must unambiguously identify the same thing in any
> context, then we come to the conclusion that URIs can not identify the
> web
> page. If a web page is about a car, then the URI can't be used to refer
> to
> the web page.
It doesn't identify both. It identifies the car. The web page is
what you GET. The same URI can then be used, in another context, to
indirectly identify a representation that was formerly the result of
a GET (which is what caches do when they lookup a response), but the
cache isn't even remotely confused between the two because we have
defined them as different things.
> 2.1.1 Same URI can identify a web page and a car
>
> What, a web page can't be a car? At this point a pedantic line reasoning
> suggests that we should allow web pages and cars to conceptually overlap,
> so that something can be both. This is counterintuitive, as a web page is
> in common sense, not a concrete object whereas a car is. But sure, we
> could construct a mathematics in which we use the terms rather specially
> and something can be at the same time a web page and a car.
>
> Frankly, this doesn't serve the social purpose of the semantic web, to be
> able to deal with common sense concpets and objects. A web page about a
> car and a car are in most people's minds quite distinct (as I argue
> further below). A philosophy in which they are identical does not allow
> me
> to distinguish between them. not only conflicts with reality as I see it,
> but also leaves us no way to make statements individually about the two
> things.
A web page is something that you GET from a resource, not the resource
itself.
The only aspect of this that limits the Semantic Web is that it
cannot pretend the result of a GET and the resource identified by the
URI that was used to perform the GET are necessarily the same thing,
which is a perfectly reasonable thing to require considering that they
aren't even the same thing for time-varying documents, let alone cars.
A URI is an identifier of a resource, not the resource itself.
What is necessary for the Semantic Web is that it be able to distinguish
between resources and representations, and further that it can deal with
the very common situation where the representation has no known URI
by which it can be directly referred, because Web sites deliberately
hide the URI of those resources that they do not wish to be directly
accessible. [BTW, Content-Location is not a sufficient fix for this
problem simply because the resource provider has no desire to use it.]
> 2.1.2 The URI identifies the car, not the web page
>
> So lets fall back on the idea that the URI identifies the subject of the
> web page, but not the web page itself. This makes sense. We can build the
> semantic web on top of that easily.
>
> The problem with this is that there are a large number of systems which
> already do use URIs to identify the document. This is the whole metadata
> world. Think of a few:
>
> * The Dublin Core
uses URI to identify abstract concepts (metadata relationships),
indirectly obtain sections of a resource that describes, and identify
other resources that are the target of that relationship.
> * RSS
uses URI to identify namespaces, indirectly obtain a document
that defines a namespace, and other resources that supply
representations in a given format.
> * The HTTP headers
refer to the resource, the representation, or the message, depending
on the definition of the header field.
> * The Adobe XML system
no idea
> * Access control systems
always refer to the resource.
I don't see any problem.
> (I'm sticking with the machine-processable languages as examples because
> human-processable ones like HTML have a level of ambiguity traditional in
> human natural language but quite out of place in the WWW infrastructure
> --
> or the Semantic Web. You can argue that people say "I work for w3.org" or
> "http://www.amazon.com/shrdlu?asin=314159265359" is a great book, just as
> they happily say "Moby Dick weighs over three thousand tonnes", "Moby
> Dick
> was finished over a century ago" and "I left Moby Dick on the beach"
> without expecting to be misunderstood. So we won't use human language as
> a
> guide when defining unambiguously the question of what a URI identifies.
> )
So you intend to define meaning without reference to humans? I thought
that the purpose of the Semantic Web was to help humans understand
and operate within the realm of interrelated resources. What good does
it do if the human is first required to translate their "real world"
reference to one that applies to the less-messy-than-the-real-world
Semantic Web? I think that is an interface error.
> Roy Fielding argues the the URI which I associate with his web page
> actually identifies him.
No, I do not. I never have. I even explicitly corrected you on
this very point while we were in your office talking this over.
My home page URI identifies my home page, where I go for a hypertext
representation of the topics that I am working on so that I can
easily jump from there to other resources of interest. It is a
public resource so that others can do the same. Some people use
that URI as an indirect way of identifying me, but only in the
sense that the resource contains more information about me.
However, someone could build a system that accepts the URI of a
home page as an indirect identifier of a person and performs some
action based on that relationship that affects me as a person, such
as calling my phone number, just as any identifier can be indirectly
used in ways that are not expected by the identifying authority.
Mark Baker has argued in the past that an http URI does identify
him, but I think that is reasonable since he owns the naming authority.
If you have complete control of the namespace, the identifiers
within it can identify anything provided that you only use them
consistently to identify that thing. I doubt that is the case for
his home page URI, but it could be for some other URI.
> He argues that conventionally people use the
> identifier to identify the person. However, consider another Roy Fielding
> page put together by freinds who found a photograph of him with no
> clothes
> on. A lot of content filtering systems would collect that URI and put put
> into their list. Even though the photo had many represnetations which
> different devices could download using content negotiation and/or CC/PP
> (color orblack and white and variosu different resolutions) the URI
> istelf
> would be listed as containing nudity. The public are very aware of
> different works on the web, even though they have the same topic.
Yikes, what an unpleasant mental picture. Does that identifier provide
representations of my state, or the state of a nude picture taken at
some particular point in time? The public is capable of distinguishing
the two over time, and thus those two resources do not have the same
topic/meaning/identity, even though there does exist a relation between
the two. Fortunately, I don't have "friends" like that.
> 2.2.3 Indirect identification
>
> You can argue that a web page indirectly identifies something, of course,
> and I am quite happy with that. If you identify an organization as that
> which has home page http://www.w3.org, then you are not saying that
> http://www.w3.org/ itself is that organization. This scenario is very
> very
> common, just as we identify people and things by their "unambiguous
> properties": books by ISBN, people by email address, and so forth. So
> long
> as we don't think that the person is an email address, we are fine. Some
> people have thought that in saying "An HTTP URI can't identify an
> organization" I was ruling out this indirect identification, but not so:
> I
> am very much in favor of it. The whole SQL world, after all, only
> identified things indirectly by a key property. This causes no
> contradiction. Perhaps I should say "An HTTP URI can't directly identify
> an organization". But by "identify" I mean "directly identify", and
> "identity" is a fairly direct word and concept, so I will stick with it.
Identity is not a fairly direct word and concept -- that is why I posted
a very long description of what it means to www-tag, including its
definition according to webster.com. If this is the source of our
disagreement, then I give up. All identifiers are by their very nature
an indirect means to establishing identity.
An http URI, when it is dereferenced, activates a mechanism whereby
the string of characters in the URI is used to select a bag of bits
that is supposed to represent the state of the abstract thing
identified as a resource via the http naming authority. Does that
imply that the resource is an HTTP mechanism? No. The URI is not
the resource, the mechanism is not the resource, and the bag of bits
is not the resource. Therefore, an http resource is always
restricted to indirect identification. It is simply impossible to
"directly" identify a resource for which the representation is
allowed to change over time.
Consumers don't give a rat's ass about the mechanism beyond a desire
that it consistently provide representations that match the semantics
they intended by referencing it in the first place. The semantics
are the resource. Usually the semantics correspond to a "living
document about a particular subject", but not always.
> Conclusion so far: the idea that a URI identifies the thing the document
> is about doesn't work because we can only use a URI to identify one thing
> and we have and already do use it to identify documents on the web.
No, we use it to obtain documents via the Web by identifying a
resource and asking for a representation of its current state.
We indirectly identify information within the representations,
the web page, by referring to it as the state obtained by doing
a GET on a resource's URI. All http-based Web pages are only
indirectly identified by http URI, since a Web page is a
representation obtained at an instance in time and not the
resource itself.
> 2.2 Author definition
>
> So how can we break free of that line of reasoning? We can try throwing
> away the rule that a URI identifies only one thing.
I don't.
> 2.3 Logic disambiguates
>
> Otherwise,we have to try another way of letting the URI mean sometimes
> one
> thing and sometimes another. Here is another.
Nope, not here either.
> 2.4 Different Properties
>
> Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate using the fact that
> different properties will refer to different levels.
Machines do have to know the realm of identification. If an identifier
is used for identifying multiple things in the same realm, then it
is clearly ambiguous. However, if the machine knows that it is using
the URI in a context that is clearly direct, such as xmlns attributes,
then there is no ambiguity just because it is used differently in
other realms. It is still better though to remain unambiguous, which
is the case for the examples I described. An xmlns attribute doesn't
access the resource -- it only uses the name of the resource as an
identifier. Whether or not the same identifier can be used in a GET
is irrelevant to the mechanism of xmlns.
> 2.5 Extra info with URI
>
> Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate using extra
> information which will be provided in other ways along with the URI
No, that twists the argument. The argument is that people use identifiers
in an ambiguous way because there is no such thing as universal agreement
about the semantics of a resource if the publisher does not make those
semantics explicit. The true nature of a resource cannot be observed at
any instant in time because its definition depends on how much it varies
over time, which is outside the perceptive capacity of humans and
machines. The publisher can improve understanding of the semantics
of a resource by adding external assertions, but the identity of the
resource itself does not change by those assertions.
> 2.6 Different meaning in different context
>
> Actually the URI has to, like in English, identify these different
> things ambiguously. Machines have to disambiguate them by context: A
> catalog card will talk about a document. A car catalog will talk about a
> car.
The URI doesn't identify different things in different contexts. It is,
however, used for different purposes in different contexts. An xmlns
uses the URI of a resource on the Web (or not) to directly identify a
namespace whose state may (or may not) be indirectly described by a
representation found by performing a GET on the resource identified by
that URI. There is no ambiguity here.
> 2.7 Change it for the Semantics Web
>
> They may have been used to identify documents up till now, but for RDF
> and the Semantic Web, we should change that and start to use them as the
> Dublin Core and RDF Core groups have for abstract concepts.
There is no need. In any case, the world doesn't need another AI system
for describing semantic networks in isolation -- they are only useful
when they are allowed to be enmeshed in the real world.
> 2.8 Abandon any identification of abstract things
I can't imagine anything more abstract than an identifier that identifies
"Roy's favorite quote from TimBL", which is bound to change over time.
I refuse to let anyone stick an HTTP server in my head just because that
is the only way to directly identify that resource. They will have to
make do with a URI that I control, wherein I manage an appropriate
mapping and occasionally drop a bag of bits that represents the
last recorded value of the resource.
> 3. Conclusion
>
> I didn't have this thought out a few years ago. It has only been in
> actually building a relatively formal system on top of the web
> infrastructure that I have had to clarify these concepts my own mind. I
> am
> forced to conclude that modeling the HTTP part of the web as a web of
> abstract documents if the only way to go which is practical and, by the
> philosophical underpinnings of the WWW, tenable.
I still disagree, particularly since you still haven't described how
you can hold that position for resources that are clearly not documents,
namely the resources that are service gateways to other systems. POST
does not always mean "append to this document". Oh, wait ...
> Q: Some HTTP URIs can be POSTed to. Can you still say they identify
> documents?
>
> A: Wel, some HTTP URIs can't be accessed at all, and some access is not
> allowed, and yes, some URIs are not only documents but also can be posted
> to. So they object is more complex than simply a document. But that it
> has
> this extra functionality doesn't make it any less a HTTP document
> formally. Something can have extra features and still remain in the same
> class of things.
That makes no sense to me at all. There is no stretch of the imagination
that would allow an HTTP POST to a URI that consistently identifies an
HTTP-to-GSM SMS message gateway to be formally equivalent to a document.
REST defines the message to be a representation of a document and the
service to be a resource that consumes representations, resulting in
a state change in the service that is reflected in the response message.
One could claim that the state of all SMS messages flying though the
GSM network is identified by this URI, and that therefore we are only
appending to that state, but that clearly is not the intention of the
publisher of the URI and is not consistent with the result of a GET
on that same URI, and is certainly not useful for reasoning about the
interaction. It is an invalid model of the system.
Cheers,
Roy T. Fielding, Chief Scientist, Day Software
(roy.fielding@...) <http://www.day.com/>
Chairman, The Apache Software Foundation
(fielding@...) <http://www.apache.org/>
----- End forwarded message -----
Matthew McGehrin, Sr. SOLARIS/Unix ADMIN, VERITAS, iPLANET, NFS, NT 3 Ayer Place � Rutherford, NJ 07070 � (201) 842-0435 � matthew@... Available immediately for full time, part time, freelance, contract, on-site, or offsite work in the tri-state area. Word Version also available: http://shell.reverse.net/resume/mcgehrin_resume_2002.rtf PROFESSIONAL SUMMARY a.. Six years of administration experience in the areas of networking, hardware, and software within a dot.com environment. b.. Ability to provide technical solutions to business problems.. c.. Fast learner willing to take on any project. d.. Excellent problem solving, troubleshooting, communication, and organizational skills. e.. Supervisory experience. COMPUTER SKILLS Software: Sun IPlanet, Apache, IIS, Legato Backup, Perl Applications: Java Dynamo, Java Resin Operating Systems: Solaris, xBSD, Linux, Windows, Mac Databases: Oracle 8, Microsoft SQL Hardware: Sun Solaris 4500, 420R, 220R, Netra T1; Compaq NT 6400R, 1850R, DL360; Cisco Pix, Nokia, Checkpoint Firewalls; Arrowpoint, F5 Content; EMC Clarion, NFS, Samba Storage EMPLOYMENT FeedRoom.com, New York, NY � 09/00 � 05/01 Sr. Solaris Administrator a.. Worked with Sun Solaris 2.7, 420R, 450; Compaq DL360: EMC Clarion. b.. Installed and maintained Sun Solaris Java application servers, as well as Sun IPlanet Web servers and Apache Web Servers. c.. Installed and maintained Sun Solaris Samba/AFD fileservers supporting Unix, Mac, and NT workstations. d.. Acted as NT/2000 administrator, including user creation, e-mail, file sharing, and backups; administered Cisco Arrow-point load balancers. e.. Utilizing Veritas Net backup, performed nightly backups for NT and Sun platforms. f.. Acted as Senior Technical Lead, helping to identify projects, plan their execution, and play senior role on project management team. g.. Designed, executed, and supported infrastructure projects. h.. Given responsibility for system monitoring, tuning, troubleshooting, design, and implementation of disaster recovery procedures. i.. Performed software/hardware upgrades as necessary. LetsPlay.com, New York, NY � 08/99 � 09/00 Sr. Solaris Administrator/Manager a.. Worked with Sun Solaris 220R, 420R, 4500, Netra T1; Nokia IP 300; Arrowpoint CS-100; acted as Administrator for Nokia IP 330 and Cisco Arrow-point CS-100. b.. Installed and maintained Sun Java Dynamo application servers, as well as Sun IPlanet web servers and Postfix Mail servers receiving daily load of 3 million hits and 25,000 e-mails. Netamorphosis.com, New York, NY � 12/98 � 07/99 Internet System Administrator a.. Worked with Compaq 1850 hardware. b.. Maintained multiple Linux Apache web servers for fathersday.com, mothersday.com, and joc.com, receiving over 30 million hits per month. c.. Acted as Firewall Administrator. Reverse.net, New York, NY � 12/99 - Present Owner/Unix Administrator a.. Act as Owner/Operator/Administrator of an Internet service Provider specializing in IRC FreeBSD shell accounts for over 100 shell users. b.. Hosted in Chicago with 100+ Domains. IllusionFusion.com, New York, NY � 01/98 � 11/98 Internet System Administrator Manager a.. Maintained multiple Solaris Apache web servers for John Deere and Coca-Cola. b.. Maintained several SPARC based systems, optimizing them for DNS and mail. c.. Provide Sales and Marketing support to several major clients, including John Deere, Coca-Cola, and Wachovia Bank. Dti.net � 04/97 � 11/97 System Administrator Manager/Network Operations Engineer a.. Supervised 2 interns; assisted and trained them while working on Unix Administration projects. b.. Maintained multiple Solaris Apache web servers in an ISP hosting environment. c.. Performed daily maintenance of SMTP, DNS, and http servers. EDUCATION Certificate, Computer Programming, Chubb Institute, 1996 References Available Upon Request
Mark, thanks for posting the email between Berners-Lee and Fielding.
It was very interesting.
http://groups.yahoo.com/group/rest-discuss/message/2027
One point though that I would like clarification on: When discussing
caching, he seems to talk about different representations of resources
in terms of versioning. I infer that he means on a GET, if the underlying
resource changed, the metadata (entity-tag) should be updated to provide
hints to caching proxies.
However, different representations of the same resource might be given
based only on the user-agent, and not on a state change.
For example, given a particular URI for a purchase order say:
http://mysite/po/234
I might send this to a device like a cellphone dereferencing that URI:
<Purchase xml:base="/po/234">
<LineItem xlink:href="item1"/>
<LineItem xlink:href="item2"/>
<LineItem xlink:href="item3"/>
</PurchaseOrder>
But I'd want to send all the details to a web browser dereferencing
the same URI:
<PurchaseOrder xml:base="/po/234">
<LineItem xlink:href="item1"/>
<Name>Book One</Name>
<!-- all the other details -->
</LineItem>
<LineItem xlink:href="item2"/>
<Name>Book Two</Name>
<!-- all the other details -->
</LineItem>
<LineItem xlink:href="item3"/>
<Name>Book Three</Name>
<!-- all the other details -->
</LineItem>
</PurchaseOrder>
The underlying state of Purchase Order 234 is exactly the
same, but I'm chosing to represent it differently depending
on the circumstances.
Are these in fact the same resource? Or do the details of
the HTTP header (in this case the user-agent) become
an implicit part of the resource identifier?
Suppose I wanted to employ caching hints (Etags) along
with the response, would it even be possible in this
circumstance given that the cache would need to be
aware of what kind of response I was returning?
Jeffrey Winter wrote: > Mark, thanks for posting the email between Berners-Lee and Fielding. > It was very interesting. > > http://groups.yahoo.com/group/rest-discuss/message/2027 ditto. > [..] > > However, different representations of the same resource might be given > based only on the user-agent, and not on a state change. i have two suggestions: first of all, given that one representation is basically a subset of the other, you could give the web browser representation to the cellphone as well, and have it omit the line item data it doesn't want to display. there may be issues with the verbosity of the data, but that's going to be an issue when you use XML anyway. failing that, perhaps it is appropriate to try and ensure that you only have one representation per state change, insofar as you can. given your example, one way to do this might be to use an include mechanism (e.g. xinclude) which is (optionally) processed by the client. therefore the cellphone version could display no child data, but the web browser could. i'm not sure how the client 'knows' whether to process the includes or not though. -vincent
I nominated REST for the "Most Overlooked XML-Related Tool or Technology" category in the "2002 XML-Journal Readers' Choice Awards". :) Voting started today: http://www.sys-con.com/xml/ - Rob
>>>>> "P" == Paul Prescod <paulp@...> writes:
P> 2. "PUT and DELETE operations are rarely used, if ever."
P> I see no reason for that rule. If what you want to accomplish
P> is semantically equivalent to a PUT or DELETE then why not use
P> the standardized method for doing it?
Can I ask a really naiive question? I've thought about this, but I've
never found any method to actually implement this; is there something
I should know about browsers?
For example, on an academic website project, we needed to allow
professors access to update their personal bio by adding, deleting and
amending descriptions of their papers. Logically, we'd want to use
POST, DELETE and GET/DELETE/PUT (?) to accomplish these operations,
but so far as I know browsers are only capabile of generating POST or
GET requests. We instead used the abomination of GET?action=delete
How do I code the HTML A:href to evoke a PUT or DELETE out of Mozilla
and MSIE? Even if the method is possible and simple, I think there is
your answer: I've used web browsers and built websites for almost a
decade, and _I_ don't know, so I'd hardly expect the average
2yr-experienced webservices designer to know the distinction even
exists.
--
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
Gary Lawrence Murphy wrote: > >... > > Can I ask a really naiive question? I've thought about this, but I've > never found any method to actually implement this; is there something > I should know about browsers? No, you're right. I was talking about more of a machine-to-machine scenario. PUT and DELETE are holes in current Web specifications. HTML was defined before recent versions of HTTP and has not caught up. XForms supports PUT which means that XHTML 2.0 will support PUT. I thought we'd get pushback on DELETE so I didn't push the issue for the current version of XForms. They think of their job as generating XML documents so getting GET support was a fight already. DELETE might be beyond the pale. Also, you could say that PUT and DELETE are supported in some "browsers" insofar as they support WebDAV. It's just hard (impossible?) to get at that functionality from HTML. I agree that's a problem and it would be great if you decided to make it your personal cause to fix it. ;) >... > How do I code the HTML A:href to evoke a PUT or DELETE out of Mozilla > and MSIE? Even if the method is possible and simple, I think there is > your answer: I've used web browsers and built websites for almost a > decade, and _I_ don't know, so I'd hardly expect the average > 2yr-experienced webservices designer to know the distinction even > exists. Sure, that's a problem. My point to Sam is that people who do know the distinction should not avoid them for the reasons he describes. Avoiding them because of browser (or server!) limitations is one thing. Avoiding them because of ignorance is another thing. But Sam seemed to think we should avoid them for global consistency reasons as you might in a relational database. But the methods are inherently mediated on the Web so you can implement whatever consistency fixups you need in the handling for the methods. -- XML, Web Services Architecture, REST Architectural Style Consulting, training, programming: http://www.constantrevolution.com Come discuss XML and REST web services at the Extreme Markup Conference
Damn. I was hoping you'd say something cool like http://www.mysite.org::DELETE/paper/N10243 given this, then, it's safe to say that whether you want to use REST or XMLRPC, you /still/ need new and custom client software? Ouch, that makes REST an even harder sell because the SOAP tools exist. -- Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc Business Innovations Through Open Source Systems: http://www.teledyn.com "Computers are useless. They can only give you answers."(Pablo Picasso)
FWIW, I think that both PUT and DELETE support would be visible principally through the browser itself, not through the content. What I mean is that you should be able to edit any document that you GET, and that your browser should expose File->Save and File->Delete. Amaya's probably the best example of this; http://www.w3.org/Amaya/User/saving_and_publishing_documents/the_save_command.html#page_body MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Rest folks,
I just put up a 'demo' server that runs an experimental version of our
NetGlue software. It's currently limited to 5-simultaneous users. I'll up
the count next week. Among other things, you can browse the catalog of
'part' components or directly invoke them via HTTP URLs (with results
returned in XML. Here are some things you can do (some long URLs might
wrap). If you don't use the MSIE browser, you might have to do 'View Source'
to see the XML results.
- INVOKE Google via HTTP URL (provide your own Google key and query):
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?key={key}&q
={query}
All Google search options are available from the URL.
- HTML DOCUMENTATION for the Google search component (note that there's an
'underline' character before the 'd' parameter i.e. it's '_d=html':
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=html
- BROWSER INVOKE. Fill in the blanks and hit 'Run' ('_d=html' and
'_mode=run'):
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=html&_mo
de=run
- XML COMPONENT INTERFACE. Replace the '_d=html' with '_d=xml':
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=xml
A few other things you can do:
-BROWSE CATALOG IN HTML: http://netglue.wizen.com/netglue/ (then click on
'Catalog' in the toolbar).
-GET CATALOG IN XML: http://netglue.wizen.com/netglue/_g.pxm?_d=xml (that's
'_g.pxm' and '_d=xml').
-GET factory package INTERFACE IN XML:
http://netglue.wizen.com/netglue/factory.glu?_d=xml
-GET Google package IN XML:
http://netglue.wizen.com/netglue/factory$Google.glu?_d=xml
-GET Google search method INTERFACE IN XML:
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=xml
Replace the 'xml' with 'html' in the above examples to see it in HTML. Also,
feel free to check out the Amazon component under 'E-Commerce'. The above
syntax works for all packages you see there. Format is:
http://.../netglue/PACKAGE$COMPONENT.FUNCTION.glu?[params=values...] (don't
forget the '.glu' before the '?')
If it's not obvious, the catalog is a 'service' registry -- i.e. 'meta-data'
is built-in and can be accessed via the URL. No need for a separate UDDI
server (:-)
Any comments/feedback/suggestions are happily encouraged.
Cheers,
Ramin
P.S. This is just a *demo* box. Please be gentle with it (:-)
----- Original Message -----
From: "Gary Lawrence Murphy" <garym@...>
> >>>>> "P" == Paul Prescod <paulp@...> writes:
>
> P> 2. "PUT and DELETE operations are rarely used, if ever."
>
> P> I see no reason for that rule. If what you want to accomplish
> P> is semantically equivalent to a PUT or DELETE then why not use
> P> the standardized method for doing it?
>
> Can I ask a really naiive question? I've thought about this, but I've
> never found any method to actually implement this; is there something
> I should know about browsers?
Most browsers aren't going to make it easy. Most of the discussion - at
least for me - is about non-browser systems. An 'automatable Web' as it
were.
In any case, the ideal would be to use HTML FORM element. But that is
disallowed (so I suppose HTML is non-RESTful):
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1
===
The method attribute of the FORM element specifies the HTTP method used to
send the form to the processing agent. This attribute may take two values:
a.. get: With the HTTP "get" method, the form data set is appended to the
URI specified by the action attribute (with a question-mark ("?") as
separator) and this new URI is sent to the processing agent.
b.. post: With the HTTP "post" method, the form data set is included in
the body of the form and sent to the processing agent.
===
Here is what it /could/ have looked like.
<FORM method='DELETE' action='reports.asp?report=99&annotation=27'>
<input type='submit' value=' Delete this comment '>
</FORM>
The legal workaround would be to use client-side programming via JavaScript
& some component. On IE you could use the XMLHTTPRequest object.
<script>
function doDeleteComment(form,reportId,annotationId)
{
// this ProgID request MSXML4.dll installed - use a different one to
work with older XML DLLs.
var http = new ActiveXObject("Msxml2.XMLHTTP.4.0");
var url;
url = "reports.asp?report="+reportId+"&annotation="+annotationId;
http.open("DELETE",url,false,username,password);
http.send();
// debugging code...
alert(http.status + " " + http.statusText + "\n" + http.responseText);
return false; // prevents page from refreshing
}
</script>
<FORM method='DELETE' action='reports.asp?report=99&annotation=27'
onSubmit='return doDeleteComment(this,99,27);'>
<input type='submit' value=' Delete this comment '>
</FORM>
----- Original Message -----
From: "Gary Lawrence Murphy" <garym@...>
>
> Damn. I was hoping you'd say something cool like
>
> http://www.mysite.org::DELETE/paper/N10243
>
> given this, then, it's safe to say that whether you want to use REST or
> XMLRPC, you /still/ need new and custom client software? Ouch, that
> makes REST an even harder sell because the SOAP tools exist.
You've got all the client code you need, on many platforms and in many
languages.
To make it 'programmer friendly' you need a 'toolkit' - something that talks
about objects and not protocols.
So rather than opening a connection and setting a header, etc. etc. you want
something like:
server = new HttpServer("host.domain.com",username,password);
server.delete(uri);
server.put(uri,data);
data = server.get(uri);
childId = server.post(parentId,data);
Say the word & I'll write you a handy dandy all-seeing, all-knowing client
in JavaScript using MS's XMLHTTPRequest object. Does Mozilla have an
interface-compatible component like that?
----- Original Message ----- From: "Mark Baker" <distobj@...> > FWIW, I think that both PUT and DELETE support would be visible > principally through the browser itself, not through the content. > > What I mean is that you should be able to edit any document that you > GET, and that your browser should expose File->Save and File->Delete. > > Amaya's probably the best example of this; > > http://www.w3.org/Amaya/User/saving_and_publishing_documents/the_save_comman d.html#page_body > Yeah... call it 'Save to the Web' & I'll pay you a dollar...
----- Original Message ----- From: "Ramin Firoozye" <ramin@...> To: <rest-discuss@yahoogroups.com> Sent: Saturday, August 03, 2002 10:27 AM Subject: [rest-discuss] Demo HTTP web-services > Rest folks, > > I just put up a 'demo' server that runs an experimental version of our > NetGlue software. It's currently limited to 5-simultaneous users. I'll up > the count next week. Among other things, you can browse the catalog of > 'part' components or directly invoke them via HTTP URLs (with results > returned in XML. Here are some things you can do (some long URLs might > wrap). If you don't use the MSIE browser, you might have to do 'View Source' > to see the XML results. Cool. I've got a demo server that does some other HTTP/XML stuff. http://www.xmldatasource.com There are two servlets, one to expose NNTP as XML over HTTP, and one for LDAP. Ancient code... They both run within a servlet-based framework that helps expose data as HTTP addressable objects with standard methods and support for Accept header content negotation. It supports browser-tricks like query args for do:method and do:accept. The framework source is at http://xml.apache.org/xang/ if you are interested.
Gary Lawrence Murphy wrote: > > Damn. I was hoping you'd say something cool like > > http://www.mysite.org::DELETE/paper/N10243 > > given this, then, it's safe to say that whether you want to use REST or > XMLRPC, you /still/ need new and custom client software? Ouch, that > makes REST an even harder sell because the SOAP tools exist. You don't need PUT and DELETE to do REST. They are just handy and more interoperable than home-grown ways of doing the same thing. If you can use them (i.e. have no software constraints), you should. If not, you can survive without them. My personal opinion is that if they are really important to your app then you should probably consider all of WebDAV and have support for WebDAV clients. -- XML, Web Services Architecture, REST Architectural Style Consulting, training, programming: http://www.constantrevolution.com Come discuss XML and REST web services at the Extreme Markup Conference
> ... do the details of the HTTP header (in this
> case the user-agent) become an implicit part
> of the resource identifier?
The answer to this question is perhaps, yes in one
sense: the server uses the metadata accompanying
the request to select a particular representation
to suit the context in which the URI was dereferenced.
As for the specific issue of responding with different
representations depending on the User-Agent and its
effect on caching:
[Vincent D Murphy...]
> i have two suggestions: [ .. details .. ]
Those are reasonable possibilities, but there are
a couple of other choices:
1. Redirect to User-Agent appropriate hierarchies:
GET /po/234
User-Agent: x
for one device might return,
HTTP/1.1 301 Moved Permanently
Location: /cellphone/po/234
and for another,
HTTP/1.1 301 Moved Permanently
Location: /browser/po/234
2. Allow all devices to use the same URI but
alert caches that the User-Agent must be
interrogated using the Vary header:
HTTP/1.1 200 OK
Vary: User-Agent
<PurchaseOrder>
<!-- User-Agent appropriate details -->
</PurchaseOrder>
The first alternative isn't as aesthetically appealing
as it makes the resource context explicit, but it's
essentially bulletproof; the second, while more pure,
relies on any caches to understand and apply the Vary
response header appropriately.
Thanks. I'll take a look at Xang. I especially like the NNTP one. Good stuff. Ramin > Cool. > > I've got a demo server that does some other HTTP/XML stuff. > > http://www.xmldatasource.com > > There are two servlets, one to expose NNTP as XML over HTTP, and one for > LDAP. Ancient code... > They both run within a servlet-based framework that helps expose data as > HTTP addressable objects with standard methods and support for > Accept header > content negotation. It supports browser-tricks like query args > for do:method > and do:accept. > The framework source is at http://xml.apache.org/xang/ if you are > interested. > > > > >
Just to dig up this old thread:
> > .... In fact, it is *essential* to the Web architecture that URI
> > support at least two other kinds of semantics, namely:
> >
> > * It must be possible to compare URI for equivalence (proxies, etc.)
> >
> > * It must be possible to construct a URI from another complete URI and
> > a relative URI.
>
> IMO, a web toolkit that properly supports the web/REST model would
> provide a URI object with the following three methods:
>
> uri.dereference(method, headers, representation)
> uri.compare()
> uri.create(base, relative, query_params)
I think it can also be said:
* It must be possible to associate metadata with a URI
so,
uri.setMetadata(headers)
This is one other way that web languages differ from programming languages:
Given the same initial state, dereferencing a pointer
in a programming language is going to return the same data;
dereferencing a URI in a web language may return different data
depending on the metadata values associated with it.
- Jeff
> Say the word & I'll write you a handy dandy all-seeing, all-knowing client > in JavaScript using MS's XMLHTTPRequest object. Does Mozilla have an > interface-compatible component like that? yes. var xmlhttp = new XMLHttpRequest(); this will give you an object that is compatible with MS's XMLHTTPRequest object. see http://www.mozilla.org/xmlextras/ Sjoerd Visscher w3future.com
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > > I think it can also be said: > > * It must be possible to associate metadata with a URI > > so, > > uri.setMetadata(headers) > > This is one other way that web languages differ from programming languages: > Given the same initial state, dereferencing a pointer > in a programming language is going to return the same data; > dereferencing a URI in a web language may return different data > depending on the metadata values associated with it. > I don't look at this as metadata about the URI, but rather metadata about the request - essentially negotiating the type of information being exchanged. Also, I'm not clear what dereferencing means - is it strictly a 'get'? What about these two pseudo-code examples: server.resource(uri) = data; // does a 'put' data = server.resource(uri); // does a 'get' Does the 'put' example 'dereference' the uri?
----- Original Message ----- From: "sjoerd_visscher" <sjoerd@...> > > var xmlhttp = new XMLHttpRequest(); > > this will give you an object that is compatible with MS's > XMLHTTPRequest object. see http://www.mozilla.org/xmlextras/ > Very cool - thanks for the info!
Ok, javascript is cool. I can dig javascript as a way to do this. So long as it works portably everywhere (opera, konqueror, lynx ...) and it looks like maybe it might, then I'm cool with that. thanks for the tip. -- Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc Business Innovations Through Open Source Systems: http://www.teledyn.com "Computers are useless. They can only give you answers."(Pablo Picasso)
----- Original Message -----
From: "Ramin Firoozye" <ramin@...>
> Thanks. I'll take a look at Xang.
Just keep in mind that it was written several years ago. The code is split
into two parts : a framework and an application. The NTTP and LDAP examples
on www.xmldatasource.com are apps within the framework. The Xang project is
another application meant to let people write apps in xml and javascript (or
any scripting language). The XML file mapped URLs to code snippets to handle
the HTTP methods. I've included an example below. The URI path was used to
locate an xml element that had attributes for the http methods. This
wouldn't be realistic for deeply nested paths, but I was working with some
'virtual DOM' technology at the time which would 'hook' the XML DOM and
expose arbitrary data sources as DOM nodes, so the addressing would just
drift into whatever data source you had a plug-in for. Each node inherited
behavior from parent nodes, so you could easily code behavior for large
numbers of data elements. Anyway... the virtual DOM technology never really
materialized (that's an RDBMS joke by the way...) but the framework part of
the code was independent and the XML application page part is still useful
without it.
There was no support for rendering or data sources. That idea was that with
a virtual DOM, you just pick a stylesheet based on the output format the
client requested, and the data sources were linked via code plug-ins.
Without a virtual DOM, you have to acquire the data and transform it
yourself.
Anyway... maybe you can salvage some code or some ideas...
--sample.xap--
<root>
<!-- include some common code -->
<script xml:link='include' src='system.script.xml' > </script>
<script>
function listOrders(context,returnTypes,parameters)
{
var doc = context.response.writer;
context.response.contentType = "text/xml";
doc.println("<list>");
doc.println("</list>");
}
function listPendingOrders(context,returnTypes,parameters)
{
var list;
list = DB.getPendingOrders(parameters.get("accountId"));
// stuff...
}
</script>
<!-- the path-based URI handlers -->
<tag name='orders' onGet='listOrders();' onPost='addOrder()'>
<tag name='pending' onGet='listPendingOrders();' />
</tag>
</root>
Hi Folks, The following question actually has a lot to do with REST, although it may not seem so. Once I get my tutorial completed I will show how it all fits in with REST. But for now, here's the question: I would like to create a REST resource which serves up XML and receives XML. For those clients at a browser the XML will be styled into HTML via an XSLT stylesheet. Suppose that this styling results in an HTML form that the user fills in to create a Purchase Order. After the user fills in the form he presses "Submit". I would like for the Submit action to result in kicking off some script which harvests the data in the HTML form, create an XML string from the form data, and then HTTP PUTs the XML string back to the resource. That's where I am stuck. I know how to write some Javascript to harvest the form data and create an XML string, but I don't know how to then HTTP PUT the XML string to the resource (i.e., server). Any ideas? /Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger L. Costello wrote: > Hi Folks, > > The following question actually has a lot to do with REST, although it > may not seem so. Once I get my tutorial completed I will show how it > all fits in with REST. But for now, here's the question: > > I would like to create a REST resource which serves up XML and receives > XML. For those clients at a browser the XML will be styled into HTML > via an XSLT stylesheet. Suppose that this styling results in an HTML > form that the user fills in to create a Purchase Order. After the user > fills in the form he presses "Submit". I would like for the Submit > action to result in kicking off some script which harvests the data in > the HTML form, create an XML string from the form data, and then HTTP > PUTs the XML string back to the resource. That's where I am stuck. I > know how to write some Javascript to harvest the form data and create an > XML string, but I don't know how to then HTTP PUT the XML string to the > resource (i.e., server). Any ideas? /Roger I thought XForms might have something to say on this -- but after a rather quick look at the spec I can't see anything. http://www.w3.org/TR/xforms/ [[ XForms is an XML application that represents the next generation of Forms for the Web. By splitting traditional XHTML forms into three parts - data model, instance data, and user interface - it separates presentation from content, allows reuse, gives strong typing - reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting. XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML. ]] Guess this doesn't answer your question Roger, but I'd be interested to hear if anyone here has looked into using XForms, and how it fits with the REST perspective. cheers, Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5 vEzGGuLWf+FltyIYwqPxh5k= =y3d3 -----END PGP SIGNATURE-----
> but I don't know how to then HTTP PUT the XML > string to the resource (i.e., server). As S. Mike Dierken pointed out http://groups.yahoo.com/group/rest-discuss/message/2037 straight HTML doesn't even support it, but you can use the same XMLHTTPRequest (Microsoft) or XMLHttpRequest (Mozilla) object that he has been discussing to do a PUT. I don't think there is any truly cross-platform way of doing it at the present. ----- Original Message ----- From: "Roger L. Costello" <costello@...> To: <rest-discuss@yahoogroups.com> Cc: "Costello,Roger L." <costello@...> Sent: Monday, August 05, 2002 8:41 AM Subject: [rest-discuss] Doing an HTTP PUT from HTML? Hi Folks, The following question actually has a lot to do with REST, although it may not seem so. Once I get my tutorial completed I will show how it all fits in with REST. But for now, here's the question: I would like to create a REST resource which serves up XML and receives XML. For those clients at a browser the XML will be styled into HTML via an XSLT stylesheet. Suppose that this styling results in an HTML form that the user fills in to create a Purchase Order. After the user fills in the form he presses "Submit". I would like for the Submit action to result in kicking off some script which harvests the data in the HTML form, create an XML string from the form data, and then HTTP PUTs the XML string back to the resource. That's where I am stuck. I know how to write some Javascript to harvest the form data and create an XML string, but I don't know how to then HTTP PUT the XML string to the resource (i.e., server). Any ideas? /Roger To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> I don't look at this as metadata about the URI, > but rather metadata about the request I have to agree. That's a much better way of looking at it. > Also, I'm not clear what dereferencing means - is > it strictly a 'get'? > What about these two pseudo-code examples: > server.resource(uri) = data; // does a 'put' > data = server.resource(uri); // does a 'get' > > Does the 'put' example 'dereference' the uri? IMO a PUT like a GET does dereference, basically because either way the resource's state is being exposed And while you could have something along the lines of > server.resource(uri) = data; // does a 'put' > data = server.resource(uri); // does a 'get' as defaults, for completeness you'd need to be able to override any default headers too > server.resource(uri, headers) = data; // does a 'put' > data = server.resource(uri, headers); // does a 'get'
My approach (with the toolkit I'm just about finished implementing) is to create a server-side filter that takes the key-value pairs in the incoming POST entity body, translates it to XML, and forwards the request to the next filter in the chain. The same occurs for the response. This approach insures that the client and server will operate in a RESTful yet more decoupled manner. Roger Costello <costello@...> wrote: > I would like to create a REST resource which serves > up XML and receives XML. For those clients at a > browser the XML will be styled into HTML > via an XSLT stylesheet. Suppose that this > styling results in an HTML form that the user fills > in to create a Purchase Order. [snip] __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
> I would like to create a REST resource which serves up XML and > receives XML. For those clients at a browser the XML will be styled > into HTML via an XSLT stylesheet. Suppose that this styling results > in an HTML form that the user fills in to create a Purchase Order. > After the user fills in the form he presses "Submit". I would like > for the Submit action to result in kicking off some script which > harvests the data in the HTML form, create an XML string from the form > data, and then HTTP PUTs the XML string back to the resource. > That's where I am stuck. I know how to write some Javascript > to harvest the form data and create an XML string, but I > don't know how to then HTTP PUT the XML string to the > resource (i.e., server). Any ideas? /Roger Hi Roger, People are free to correct me here (it's been a while), but: no browsers support HTTP PUT. I've done it before by writing an applet using a recent version of java and calling that from javascript. Essentially you're using the java.net.HttpURLConnection as an alternate HTTP implementation, because it *does* support PUT. Of course, I ended up moving over to POST because hacking the server to support PUT was not allowed... This was a few years ago when we didn't have a nicely documented framework from which to argue for such things :) cheers, james
rom: "Uther, James" <james.uther@...> > > People are free to correct me here (it's been a while), but: no browsers > support HTTP PUT. I don't know about the other ones, but I know that in IE6, PUT is internally substituted with GET instead. How do you like them apples! Frankly, I would have preferred it giving me an error than changing the meaning of my request... --- Seairth Jacobs seairth@...
Hi Roger,
How about this?
The HTTPURLConnection java class can submit a PUT request method. If you
compile it into an applet, then you can invoke the applet in the browser and
pass the form data down to it. The applet doesn't need any visual
representation. It can sit behind the scenes ready for invocation via
Javascript. The only thing is that the URL you are PUTting to should be on
the same machine the Applet is coming from (for applet sercurity reasons).
If you need the Java code for the PUT class, holler and I'll be happy to
post it.
The other way is to use a server 'redirector' that does it for you. That
might be more flexible.
Cheers,
Ramin
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Monday, August 05, 2002 5:42 AM
To: rest-discuss@yahoogroups.com
Cc: Costello,Roger L.
Subject: [rest-discuss] Doing an HTTP PUT from HTML?
Hi Folks,
The following question actually has a lot to do with REST, although it
may not seem so. Once I get my tutorial completed I will show how it
all fits in with REST. But for now, here's the question:
I would like to create a REST resource which serves up XML and receives
XML. For those clients at a browser the XML will be styled into HTML
via an XSLT stylesheet. Suppose that this styling results in an HTML
form that the user fills in to create a Purchase Order. After the user
fills in the form he presses "Submit". I would like for the Submit
action to result in kicking off some script which harvests the data in
the HTML form, create an XML string from the form data, and then HTTP
PUTs the XML string back to the resource. That's where I am stuck. I
know how to write some Javascript to harvest the form data and create an
XML string, but I don't know how to then HTTP PUT the XML string to the
resource (i.e., server). Any ideas? /Roger
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Wow! That's the silliest thing I've ever heard a browser do.
How did you test that?
-----Original Message-----
From: Seairth Jacobs [mailto:seairth@...]
Sent: Monday, August 05, 2002 8:24 AM
To: rest-discuss
Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?
rom: "Uther, James" <james.uther@...>
>
> People are free to correct me here (it's been a while), but: no
browsers
> support HTTP PUT.
I don't know about the other ones, but I know that in IE6, PUT is
internally
substituted with GET instead. How do you like them apples! Frankly, I
would have preferred it giving me an error than changing the meaning of my
request...
---
Seairth Jacobs
seairth@...
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Simple HTML Form, where METHOD="PUT". :) Okay, it may not be a really good/reliable test, but I was surprised at the outcome. If anything, I would have expected it to treat the PUT as a POST (which still would have been wrong, IMHO). I think the reason that GET is used is because it's the "default" value of the METHOD attribute [1]. I guess they figure that if an invalid value is given, then use the default value instead.
And as for how I knew it was converted to a GET, I have a server-side ISAPI extension that dumps the entire request to a file for debugging purposes.
[1] http://www.w3.org/TR/html4/interact/forms.html#edef-FORM
---
Seairth Jacobs
seairth@seairth.com
----- Original Message -----
From: Ramin Firoozye
To: Seairth Jacobs ; rest-discuss
Sent: Monday, August 05, 2002 1:08 PM
Subject: RE: [rest-discuss] Doing an HTTP PUT from HTML?
Wow! That's the silliest thing I've ever heard a browser do.
How did you test that?
-----Original Message-----
From: Seairth Jacobs [mailto:seairth@seairth.com]
Sent: Monday, August 05, 2002 8:24 AM
To: rest-discuss
Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?
rom: "Uther, James" <james.uther@...>
>
> People are free to correct me here (it's been a while), but: no browsers
> support HTTP PUT.
I don't know about the other ones, but I know that in IE6, PUT is internally
substituted with GET instead. How do you like them apples! Frankly, I
would have preferred it giving me an error than changing the meaning of my
request...
---
Seairth Jacobs
seairth@...
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Hi Dan, I raised [1] an issue [2] about this a while back. Were you looking at the latest editors' drafts? Cheers, 1. http://lists.w3.org/Archives/Public/www-forms-editor/2002Jan/0007.html 2. http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#resoluti on7 [member-only] ----- Original Message ----- From: "Dan Brickley" <danbri@...> To: "Roger L. Costello" <costello@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, August 05, 2002 6:37 AM Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Roger L. Costello wrote: > > Hi Folks, > > > > The following question actually has a lot to do with REST, although it > > may not seem so. Once I get my tutorial completed I will show how it > > all fits in with REST. But for now, here's the question: > > > > I would like to create a REST resource which serves up XML and receives > > XML. For those clients at a browser the XML will be styled into HTML > > via an XSLT stylesheet. Suppose that this styling results in an HTML > > form that the user fills in to create a Purchase Order. After the user > > fills in the form he presses "Submit". I would like for the Submit > > action to result in kicking off some script which harvests the data in > > the HTML form, create an XML string from the form data, and then HTTP > > PUTs the XML string back to the resource. That's where I am stuck. I > > know how to write some Javascript to harvest the form data and create an > > XML string, but I don't know how to then HTTP PUT the XML string to the > > resource (i.e., server). Any ideas? /Roger > > I thought XForms might have something to say on this -- but after a > rather quick look at the spec I can't see anything. > > http://www.w3.org/TR/xforms/ > > [[ > XForms is an XML application that represents the next generation > of Forms for the Web. By splitting traditional XHTML forms into > three parts - data model, instance data, and user interface - > it separates presentation from content, allows reuse, gives > strong typing - reducing the number of round-trips to the > server, as well as offering device independence and > a reduced need for scripting. > > XForms is not a free-standing document type, but is intended to > be integrated into other markup languages, such as XHTML. > ]] > > Guess this doesn't answer your question Roger, but I'd be interested to > hear if anyone here has looked into using XForms, and how it fits with > the REST perspective. > > cheers, > > Dan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5 > vEzGGuLWf+FltyIYwqPxh5k= > =y3d3 > -----END PGP SIGNATURE----- > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
> Wow! That's the silliest thing I've ever heard a browser do. > How did you test that? Both IE and Mozilla convert anything that's not a POST into a GET. I had tested this against both IIS and Tomcat. And just to make sure it wasn't the server logic itself converting for your convenience, I checked it outbound from the client using the apache TcpTunnelGui utility and it's definitely the client doing the conversion.
There should also be a "delete". :_) - winter ----- Original Message ----- From: "Mark Nottingham" <mnot@...> To: "Roger L. Costello" <costello@...>; "Dan Brickley" <danbri@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, August 05, 2002 1:34 PM Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML? Hi Dan, I raised [1] an issue [2] about this a while back. Were you looking at the latest editors' drafts? Cheers, 1. http://lists.w3.org/Archives/Public/www-forms-editor/2002Jan/0007.html 2. http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#resoluti on7 [member-only] ----- Original Message ----- From: "Dan Brickley" <danbri@...> To: "Roger L. Costello" <costello@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, August 05, 2002 6:37 AM Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Roger L. Costello wrote: > > Hi Folks, > > > > The following question actually has a lot to do with REST, although it > > may not seem so. Once I get my tutorial completed I will show how it > > all fits in with REST. But for now, here's the question: > > > > I would like to create a REST resource which serves up XML and receives > > XML. For those clients at a browser the XML will be styled into HTML > > via an XSLT stylesheet. Suppose that this styling results in an HTML > > form that the user fills in to create a Purchase Order. After the user > > fills in the form he presses "Submit". I would like for the Submit > > action to result in kicking off some script which harvests the data in > > the HTML form, create an XML string from the form data, and then HTTP > > PUTs the XML string back to the resource. That's where I am stuck. I > > know how to write some Javascript to harvest the form data and create an > > XML string, but I don't know how to then HTTP PUT the XML string to the > > resource (i.e., server). Any ideas? /Roger > > I thought XForms might have something to say on this -- but after a > rather quick look at the spec I can't see anything. > > http://www.w3.org/TR/xforms/ > > [[ > XForms is an XML application that represents the next generation > of Forms for the Web. By splitting traditional XHTML forms into > three parts - data model, instance data, and user interface - > it separates presentation from content, allows reuse, gives > strong typing - reducing the number of round-trips to the > server, as well as offering device independence and > a reduced need for scripting. > > XForms is not a free-standing document type, but is intended to > be integrated into other markup languages, such as XHTML. > ]] > > Guess this doesn't answer your question Roger, but I'd be interested to > hear if anyone here has looked into using XForms, and how it fits with > the REST perspective. > > cheers, > > Dan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5 > vEzGGuLWf+FltyIYwqPxh5k= > =y3d3 > -----END PGP SIGNATURE----- > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> Both IE and Mozilla convert anything that's not a POST into a GET. > I had tested this against both IIS and Tomcat. And just to make sure > it wasn't the server logic itself converting for your convenience, > I checked it outbound from the client using the apache TcpTunnelGui > utility and it's definitely the client doing the conversion. > Hmm. I'm guessing one started it and the other decided to be 'compatible' (even if it made no sense). Someone ought to go over and fix up Mozilla (and add a 'delete' too, while they're at it...)
I have been thinking some more about variations on the PO example(s)
discussed recently. One of the questions I am grappling with is:
At what point does mere data become an actual resource?
For instance, I gave a model in which only URIs were posted and all
resources were acquired through GETs. In this model, there is no such thing
as "sending data" via POST. In terms of the PO example, only the URI to a
PO resource was sent to the vendor.
However, Roger Costello was working on a tutorial where he wanted to have a
vendor present an HTML form that a user would fill in. This form would POST
the PO to the server. In this case, that same PO is considered to be
nothing more than "data".
So, here we have potentially two identical blocks of data. In the first
instance, it is a resource (really, representation of a resource)
identifiable by a URI and in the second instance, it is merely data. Why is
it that the second instance is not considered a resource, or even a
representation of a resource? Must a resource have an associated URI? Is
it okay to push a representation of a resource (POST) instead of pull a
representation of a resource (GET)? And if so, then what does it mean to
send a representation of a resource to another resource?
---
Seairth Jacobs
seairth@...
Mike,
I already have an LDAP service in the works, but I hadn't thought of doing
NNTP.
I can just see enabling posting to NNTP via a web-service.
Spam multiplication factor x 100 (:-)
Thanks for the link.
-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]
Sent: Sunday, August 04, 2002 10:28 PM
To: rest-discuss@yahoogroups.com; Ramin Firoozye
Subject: Re: [rest-discuss] Demo HTTP web-services
----- Original Message -----
From: "Ramin Firoozye" <ramin@...>
> Thanks. I'll take a look at Xang.
Just keep in mind that it was written several years ago. The code is split
into two parts : a framework and an application. The NTTP and LDAP
examples
on www.xmldatasource.com are apps within the framework. The Xang project
is
another application meant to let people write apps in xml and javascript
(or
any scripting language). The XML file mapped URLs to code snippets to
handle
the HTTP methods. I've included an example below. The URI path was used to
locate an xml element that had attributes for the http methods. This
wouldn't be realistic for deeply nested paths, but I was working with some
'virtual DOM' technology at the time which would 'hook' the XML DOM and
expose arbitrary data sources as DOM nodes, so the addressing would just
drift into whatever data source you had a plug-in for. Each node inherited
behavior from parent nodes, so you could easily code behavior for large
numbers of data elements. Anyway... the virtual DOM technology never
really
materialized (that's an RDBMS joke by the way...) but the framework part
of
the code was independent and the XML application page part is still useful
without it.
There was no support for rendering or data sources. That idea was that
with
a virtual DOM, you just pick a stylesheet based on the output format the
client requested, and the data sources were linked via code plug-ins.
Without a virtual DOM, you have to acquire the data and transform it
yourself.
Anyway... maybe you can salvage some code or some ideas...
--sample.xap--
<root>
<!-- include some common code -->
<script xml:link='include' src='system.script.xml' > </script>
<script>
function listOrders(context,returnTypes,parameters)
{
var doc = context.response.writer;
context.response.contentType = "text/xml";
doc.println("<list>");
doc.println("</list>");
}
function listPendingOrders(context,returnTypes,parameters)
{
var list;
list = DB.getPendingOrders(parameters.get("accountId"));
// stuff...
}
</script>
<!-- the path-based URI handlers -->
<tag name='orders' onGet='listOrders();' onPost='addOrder()'>
<tag name='pending' onGet='listPendingOrders();' />
</tag>
</root>
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
W3C has come up with some 40 usage scenarios for web-services. <http://www.w3.org/TR/ws-arch-scenarios/> Any thought on how many the REST approach can cover? (and shouldn't they be hearing about it? (:-) Ramin
Hi Folks,
I have written a paper[1] on migrating applications to Web
services. In a nutshell, here's what the paper says:
Don't use SOAP, WSDL, or UDDI! Instead, use these:
- Stand up Web services that receive and reply with standardized
XML vocabularies (create standard XML vocabularies for
your domain).
- Describe your Web services using HTML.
- Use standard search engines - Google, Yahoo, etc - to search for
services.
If you do this then you have taken a big and important step.
SOAP, WSDL, and UDDI are very immature, in a state of flux, and have
many crippling weaknesses. I believe that they will be short-lived and
will be replaced by superior technologies.
For today, it is "good enough" to just exchange (standards-based) XML
messages, to use HTML to describe services, and to use standard search
engines to find services.
Comments welcome. /Roger
[1] http://www.xfront.com/MigratingToWebServices.html
> - Describe your Web services using HTML. actually, you'll want to use RDF to describe the web service. We want machines to be able to interact with these services autonomously. HTML can't actually say anything about the objects that you are talking about. Humans read HTML, machines read RDF. > - Use standard search engines - Google, Yahoo, etc - to search for > services. That's a cool point. That plus RDF to describe the service can really work. Seth
> However, Roger Costello was working on a tutorial where he wanted to have a > vendor present an HTML form that a user would fill in. This form would POST > the PO to the server. In this case, that same PO is considered to be > nothing more than "data". It might be easier to use JavaScript to take the Form data, make an XML document out of it, and use XMLHttpConnection (or whatever that JavaScript object is called) to PUT that XML document. You're right in that every resource should have a URI. There has been discussion here on this list regarding how that URI is created. Since this information is coming from a browser, which cannot host resources, this issue is hard. One solution is to use UUIDs to provide a unique identifier for the resource. A UUID is unique over time and space. And because URIs should be opaque to the end user, a URI can easily be built from a UUID. That way, the client has decided on the resource name, and can assume it has not clashed with a current resource name. Another benefit of the client creating the resource name is that it always knows this resource name. So it can continue to check that URI via GET for its latest status. Seth
On Thu, Aug 01, 2002 at 09:39:16PM -0400, Jeffrey Winter wrote: > The underlying state of Purchase Order 234 is exactly the > same, but I'm chosing to represent it differently depending > on the circumstances. > > Are these in fact the same resource? No, they're two representations of the same resource. Neither is the resource. The resource is just the purchase order, which is abstract and can't be "gotten". > Or do the details of > the HTTP header (in this case the user-agent) become > an implicit part of the resource identifier? Noooo.... 8-) > Suppose I wanted to employ caching hints (Etags) along > with the response, would it even be possible in this > circumstance given that the cache would need to be > aware of what kind of response I was returning? Sure it would, but to be a good HTTP agent, you should signal the variability to caches by saying; Vary: User-Agent MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Seth Ladd wrote: > > > - Describe your Web services using HTML. > > actually, you'll want to use RDF to describe the web service. We want > machines to be able to interact with these services autonomously. HTML > can't actually say anything about the objects that you are talking > about. Humans read HTML, machines read RDF. You make a good point Seth. However, I believe that at this point in the evolution of Web services realistically the best we can do is have a human read a textual description of how to use a Web service and then build his client application in accordance with that description. I agree that tomorrow client applications will be able to dynamically make sense of an RDF (or, better yet, DAML-S) description, and dynamically configure itself to use the Web service. I believe that today a textual description of how to use a Web service is "good enough". /Roger
> agree that tomorrow client applications will be able to dynamically make > sense of an RDF (or, better yet, DAML-S) description, and dynamically > configure itself to use the Web service. I believe that today a textual > description of how to use a Web service is "good enough". /Roger Hmm... true, those fabled inference engines are nowhere to be found. :) But, if we're advocating the best way to discover and use True Web Services, let's also start advocating DAML-S (or some other service description language). I agree that we'll also need some textual descriptions. Luckily, we can markup RDF inside other XML. So we can always write a XHTML document that puts a pretty public face on the service. Inside that document, I can include my RDF markup describing the service in more rigid detail for machines that are searching Google for services like that. I think we can come up with a good mix of XHTML and RDF to describe services. The idea of placing that description document (mixed human and machine markup) inside Google is wonderful. Now, on to read about DAML-S. :) Seth
Seth Ladd wrote: > > > But, if we're advocating the best way to discover and use True Web > Services, let's also start advocating DAML-S (or some other service > description language). I agree that we'll also need some textual > descriptions. Luckily, we can markup RDF inside other XML. So we can > always write a XHTML document that puts a pretty public face on the > service. Inside that document, I can include my RDF markup describing > the service in more rigid detail for machines that are searching Google > for services like that. > > I think we can come up with a good mix of XHTML and RDF to describe > services. The idea of placing that description document (mixed human > and machine markup) inside Google is wonderful. An absolutely brilliant idea Seth! I like that a lot. That is an excellent way to bridge what we can do today with what we will be able to do tomorrow. Bravo! If it's okay with you, I would like to incorporate that into my article? /Roger
On Tue, Aug 06, 2002 at 10:48:48AM -0400, Roger L. Costello wrote: > You make a good point Seth. However, I believe that at this point in > the evolution of Web services realistically the best we can do is have a > human read a textual description of how to use a Web service and then > build his client application in accordance with that description. I'm with Seth on this. If you propose this to Web services folks, you'll immediately turn them off because it's instantly less capable than what they currently have. You have to give them something that can do what their existing technologies can do, *and* new stuff. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Hello, I've come to a mental block, and I am hoping the REST community can help me clear things up. For this example, I'll use two resources: A Car and A Driver. A central monitoring computer wants to know when a particular driver has entered the car AND through what door did that driver enter. In this scenario I have two resources, and each one is changing state. The Car's child resource Door has changed from Closed to Open (and back to Closed). The Driver's location property has changed from OutsideCar to InsideCar. I need to know both resources and their state changes to correctly know which Driver is in the car and what door was used. I'm having problems connecting these two state changes together to provide the central monitoring computer the correct information. I don't want to transmit them separately, since then I can't always know the two events are related. I don't want to say in the Door Open state change that a particular Driver opened it because that information (the actor in this scenario) isn't really part of the state change of the door. I want to keep the communication primarily state changes of resources, not Events that detail "How, What, Where, and Why". I am missing something of the puzzle? How can I communicate two pieces of information in one state change, or link two state changes? Your help and insight is greatly appreciated! Thanks very much, Seth
Seth, You said it yourself in the subject of your email: "Transfering State." In this case you need to make the 'State' of 'States' a GET- able resource. I'd recommend something like: GET http://localhost/app/statechanges/latest -- returns the new state of every object whose state has changed within the last time unit eg <states><state target="Driver">...</state><state target="Door">...</state></states> as well as the exact time the state transition took place. It sounds like you may be going for an event-based model. Beware that neither SOAP nor REST map well onto the event-based model. HTTP is fundamentally a 'pull'-focused protocol while event-based models are 'push'-focused. It can be done but it should not be done. - jkk --- In rest-discuss@y..., Seth Ladd <seth@b...> wrote: > Hello, > > I've come to a mental block, and I am hoping the REST community can help > me clear things up. > > For this example, I'll use two resources: A Car and A Driver. A central > monitoring computer wants to know when a particular driver has entered > the car AND through what door did that driver enter. In this scenario I > have two resources, and each one is changing state. The Car's child > resource Door has changed from Closed to Open (and back to Closed). The > Driver's location property has changed from OutsideCar to InsideCar. I > need to know both resources and their state changes to correctly know > which Driver is in the car and what door was used. > > I'm having problems connecting these two state changes together to > provide the central monitoring computer the correct information. I > don't want to transmit them separately, since then I can't always know > the two events are related. > > I don't want to say in the Door Open state change that a particular > Driver opened it because that information (the actor in this scenario) > isn't really part of the state change of the door. I want to keep the > communication primarily state changes of resources, not Events that > detail "How, What, Where, and Why". > > I am missing something of the puzzle? How can I communicate two pieces > of information in one state change, or link two state changes? > > Your help and insight is greatly appreciated! > > Thanks very much, > Seth
----- Original Message ----- From: "nixerman" <nixerman@...> > > It sounds like you may be going for an event-based model. Beware that > neither SOAP nor REST map well onto the event-based model. HTTP is > fundamentally a 'pull'-focused protocol while event-based models > are 'push'-focused. It can be done but it should not be done. HTTP PUT, POST, and DELETE are pushed. The Web Works Both Ways. I think SOAP-as-messaging would work fine for event-based systems, but I haven't put much thought into it. There are other reasons to be cautious of an event-based model with REST. Its very easy to slip into tunneling of methods if your resources become generic 'queue' and 'topic' resources. I know now that this can be problematic when doing application resource modelling. However, if you are able to maintain a rich resource model and not drift into generic messaging, events are fine way to build systems. One thing I learned a while ago was to not worry about lots of small events - trying to aggregate them into a single message isn't worth the effort. You state that the problem with sending events separately is "since then I can't always know the two events are related." How do you know the events are related anyway? Model that as a resource and you may make some progress.
> There are other reasons to be cautious of an event-based model with REST. > Its very easy to slip into tunneling of methods if your resources become > generic 'queue' and 'topic' resources. I know now that this can be > problematic when doing application resource modelling. Agreed. That's exactly the trap I was trying not to fall into. Luckily we moved away from queues just recently. The Client now pull exactly the data they need. > You state that the problem with sending events separately is "since then I > can't always know the two events are related." > How do you know the events are related anyway? Model that as a resource and > you may make some progress. Yes, and I think we finally modeled it as a resource. That was the hardest part: taking two resources that were well known, whose state changes we are interested in, and asking "What is the resource that results from this change?" It's an odd looking resource because it ties together two other resources, but it can stand on its own. Because of this we think it works well. I'd love to post a synopsis once we finalize our spec. Thanks for your help! Seth
Here's my prediction on how Web services will evolve over the upcoming
years:
|<----------->|<-------------------->|<---------------->|<----------->|
2001 2005 2008 2012
HTML, standardize begin to full-scale
screen XML vocabularies; replace use of
scraping textual description vanilla XML dynamic
of Web services with dynamic discovery
using HTML; discovery XML;
Web services XML - RDF/DAML; inference
exchange vanilla describe engine
XML; Web services brokers
Search for Web using dynamic automatically
services using XML - DAML-S; find things
Google, Yahoo, etc begin to see for you;
knowledge-based knowledge-
search engines based service
descripions
Some things to note:
1. There will be a gradual transition towards increasingly more
semantic-rich vocabularies.
2. At the present we are in the "vanilla XML phase". The emphasis today
is on getting consensus within a community on what is the required data
and how it should be organized. Web services move away from exchanging
HTML documents to exchanging XML documents.
- THIS IS A HUGE LEAP FORWARD! Do not underestimate the impact
of this change! It positions the Web for the next stage -
introducing semantics into the Web.
2. Starting around 2005 you will start to see the introduction of
non-vanilla XML vocabularies. These vocabularies will enable
inferencing (e.g., discover that SLR is a camera), thus enabling dynamic
discovery. There will likewise be a shift in how Web services are
described - from a textual (HTML) description to a semantic-discoverable
description. The leading contender today is DAML-S. (During this phase
I would expect to see implemented Seth's idea of blending human-readable
Web service descriptions with machine-readable descriptions)
3. The full semantic Web kicks in around 2007.
----
Positioning for the future
Want to get your company in a good position for the future? Concentrate
on:
- getting consensus within your community on an XML vocabulary
- get your applications onto the Web
- get your applications to stop exchanging HTML documents and
start exchanging XML documents
- describe your Web services textually using HTML
- use standard search engines (Google, Yahoo, etc) to locate
services.
If you do these things then you are:
- working efficiently
- not wasting money (on things like SOAP, WSDL, UDDI; note in the
timeline no mention of these; when the dust settles on these
technologies superior technologies - DAML, DAML-S - will have
already superceded them)
- you are positioning your company for the next step
These time estimates are based upon my observation of the speed of W3
technologies being developed and deployed on the Web.
Comments? /Roger
Roger L. Costello wrote, > Comments? /Roger It will all grind to a horrible halt at the "standardize XML vocabularies" stage, at least where there are any significantly non-trivial semantics attached to those vocabularies. There'll be lots of _activity_, for sure, but very little progress. FWIW, I have a years salary bet on this ... so I'm pretty confident that I'm right (which, of course, doesn't mean that I actually am right) ;-) Cheers, Miles
Hi Roger,
Interesting viewpoint. I'll take issue with one item in your paper:
"Describe your Web Services using HTML."
I think *any* XML* service description is better than HTML. Even if someone
makes up something remotely XML-like, at least they'll have a chance of
going back and remapping it into whatever IDL they want with through XSL or
turning it into formatted HTML.
But just having an HTML description without *any* service meta-data means
having to go back and re-do potentially lots of work. At the very least, I'd
tell people to put some formatted comments inside the HTML so some future
automated tool will have a chance beyond simple HTML-scraping.
Cheers,
Ramin
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Tuesday, August 06, 2002 5:32 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] A Sane Approach to Migrating to Web Services
Hi Folks,
I have written a paper[1] on migrating applications to Web
services. In a nutshell, here's what the paper says:
Don't use SOAP, WSDL, or UDDI! Instead, use these:
- Stand up Web services that receive and reply with standardized
XML vocabularies (create standard XML vocabularies for
your domain).
- Describe your Web services using HTML.
- Use standard search engines - Google, Yahoo, etc - to search for
services.
If you do this then you have taken a big and important step.
SOAP, WSDL, and UDDI are very immature, in a state of flux, and have
many crippling weaknesses. I believe that they will be short-lived and
will be replaced by superior technologies.
For today, it is "good enough" to just exchange (standards-based) XML
messages, to use HTML to describe services, and to use standard search
engines to find services.
Comments welcome. /Roger
[1] http://www.xfront.com/MigratingToWebServices.html
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Thanks for the comments Ramin. Yes, I understand your concern - nearly anything is better than that nasty HTML. These are essentially the same points that Seth and Mike raised yesterday. Seth came up with a (brilliant) idea of blending an XML description of the Web service in with a textual (HTML) description of the Web service. The former is for machines, the later for humans. (Same technique that RDDL employs.) I like this strategy a lot! Personally, however, I feel that getting machines to make sense out of the XML description won't really see any widespread use until the next phase of the Web evolution (around 2005). /Roger
Personally, I'm a little skeptical about the whole dynamic discovery
business.
Smacks a little too much of A.I. (with the same sort of 70's-80's hype
attached).
Searching for web-services using Google/Yahoo I agree with, but only if
there's
money in it for them. My prediction is that once the tire-kicking is over
with, you'll
see a rise of 'for-pay' web-services and then Google will start listing them
and
charging people for 'sponsored' listings.
As for the move from HTML to XML, I honestly don't think any mainstream
site-builder
is going to switch from their fancy HTML/Flash interface to an
XML-XSLT->HTML setting
without some serious tool support. Dreamweaver's latest rev had *nothing*
XSLT
related in it. Same with Frontpage. Besides, why would they want to switch
from their
HTML site to an XML/XSLT site when it slows things down, makes them have to
dive
elbow-deep into XSLT programming code, is harder to maintain, and offers
them no
obvious immediate financial benefit.
The more obvious driver will be people creating XML-based services *then*
putting
an HTML front-end on it instead of the other way round.
Good stuff, Roger. A little dose of skepticism is a healthy thing.
-Ramin
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Wednesday, August 07, 2002 5:54 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Web Services Evolution Timeline
Here's my prediction on how Web services will evolve over the upcoming
years:
|<----------->|<-------------------->|<---------------->|<----------->|
2001 2005 2008 2012
HTML, standardize begin to full-scale
screen XML vocabularies; replace use of
scraping textual description vanilla XML dynamic
of Web services with dynamic discovery
using HTML; discovery XML;
Web services XML - RDF/DAML; inference
exchange vanilla describe engine
XML; Web services brokers
Search for Web using dynamic automatically
services using XML - DAML-S; find things
Google, Yahoo, etc begin to see for you;
knowledge-based knowledge-
search engines based service
descripions
Some things to note:
1. There will be a gradual transition towards increasingly more
semantic-rich vocabularies.
2. At the present we are in the "vanilla XML phase". The emphasis today
is on getting consensus within a community on what is the required data
and how it should be organized. Web services move away from exchanging
HTML documents to exchanging XML documents.
- THIS IS A HUGE LEAP FORWARD! Do not underestimate the impact
of this change! It positions the Web for the next stage -
introducing semantics into the Web.
2. Starting around 2005 you will start to see the introduction of
non-vanilla XML vocabularies. These vocabularies will enable
inferencing (e.g., discover that SLR is a camera), thus enabling dynamic
discovery. There will likewise be a shift in how Web services are
described - from a textual (HTML) description to a semantic-discoverable
description. The leading contender today is DAML-S. (During this phase
I would expect to see implemented Seth's idea of blending human-readable
Web service descriptions with machine-readable descriptions)
3. The full semantic Web kicks in around 2007.
----
Positioning for the future
Want to get your company in a good position for the future? Concentrate
on:
- getting consensus within your community on an XML vocabulary
- get your applications onto the Web
- get your applications to stop exchanging HTML documents and
start exchanging XML documents
- describe your Web services textually using HTML
- use standard search engines (Google, Yahoo, etc) to locate
services.
If you do these things then you are:
- working efficiently
- not wasting money (on things like SOAP, WSDL, UDDI; note in the
timeline no mention of these; when the dust settles on these
technologies superior technologies - DAML, DAML-S - will have
already superceded them)
- you are positioning your company for the next step
These time estimates are based upon my observation of the speed of W3
technologies being developed and deployed on the Web.
Comments? /Roger
Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Since we are taking about predictions, here is an interesting article (from the future;) that I came accross today: August 2009: How Google beat Amazon and Ebay to the Semantic Web http://ftrain.com/google_takes_all.html - Robert
Perhaps a thread of interest to the members of this list: * http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01848.html -- XML, Web Services Architecture, REST Architectural Style Consulting, training, programming: http://www.constantrevolution.com Come discuss XML and REST web services at the Extreme Markup Conference
Paul Prescod wrote: > Perhaps a thread of interest to the members of this list: > > * http://www.ai.mit.edu/~gregs/ll1-discuss-archive- html/msg01848.html Yeah, really. Another great article, Paul! Your ideas on this extended topic have been very stimulating to me. I've been fumbling in the same direction ever since ebXML, where I was pretty heavily involved in ebXML-BPSS, one of the bad examples in your article. I take no offense, it was a learning experience for me, and I learned a lot. I continue to like the RosettaNet-UNCEFACT-ebXML "state alignment" transaction model, which we've explored some on this list, and think it can both be RESTful and have the unit-of-work transaction property. However, when it comes to the choreography or orchestration in ebXML BPSS - the stuff that orchestrates between the transactions - I get more skeptical every day. In fact, there were several factions in the ebXML Business Process project, which produced ebXML-BPSS among other things. One faction went over to UNCEFACT-eBTWG and is working out a better way to orchestrate conversations focused on states of business objects. I think that if you take the gist of that "better way" and translate the business objects into REST resources, you will get something that is very close to where your train of thought is going. (We'll see soon enough if I'm right.) One aspect of the eBTWG work is a business ontology based on Bill McCarthy's REA (Resource-Event-Agent) model (with which Mark is familiar, since we used to kick it around in the dist-obj list). I think the REA ontology is the semantic basis for the declarative language you are looking for. For example, the REA model for a business exchange (or even barter) is Give and Take, where I Give you some economic resources and Take from you some other economic resources in exchange. (E.g. usually products or services in exchange for money, but it wouldn't have to be money.) In REA, Give and Take are economic events. In business, economic events are usually preceded by Commitments, which are promises to perform economic events in the future. (An Order is a collection of Commitments.) So if the Commitment exists, you can post the Give and Take economic events to it. If the Give event is supposed to appear first, then the Take event could be posted to it. They're all speech acts that refer to previous speech acts. If the referent doesn't exist, you can't refer to it. Again, little or no choreography required. But the rules should also be REST resources. Am I following your train of thought? -Bob Haugen References, almost all more verbose than you want: REA Ontology source page: http://www.msu.edu/user/mccarth4/rea-ontology/index.htm UNCEFACT-eBTWG Business Entity Type project draft paper: http://www.collaborativedomain.com/standards/documents/BET%20Draft% 20Technical%20Specification_v012.zip (watch out for word wrap) RDF version of all this stuff due in fall.
On Thursday, August 8, 2002, at 01:28 PM, bhaugen32 wrote: > Paul Prescod wrote: >> Perhaps a thread of interest to the members of this list: >> >> * http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01848.html > > Yeah, really. Another great article, Paul! Ditto! Good job, Paul. This exact line of thinking mirrors what's been keeping me up at night for about the last year: trying to generalize and formalize this sort of notion into a generic theory of compositional complexity in software architecture. Kudos, jb
>>>>> "R" == Ramin Firoozye <ramin@...> writes:
R> Personally, I'm a little skeptical about the whole dynamic
R> discovery business. Smacks a little too much of A.I. (with the
R> same sort of 70's-80's hype attached).
Not so -- it's more likely to be implemented by massively distributed
human intelligence, for example, through inferences gleened by sifting
blog-like RDF metadata not unlike the way Google now reverts to it's
guess at spelling mistakes if the first search turns up empty.
R> Searching for web-services using Google/Yahoo I agree with, but
R> only if there's money in it for them. My prediction is that
R> once the tire-kicking is over with, you'll see a rise of
R> 'for-pay' web-services and then Google will start listing them
R> and charging people for 'sponsored' listings.
I still see Internet as an advertising medium. We advertise our goods,
our services, our ideas, our experiences, and webservice discovery is
really "find me all commercials for ..."
I also haven't seen any really compelling for-pay services except in
very narrow professional domains (where either someone else pays on
your behalf or you fold the costs into your own webservice-advertised
goods). The old saw that "professional editing" produces somehow
better journalism falls apart when you simply take a look through the
eons of microfilm stockpiled at the NYT -- it's based on the
unsupportable myth that the journalism of our childhood was somehow
more reliable than your average blog. It wasn't.
Ditto for stock quotes, IMHO. Reacting to the reported prices is not
nearly as useful as inside information about impending price changes ;)
My prediction is that, once the "golly-gee whiz" of the Internet wears
off (as it has already done for the under 25 crowd) for-fee services
will find their otherwise-sponsored bretheren overtaking them at an
alarming rate.
R> As for the move from HTML to XML, I honestly don't think any
R> mainstream site-builder is going to switch from their fancy
R> HTML/Flash interface to an XML-XSLT-> HTML setting
There's nothing incompatible here. XML/SVG->XSLT-+->HTML
+->RDF
+->...
What is needed is the need for the other formats as seen by the
average website (who is presently still in golly-gee land). When they
understand how their webservices are their public face, they will
anneal to being more effective at it (compare TV commercials from 1952
with 1972). When they realize that information overload has lead the
desktop vendors to produce Meerkat-like semantic surfers, they will
demand the Dreamweavers give them tools to leverage that sales
channel.
R> The more obvious driver will be people creating XML-based
R> services *then* putting an HTML front-end on it instead of the
R> other way round.
The driver I expect will be all under the hood. People will still
create their stories online, only with the requirement that it "also
feeds those meerkat things" and they won't care a hoot about RFC's.
Vendors, on the other hand, already know that the most efficient
lowest common denominator formats for storage and exchange are XMLs.
--
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
Yep, ditto, this is bang on. Coincidentally, WSCI was just acknowledged by the W3C as a submission; http://www.w3.org/Submission/2002/04/ Stop the madness! 8-O MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
(Canarie News Newsletter) -------- Original Message -------- Subject: [news] Web services versus the Semantic Web Date: Thu, 8 Aug 2002 14:13:53 -0400 (EDT) From: CAnet-3-NEWS@... For more information on this item please visit the CANARIE CA*net 3 Optical Internet program web site at http://www.canet3.net/news/news.html ------------------------------------------- [A lot of the hype about web services has been on the eBuisness potential. However many experts feel that web services and the semantic web has much greater applicability beyond the limited horizons of eBusiness. Thanks to Wade Hong for this pointer. Some excerpts - BSA] http://www.xml.com/pub/a/2002/07/17/daml-s.html The True Meaning of Service The Conventional Wisdom... At some point over the past 18 months the future direction of the Web began to be seen widely as a struggle between "Web Services" and the "Semantic Web". The latter was thought to be rooted in the W3C and academia, the former in IBM-Microsoft-Sun and industry. Part of the debate between services and semantics is a replay of the debate about what makes the Web an interesting place: commerce or content? In the conventional wisdom, services represent the commerce part of the Web, while semantics represent its content. It's been clear for some time that the conventional wisdom is wrong. The idea is that high-level ontologies of web resources can be very useful things and, here's the kicker, web services are just a kind of web resource. Web services are resources that allow one to effect some action or change in the world, such as the sale of a product or the control of a physical device. The motivations for creating DAML-S include discovery, invocation, interoperation, composition, verification, and monitoring. A part of the practical cash value of any web technology labeled "semantic" is that the Web ought to provide something relatively useful in response to vague or even cryptic input from the end-user. ------------------------------------ To subscribe or unsubscribe to the CANARIE-NEWS list please send e-mail to: majordomo@... In the body of the e-mail: subscribe news end ------------------------------------- These news items and comments are mine alone and do not necessarily reflect those of the CANARIE board or management. ----------------------------- Bill St. Arnaud Senior Director Network Projects CANARIE Inc www.canarie.ca/~bstarn
This is a bug in PHP; when the script encounters a fatal error, it still generates a 200 status code. http://bugs.php.net/bug.php?id=18824 This is for Apache's mod_dir to generate Content-Location: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11580 -- Mark Nottingham
http://llmensa.tripod.com
Hey guys, I have a quick question about the expected behavior of Http Digest authentication. The answer is not clear to me from reading the spec. Currently I understand it as: Server issues 401 Unauthorized challenge. Client generates a Digest header to authenticate itself. My question is: is the client expected to include the Digest HTTP header in all further requests to the server? Or is the server supposed to magically remember that this client has already authenticated itself? I suspect that a client should be forced to reauthenticate itself with every request and this is how most browsers seem to work but I'm not completely sure. Thanks for the input. - Buko
Hi On Fri 16-Aug-2002 at 07:40:43AM -0000, nixerman wrote: > > My question is: is the client expected to include the Digest HTTP > header in all further requests to the server? Yes. I was reading the HTTP book that was recommended on this list the other day and I was pleasantly surprised to read about the detail of digest authentication, it's a shame it's not fully supported by current browsers. Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
Hi Folks, My vision of the next generation of the Web is that all HTML document interchanges will be replaced by XML document interchanges. Thus, the Web evolves from an HTML-based Web to an XML-based Web. In an XML-based Web I question the utility of the HTTP POST method. The HTTP GET method allows a client to cleanly retrieve an XML document. The HTTP PUT method allows the client to cleanly send an XML document to the server. The HTTP POST method, however, requires name/value pairs in the payload. A client could submit an XML document using a name/value pair, where the value is an XML document. However, that doesn't seem very clean. In an XML-based Web I just want to exchange XML documents. The payload is clean - just an XML document. I would like to (boldly) assert that the name/value pair style is a remnant of HTML and is not suitable for an XML-based world! Thus, I propose that in The New Web that HTTP POST be dropped. I know what you are thinking: "Okay Roger, how do you do an update operation if you dump POST?" I am not sure. Perhaps it is specified in the XML document itself? Perhaps we need a new HTTP method for doing an update using an XML document? Thoughts? Comments? /Roger
Roger,
POST is not limited to name-value pairs. If you look at RFC 2616 section
9.5 [1], you will see no mention of canonically-encoded name-value pairs as
the only type of entity supported. The type is determined by Content-Type.
Most importantly, however, you will notice that the RFC defines POST as
being used to:
"...request that the origin server accept the entity
enclosed in the request as a new subordinate of the
resource identified by the Request-URI in the
Request-Line"
This is a key feature of the REST style. POSTing to a subordinate of a
known resource is an important feature, because it allows you to POST a
representation without knowing what the resource at the origin server will
do with it.
If you didn't have POST, having only GET and PUT would overcomplicate the
protocol. Everyone would need to create their own way of perhaps using
multiple GETs to discover the URI of a subordinate resource and use PUT to
send their representation to it.
-Philip
1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Friday, August 16, 2002 9:24 AM
To: rest-discuss@yahoogroups.com
Cc: Costello,Roger L.
Subject: [rest-discuss] No POST in an XML-based Web?
Hi Folks,
My vision of the next generation of the Web is that all HTML document
interchanges will be replaced by XML document interchanges. Thus, the
Web evolves from an HTML-based Web to an XML-based Web.
In an XML-based Web I question the utility of the HTTP POST method. The
HTTP GET method allows a client to cleanly retrieve an XML document.
The HTTP PUT method allows the client to cleanly send an XML document to
the server. The HTTP POST method, however, requires name/value pairs in
the payload. A client could submit an XML document using a name/value
pair, where the value is an XML document. However, that doesn't seem
very clean. In an XML-based Web I just want to exchange XML documents.
The payload is clean - just an XML document.
I would like to (boldly) assert that the name/value pair style is a
remnant of HTML and is not suitable for an XML-based world! Thus, I
propose that in The New Web that HTTP POST be dropped.
I know what you are thinking: "Okay Roger, how do you do an update
operation if you dump POST?" I am not sure. Perhaps it is specified in
the XML document itself? Perhaps we need a new HTTP method for doing an
update using an XML document? Thoughts? Comments? /Roger
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.
Thanks Philip. Very well stated. My ignorance. /Roger Phil Eskelin wrote: > > Roger, > > POST is not limited to name-value pairs. If you look at RFC 2616 section > 9.5 [1], you will see no mention of canonically-encoded name-value pairs as > the only type of entity supported. The type is determined by Content-Type. > Most importantly, however, you will notice that the RFC defines POST as > being used to: > > "...request that the origin server accept the entity > enclosed in the request as a new subordinate of the > resource identified by the Request-URI in the > Request-Line" > > This is a key feature of the REST style. POSTing to a subordinate of a > known resource is an important feature, because it allows you to POST a > representation without knowing what the resource at the origin server will > do with it. > > If you didn't have POST, having only GET and PUT would overcomplicate the > protocol. Everyone would need to create their own way of perhaps using > multiple GETs to discover the URI of a subordinate resource and use PUT to > send their representation to it. > > -Philip > > 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 > > -----Original Message----- > From: Roger L. Costello [mailto:costello@...] > Sent: Friday, August 16, 2002 9:24 AM > To: rest-discuss@yahoogroups.com > Cc: Costello,Roger L. > Subject: [rest-discuss] No POST in an XML-based Web? > > Hi Folks, > > My vision of the next generation of the Web is that all HTML document > interchanges will be replaced by XML document interchanges. Thus, the > Web evolves from an HTML-based Web to an XML-based Web. > > In an XML-based Web I question the utility of the HTTP POST method. The > HTTP GET method allows a client to cleanly retrieve an XML document. > The HTTP PUT method allows the client to cleanly send an XML document to > the server. The HTTP POST method, however, requires name/value pairs in > the payload. A client could submit an XML document using a name/value > pair, where the value is an XML document. However, that doesn't seem > very clean. In an XML-based Web I just want to exchange XML documents. > The payload is clean - just an XML document. > > I would like to (boldly) assert that the name/value pair style is a > remnant of HTML and is not suitable for an XML-based world! Thus, I > propose that in The New Web that HTTP POST be dropped. > > I know what you are thinking: "Okay Roger, how do you do an update > operation if you dump POST?" I am not sure. Perhaps it is specified in > the XML document itself? Perhaps we need a new HTTP method for doing an > update using an XML document? Thoughts? Comments? /Roger > > Yahoo! Groups Sponsor > ADVERTISEMENT > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > ________________________________________________________________________ > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. TradeWeb reserves the right to monitor all > e-mail communications through its networks.
Roger, I would say 'ignorance' is too pessimistic to mention on a Friday ;-). When I first embarked on developing my toolkit a few years ago, I had the same approach you described. I put an entire XML representation into a "result" name-value pair of a POST message for remote method invocations. The response would also have an "error" name an error occurred in processing the POST request. At the time, I couldn't explain why, but it seemed dirty. Then, after closely reading RFC 2616, and after experiencing a few epiphanies while reading Fielding's thesis, I realized this was a bogus approach, and almost anti-REST in nature. Now, I am more of an "clean-kitchen" HTTP purist. HTTP is king, and representations as remote method invocations are evil evil notions better left to the SOAP demagoguery. -Philip -----Original Message----- From: Roger L. Costello [mailto:costello@...] Sent: Friday, August 16, 2002 9:58 AM To: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] No POST in an XML-based Web? Thanks Philip. Very well stated. My ignorance. /Roger Phil Eskelin wrote: > > Roger, > > POST is not limited to name-value pairs. If you look at RFC 2616 section > 9.5 [1], you will see no mention of canonically-encoded name-value pairs as > the only type of entity supported. The type is determined by Content-Type. > Most importantly, however, you will notice that the RFC defines POST as > being used to: > > "...request that the origin server accept the entity > enclosed in the request as a new subordinate of the > resource identified by the Request-URI in the > Request-Line" > > This is a key feature of the REST style. POSTing to a subordinate of a > known resource is an important feature, because it allows you to POST a > representation without knowing what the resource at the origin server will > do with it. > > If you didn't have POST, having only GET and PUT would overcomplicate the > protocol. Everyone would need to create their own way of perhaps using > multiple GETs to discover the URI of a subordinate resource and use PUT to > send their representation to it. > > -Philip > > 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 > > -----Original Message----- > From: Roger L. Costello [mailto:costello@...] > Sent: Friday, August 16, 2002 9:24 AM > To: rest-discuss@yahoogroups.com > Cc: Costello,Roger L. > Subject: [rest-discuss] No POST in an XML-based Web? > > Hi Folks, > > My vision of the next generation of the Web is that all HTML document > interchanges will be replaced by XML document interchanges. Thus, the > Web evolves from an HTML-based Web to an XML-based Web. > > In an XML-based Web I question the utility of the HTTP POST method. The > HTTP GET method allows a client to cleanly retrieve an XML document. > The HTTP PUT method allows the client to cleanly send an XML document to > the server. The HTTP POST method, however, requires name/value pairs in > the payload. A client could submit an XML document using a name/value > pair, where the value is an XML document. However, that doesn't seem > very clean. In an XML-based Web I just want to exchange XML documents. > The payload is clean - just an XML document. > > I would like to (boldly) assert that the name/value pair style is a > remnant of HTML and is not suitable for an XML-based world! Thus, I > propose that in The New Web that HTTP POST be dropped. > > I know what you are thinking: "Okay Roger, how do you do an update > operation if you dump POST?" I am not sure. Perhaps it is specified in > the XML document itself? Perhaps we need a new HTTP method for doing an > update using an XML document? Thoughts? Comments? /Roger [snip] ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
Hi Roger,
Intriguing idea. But I think you're looking at it a bit too
document-oriented (:-)
In an XML-based web, GET would retrieve an XML document and/or structure
(given parameters), PUT would send an XML document and/or structure, and
POST would invoke a remote XML-based web-service.
A web-service would either require key-value parameters, or a 'structure'
that needs to be filled out and sent down. The form fields would be extended
to allow filling the structure data and then sending it to the remote
procedure.
For example, a weather service could either take a single parameter called
zip code (in which case, you could use PUT, or a simple form of POST) or a
more complex structure like:
<data name="params">
<city type="string" />
<state type="string" />
<country type="string" />
</data>
The form field names would then be something like:
params.city
params.state
params.country
and the user-agent would map its internal data (say, from a calling
web-service or an HTML FORM) into this structure before posting it to the
far end.
Just a thought,
Ramin
-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Friday, August 16, 2002 6:24 AM
To: rest-discuss@yahoogroups.com
Cc: Costello,Roger L.
Subject: [rest-discuss] No POST in an XML-based Web?
Hi Folks,
My vision of the next generation of the Web is that all HTML document
interchanges will be replaced by XML document interchanges. Thus, the
Web evolves from an HTML-based Web to an XML-based Web.
In an XML-based Web I question the utility of the HTTP POST method. The
HTTP GET method allows a client to cleanly retrieve an XML document.
The HTTP PUT method allows the client to cleanly send an XML document to
the server. The HTTP POST method, however, requires name/value pairs in
the payload. A client could submit an XML document using a name/value
pair, where the value is an XML document. However, that doesn't seem
very clean. In an XML-based Web I just want to exchange XML documents.
The payload is clean - just an XML document.
I would like to (boldly) assert that the name/value pair style is a
remnant of HTML and is not suitable for an XML-based world! Thus, I
propose that in The New Web that HTTP POST be dropped.
I know what you are thinking: "Okay Roger, how do you do an update
operation if you dump POST?" I am not sure. Perhaps it is specified in
the XML document itself? Perhaps we need a new HTTP method for doing an
update using an XML document? Thoughts? Comments? /Roger
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Guys, Has anybody done any work on creating a WSDL-equivalent for REST? I'm developing my own solution but I'm curious if there's work already being done. - jkk
> In an XML-based Web I question the utility of the HTTP POST method. The > HTTP GET method allows a client to cleanly retrieve an XML document. > The HTTP PUT method allows the client to cleanly send an XML document to > the server. The operation is not 'send' - it is 'set'. The server doesn't have as much freedom to choose how to handle the request. The constraint is that a GET will return a representation of the resource that should be the same state as what was PUT. > The HTTP POST method, however, requires name/value pairs in > the payload. Not true. POST supports Content-Type. I've used it to post xml for years. > A client could submit an XML document using a name/value > pair, where the value is an XML document. However, that doesn't seem > very clean. In an XML-based Web I just want to exchange XML documents. If it is still the 'Web', then you want to access and control resources. Exchanging documents is one use of the Web. > The payload is clean - just an XML document. > > I would like to (boldly) assert that the name/value pair style is a > remnant of HTML and is not suitable for an XML-based world! Thus, I > propose that in The New Web that HTTP POST be dropped. Re-examine the meaning of POST and PUT - I think you will find that their meanings are necessary: GET = get PUT = set POST = add DELETE = remove These are 'generic' - they apply to all resources - but that does not mean they are 'ambiguous' or open to wildly different server interpretations.
> ----- Original Message ----- > From: Ramin Firoozye > In an XML-based web, GET would retrieve an XML document and/or structure (given parameters), > PUT would send an XML document and/or structure, and POST would invoke a remote XML-based web-service. I hate to sound like yet another blind person feeling up an elephant... but a PUT would /set/ a remote resource to the state described by the message body, and a POST would /extend/ the resource targeted by the request with data described by the message body. > A web-service would either require key-value parameters, or a 'structure' that needs to be filled out and sent down. > The form fields would be extended to allow filling the structure data and then sending it to the remote procedure. A real WEB service would not require any particular content format, but would accept multiple formats. Simple name-value pairs in a name=value format or <name>value</name> or whatever would work. A more extensible structured XML would work. An GIF/JPG/PNG would work.
How so? Works for me with MSIE6 and Mozilla... ----- Original Message ----- From: "Chris Croome" <chris@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, August 16, 2002 3:50 AM Subject: Re: [rest-discuss] Http Digest Authentication > Hi > > On Fri 16-Aug-2002 at 07:40:43AM -0000, nixerman wrote: > > > > My question is: is the client expected to include the Digest HTTP > > header in all further requests to the server? > > Yes. > > I was reading the HTTP book that was recommended on this list the other > day and I was pleasantly surprised to read about the detail of digest > authentication, it's a shame it's not fully supported by current > browsers. > > Chris > > -- > Chris Croome <chris@...> > web design http://www.webarchitects.co.uk/ > web content management http://mkdoc.com/ > everything else http://chris.croome.net/ > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
nixerman wrote: > > Guys, > > Has anybody done any work on creating a WSDL-equivalent for REST? > > I'm developing my own solution but I'm curious if there's work > already being done. > > - jkk Various people have looked into this: WRDL: http://www.prescod.net/rest/wrdl/wrdl.html RestRDF: http://www.markbaker.ca/2002/03/RestRDF/ (http://216.239.33.100/search?q=cache:A3kH6uQIhDUC:www.markbaker.ca/2002/03/RestRDF/+restrdf&hl=en&ie=UTF-8) Jason Diamond did some work on something simple also but I don't have the URL equivalent. -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model http://216.239.33.100/search?q=cache:Pff2INpuzUgC:www.markbaker.ca/2001/09/draft-baker-http-resource-state-model+abstract+model+for+http+resource+state&hl=en&ie=UTF-8 "3.1.3.1 Identity-preserving composite state resources A specialized type of "composite state resource" described in section 3.1.3, this resource has the additional property that "P" assigns a new identity to the representation of the resource being POSTed, while making those resources available through "R". " I have a lot of trouble parsing that. First, can identity be assigned to representations? What is the "resource being posted"? Is that the same as the "resource being posted to"? What does "available through" mean? In a hypertext sense that there is a link from R to these resources? And anyway, why do we use the same method when we want to create new sub-resources versus mutate the existing resource? Seems confusing. Would a better name for "identity preserving" be "sub-resource creating?" -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
"Roger L. Costello" wrote: > Note that XForms is a standardized way of generating user interfaces that submit XML (or name-value pairs) through POST (and now PUT). -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
Hi On Fri 16-Aug-2002 at 02:40:51 -0700, Mark Nottingham wrote: > How so? Works for me with MSIE6 and Mozilla... I was under the impression, perhaps mistakenly, that features of improved digest authentication such as Replay Protection, Mutal Authentication, Repeat Client Security and Integrity Protection were not fully supported. I would be happy to be totally wrong about this :-) Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
What spec are these features mentioned in?
Thanks,
Walden Mathews
----- Original Message -----
From: Chris Croome
To: rest-discuss@yahoogroups.com
Sent: Saturday, August 17, 2002 11:58 AM
Subject: Re: [rest-discuss] Http Digest Authentication
Hi
On Fri 16-Aug-2002 at 02:40:51 -0700, Mark Nottingham wrote:
> How so? Works for me with MSIE6 and Mozilla...
I was under the impression, perhaps mistakenly, that features of
improved digest authentication such as Replay Protection, Mutal
Authentication, Repeat Client Security and Integrity Protection were not
fully supported. I would be happy to be totally wrong about this :-)
Chris
--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
everything else http://chris.croome.net/
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Hi On Sun 18-Aug-2002 at 08:26:45AM -0400, Walden Mathews wrote: > What spec are these features mentioned in? I read about them in 'HTTP Essentials' (a book) but I *think* this is the RFC: ftp://ftp.isi.edu/in-notes/rfc2617.txt Chris
Guys, Has it been established yet what the best practices are for resource creation? I know the verb PUT should be used with with the 201 Created code but what should the target of the verb be? Currently I'm using: PUT /app/rest/container/new <?xml version="1.0" encoding="utf-8"?> ... Where 'new' is a special dummy object which represents an uninitialized objects. The standard response is: HTTP 201 Created Location: /app/rest/container/4242 (eg) Host: http://www.example.com Other possible responses include 402 Payment Required, 403 Forbidden, 413 Request Entity Too Large. My questions: 1) What is the best way to indicate error to the client when the client sends malformed XML to the server? I'm not sure whether 407 Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I use 400 but the rfc says this error code should be avoided and the server should aim to be as specific as possible. 2) Does it make sense to have a dummy 'new' resource that is the target of resource creation request? You could ask what the result of GET /app/rest/container/new is and I'm not sure since it rarely makes sense. This leads me to believe resource creation should be done by a POST to the container where POST means 'Append'. The rfc is not completely clear on the difference in this unique case--it seems to indicate either PUT or POST works. 3) When the client is generating entities who is responsible for generating etags? The server is usually responsible because the server usually generated the resource, but when the client does resource generation should it have the burden of generating etags too? Should clients be trusted to generate etags? Thanks for your advice. - inthedarkplace
inthedarkplace wrote: > > Guys, > > Has it been established yet what the best practices are for resource > creation? I know the verb PUT should be used with with the 201 > Created code but what should the target of the verb be? For what you're doing, POST is correct. PUT would return the "/new" Location. PUT is like writing to a file (whether creating or overwriting). POST is like asking the server to create a new file with a particular content. >... > 1) What is the best way to indicate error to the client when the > client sends malformed XML to the server? I'm not sure whether 407 > Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I > use 400 but the rfc says this error code should be avoided and the > server should aim to be as specific as possible. You mean 406 Not Acceptable. I think that 406 is intended for declaring an inability to generate an acceptable *response* entity, not for rejecting the request entity. I think that 409 is similarly unsuitable because the problem has nothing to do with a clash between current state and intended state. So I think 400 is best: "The request could not be understood by the server due to malformed syntax." > 2) Does it make sense to have a dummy 'new' resource that is the > target of resource creation request? You could ask what the result of > GET /app/rest/container/new is and I'm not sure since it rarely makes > sense. This leads me to believe resource creation should be done by a > POST to the container where POST means 'Append'. The rfc is not > completely clear on the difference in this unique case--it seems to > indicate either PUT or POST works. I think POST is right. > 3) When the client is generating entities who is responsible for > generating etags? The server is usually responsible because the > server usually generated the resource, but when the client does > resource generation should it have the burden of generating etags > too? Should clients be trusted to generate etags? The client can't really do resource generation in REST. The client can hand a representation to the server and say "make this a resource please" but that's different. So in the end the server has responsibility for generating etags whether it created the resource from scratch or from a supplied representation. -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
On Fri, Aug 16, 2002 at 07:43:41PM -0400, Paul Prescod wrote: > "3.1.3.1 Identity-preserving composite state resources > > A specialized type of "composite state resource" described in > section 3.1.3, this resource has the additional property that "P" > assigns a new identity to the representation of the resource being > POSTed, while making those resources available through "R". > " > > I have a lot of trouble parsing that. First, can identity be assigned to > representations? Sure. They have identity. > What is the "resource being posted"? The wording assumes that the information being posted is the representation of an existing resource, which may not be the case, granted. > Is that the same > as the "resource being posted to"? No. The resource being posted to would be the container, like an email archive, for example. > What does "available through" mean? > In a hypertext sense that there is a link from R to these resources? Not just a link, but a subordinate relationship. e.g. you might be addressing http://example.org/foo/bar/baz, but /foo/bar/ could be a container which is code which decides if/when/how you get to look at 'baz'. The container may recognize that 'baz' is now unavailable and return a 404, or permanently gone and return a 410. etc.. > And anyway, why do we use the same method when we want to create new > sub-resources versus mutate the existing resource? Seems confusing. POST is the catch-all mutator in REST. If there's a need to break out a specific expected behaviour into its own method, then that's ok. But I personally prefer doing things in the POST-to-a-container model, ala SOAPAction. > Would a better name for "identity preserving" be "sub-resource > creating?" No, I was trying to get across that the processing done in P is loss-less. i.e. that what is POSTed will be what you get back when you do a GET on the Location header in the 201 response. Actually, I suppose that's more "state preserving" than "identity preserving", since there is no identity to preserve. Oops. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Guys, From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07- 11T21:50-08:00 <blockquote>For one, SOAP doesn't force me to encode my query as a URI (for example, I could use XML Query or XSLT to express the query expression). Also, SOAP's message model allows me to qualify queries through use of transport-neutral headers. For example, I may not have HTTP-based access to your machine, yet I may still want to send a SOAP request (over Jabber perhaps) that queries something on your box. By adopting the SOAP messaging model, I can express any number of aspects of my query (e.g., signatures, privacy requirements, idempotency, cache control) using fairly rich XML-based headers.</blockquote> Is this true? I don't see anything in the spec which says that a HTTP GET request is not allowed to have an entity body (and therefore contain XML documents or anything). Please comment. - inthedarkplace
On Mon, Aug 19, 2002 at 08:34:53PM -0000, inthedarkplace wrote: > Guys, > > From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07- > 11T21:50-08:00 > > <blockquote>For one, SOAP doesn't force me to encode my query as a > URI (for example, I could use XML Query or XSLT to express the query > expression). Also, SOAP's message model allows me to qualify queries > through use of transport-neutral headers. For example, I may not have > HTTP-based access to your machine, yet I may still want to send a > SOAP request (over Jabber perhaps) that queries something on your > box. By adopting the SOAP messaging model, I can express any number > of aspects of my query (e.g., signatures, privacy requirements, > idempotency, cache control) using fairly rich XML-based > headers.</blockquote> > > Is this true? I don't see anything in the spec which says that a HTTP > GET request is not allowed to have an entity body (and therefore > contain XML documents or anything). It's a feature, not a bug, that identifying information should go in the URI. There's a large cost for not doing so, in that you can't hand the identifier around to other people. So while it might be cool to use XML like this to identify me; <person>Mark Baker</person> There's no deployed way to actually turn that into information about me over a network. Oops! Besides, there's always my POST/201/GET idiom to get the best of both worlds, if you can afford an extra round trip; http://lists.w3.org/Archives/Public/www-tag/2002Jan/0232 And FWIW, the GET/body issue just popped up again on the HTTP WG mailing list; http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/thread.html#24 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I can't follow that URI but these are all standards complaints and IMO misguided. inthedarkplace wrote: > > Guys, > > From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07- > 11T21:50-08:00 > > <blockquote>For one, SOAP doesn't force me to encode my query as a > URI (for example, I could use XML Query or XSLT to express the query > expression). Let's be clear right off the bat that properly-executed REST is more syntactically restrictive than SOAP. REST imposes a discipline that leads to more interoperable applications. SOAP advocates only see the discipline and not the interoperability benefits. SOAP makes almost no demand on application developers. In all seriousness you can take a proprietary binary protocol and claim that it is legal SOAP and justify it through the SOAP specification! This issue of interoperability versus "flexibility" is discussed more here: * http://www.prescod.net/rest/rest_vs_soap_overview/ There is obviously nothing in HTTP that prevents querying using XML Query or XSLT over POST but it is usually not good REST design. In fact, it is usually not good *distributed application design*. Sending XML Query is like sending arbitrary SQL over the network. Sending XSLT is like sending executable code. Neither makes sense across the trust boundaries that make the Internet so interesting. I've discussed this here: * http://www.prescod.net/rest/rpc_for_get.html If you redesign your service interface to use the Web's query model rather than XML Query's, you get better security, better addressability, better interoperability and a simpler interface to boot. > ... Also, SOAP's message model allows me to qualify queries > through use of transport-neutral headers. If you and your partner agree to use SOAP you have to implement SOAP handlers on both ends. If you and your partner agree to use HTTP you have to implement HTTP handlers on both ends. HTTP headers are equally "transport neutral". They don't care whether you are using TCP or some proprietary protocol. > ... For example, I may not have > HTTP-based access to your machine, yet I may still want to send a > SOAP request (over Jabber perhaps) that queries something on your > box. What box in the world has Jabber but not HTTP? What implementation language is the jabber engine implemented in which is lacking an HTTP server like the free ones you can download for Java, Python, Perl, C, ... > ....By adopting the SOAP messaging model, I can express any number > of aspects of my query (e.g., signatures, privacy requirements, > idempotency, cache control) using fairly rich XML-based > headers.</blockquote> There are obviously standard HTTP headers for cache control and privacy. Idempotency is guaranteed by the methods (headers for idempotency don't make much sense to me). Signatures are no problem although I haven't seen that done myself. So Don is saying that with SOAP you *could do* all of these wonderful things in the future and I say that with HTTP you *can do* most of these wonderful things using existing standards today. -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
Okay, I know this has been talked about on the list in various ways before, but I am still trying to grasp what the "proper" format of RESTful URLs should be when taking into account the concept of sessions. To put this in context, I am starting up on a small project (written in PHP), the core of which will be a sort of content management system. Documents will be publicly viewable, but additional features will require people to log in and have an active "session". So, Here's the general layout of the paths I am going to use: /doc.php/docID "docID" will be a unique value that identifies a given document. The returned document (html only for now) will contain the following links: /doc.php/docID/discussions /doc.php/docID/references /doc.php/docID/revisions /doc.php/docID/subdocuments Each of those will contain additional links, etc. I am comfortable with this and it seems quite clean and simple to maintain. However, these URLs can be accessed in one of two modes. A given viewer can have GET access or can have POST access. GET access basically allows a viewer to follow links. However, there are several features where the view can choose to be interactive (e.g. create references, post discussion messages, etc.). When this is the case, the viewer must be authenticated. My current design requires a viewer to log in and create a session in order to provide the necessary authentication. Traditionally, I would have created a session ID and passed it around in the query string of every URL on a page. However, as I get more an more into REST, I am beginning to wonder if this is the right way of going about it. There has been discussion as to whether /doc.php/docID and /doc.php/docID?sid=12345 are equivalent URLs. My take on them (now) is that they are actually two different URLs that happen to return representations of the same resource. However, the second URL contains a series of characters (the entire query string in this case) that has nothing to do with the resource itself. Therefore, it seems to me that it is not appropriate to use this URL to point to the same resource as the first URL does, especially since in many of the cases the same exact representation will be returned to the viewer. I also do not want to use cookies to store the session ID for many reasons. So what do I do? How do I provide a common authentication mechanism that's supported by most browsers and still keeps the URLs simple can clean (and therefore more RESTful, I think)? Or am I totally misunderstanding the REST issues for tracking sessions? --- Seairth Jacobs seairth@...
On Mon, Aug 19, 2002 at 08:45:41PM -0400, Seairth Jacobs wrote: > I also do not want to use cookies to store the session ID for many reasons. > So what do I do? How do I provide a common authentication mechanism that's > supported by most browsers and still keeps the URLs simple can clean (and > therefore more RESTful, I think)? Use HTTP authentication, and have your app check to see if the request is authenticated or not while it constructs the content to return. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Heya Guys, I've been asked to rearchitect the design for a widely distributed content management system based on .NET, IRC and REST. I'm looking for any comments based on a simply single-signon system I'm reworking to make more REST-ful. I wrote up a quick summary of the existing system at: http://jkk.sumnurv.com/RWS-Signon-SpecLite.rtf Lemme know what you think. - inthedarkplace
Guys, I'm just wondering how people feel about WebDAV. Personally I don't like it since I feel there's a more elegant (read RESTful) way to develop it rather than adding verbs to HTTP 1.1. What do others think? - inthedarkplace
> From: inthedarkplace [mailto:inthedarkplace@...] > Sent: Tuesday, August 20, 2002 4:03 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] WebDAV > > > Guys, > > I'm just wondering how people feel about WebDAV. Personally I don't > like it since I feel there's a more elegant (read RESTful) way to > develop it rather than adding verbs to HTTP 1.1. > > What do others think? Make a proposal. I've seen some ideas about giving properties their own URLs, but those were just some ideas. One would need a more complete proposal to decide whether this would work well. Besides, why would be adding new verbs unRESTful?
> I've seen some ideas about giving properties their own URLs, but those were > just some ideas. One would need a more complete proposal to decide whether > this would work well. > > Besides, why would be adding new verbs unRESTful? Presumably adding a synonym for GET which only applied to properties would not be very RESTful, as they could be exposed as resources in their own right. Adding verbs for locking or other strange things with new and unusual semantics would certainly be a good idea though... Michael
> From: Michael Day [mailto:mikeday@...] > Sent: Tuesday, August 20, 2002 9:10 AM > To: rest-discuss@yahoogroups.com > Subject: RE: [rest-discuss] WebDAV > > > > > I've seen some ideas about giving properties their own URLs, > but those were > > just some ideas. One would need a more complete proposal to > decide whether > > this would work well. > > > > Besides, why would be adding new verbs unRESTful? > > Presumably adding a synonym for GET which only applied to > properties would > not be very RESTful, as they could be exposed as resources in their own Yes, they could. Possibly. I think the discussion would be more interesting if someone would present a workable proposal how to implement this, without losing the PROPFIND/depth 1 functionality of WebDAV. BTW: HEAD gets a fixed set of properties (entitity headers) as well. It's not really different from PROPFIND/depth 0. So is HEAD unRESTful? > right. Adding verbs for locking or other strange things with new and > unusual semantics would certainly be a good idea though... Correct. The interesting part is to decide wether a specific feature should be a new verb or can be "tunnelled" through existing methods.
> BTW: HEAD gets a fixed set of properties (entitity headers) as well. It's > not really different from PROPFIND/depth 0. So is HEAD unRESTful? More to the point, does anyone use HEAD on a regular basis? I would be interested to hear some uses people might have for it. Michael
> From: Michael Day [mailto:mikeday@...] > Sent: Tuesday, August 20, 2002 12:07 PM > To: rest-discuss@yahoogroups.com > Subject: RE: [rest-discuss] WebDAV > > > > > BTW: HEAD gets a fixed set of properties (entitity headers) as > well. It's > > not really different from PROPFIND/depth 0. So is HEAD unRESTful? > > More to the point, does anyone use HEAD on a regular basis? I would be > interested to hear some uses people might have for it. Well, we use it to fetch metadata about a resource without actually having to get it's contents. That's what it's for, right? Besides, GET gets the same amount of metadata as HEAD, and I don't think that anybody claims that GET is unRESTful :-)
Hi
On Tue 20-Aug-2002 at 08:06:32PM +1000, Michael Day wrote:
>
> More to the point, does anyone use HEAD on a regular basis? I would be
> interested to hear some uses people might have for it.
Yes, I use HEAD often, for checking HTTP headers:
$ lynx -head -dump http://example.com/
If you want to check GZ'ed content you have to use something else like
Apache benchmark:
$ /usr/local/apache/bin/ab -v 4 -n 1 -H \
"Accept-Encoding: gzip, deflate" -i http://example.com/
Chris
--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
everything else http://chris.croome.net/
Julian Reschke wrote: > >... > > Yes, they could. Possibly. I think the discussion would be more interesting > if someone would present a workable proposal how to implement this, without > losing the PROPFIND/depth 1 functionality of WebDAV. Is there any chance of the proposal making its way into software within our lifetimes or is it just for intellectual interest? ;) One could imagine combining the proposal with an idea unifying WebDAV properties with the RDF model. -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
> From: Paul Prescod [mailto:paul@...] > Sent: Tuesday, August 20, 2002 4:05 PM > To: Julian Reschke > Cc: Michael Day; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] WebDAV > > > Julian Reschke wrote: > > > >... > > > > Yes, they could. Possibly. I think the discussion would be more > interesting > > if someone would present a workable proposal how to implement > this, without > > losing the PROPFIND/depth 1 functionality of WebDAV. > > Is there any chance of the proposal making its way into software within > our lifetimes or is it just for intellectual interest? ;) Well, I'd imagine that this would just introduce a second way to access/modify metadata, so it could be introduced in a backwards-compatible way. I'm sure that if the model is sound and has real benefits over PROPFIND, Apache/moddav would adopt really fast... > One could imagine combining the proposal with an idea unifying WebDAV > properties with the RDF model. Interesting. Could you elaborate?
Julian Reschke wrote: > >... > > Well, > > I'd imagine that this would just introduce a second way to access/modify > metadata, so it could be introduced in a backwards-compatible way. I'm sure > that if the model is sound and has real benefits over PROPFIND, > Apache/moddav would adopt really fast... Okay, thanks. I don't know if I'll have time for it. > > One could imagine combining the proposal with an idea unifying WebDAV > > properties with the RDF model. > > Interesting. Could you elaborate? Truthfully, not really. I haven't thought it through yet. Basically it would be cool if you could use all RDF tools on WebDAV properties. Maybe you can do that now by just using RDF in properties. -- "When I walk on the floor for the final execution, I'll wear a denim suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk." Congressman James Traficant.
----- Original Message ----- From: "inthedarkplace" <inthedarkplace@...> > I know the verb PUT should be used with with the 201 > Created code but what should the target of the verb be? I think POST is fine with the 201 response as well. > > Currently I'm using: > PUT /app/rest/container/new > <?xml version="1.0" encoding="utf-8"?> > ... > > Where 'new' is a special dummy object which represents an > uninitialized objects. I think PUT to that URI means 'set' - so you would be better off using POST to create new resources. PUT is for updating known resources (a 'create' can be thought of as 'initial update'). > > 1) What is the best way to indicate error to the client when the > client sends malformed XML to the server? I'm not sure whether 407 > Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I > use 400 but the rfc says this error code should be avoided and the > server should aim to be as specific as possible. I wouldn't use "406 Not Acceptable" - this indicates that the format of the /response/ doesn't match what the request asked for. Problems with the format of the request probably should use "415 Unsupported Media Type" - "The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method" > > 2) Does it make sense to have a dummy 'new' resource that is the > target of resource creation request? You could ask what the result of > GET /app/rest/container/new is and I'm not sure since it rarely makes > sense. This leads me to believe resource creation should be done by a > POST to the container where POST means 'Append'. The rfc is not > completely clear on the difference in this unique case--it seems to > indicate either PUT or POST works. I'd recomment using POST as well.
Let's say I've already POSTed a purchase order, which has been accepted and assigned a URI by the server, and I'm allowed to modify it. I notice I've misspelled my name, so I want to correct that on the PO. I could PUT a corrected copy of the whole PO, but what method do I use if I only want to send the name field? The name is "subordinate" to the PO, but this is not an append type operation, and it happens to be idempotent, too. If I use an XML PO document with only the name field used, should that be a PUT, or is it always assumed that PUT carries the full state of the addressed resource? Walden Mathews
On Tue, Aug 20, 2002 at 09:02:57PM -0400, Walden Mathews wrote: > Let's say I've already POSTed a purchase order, which has been accepted and assigned > a URI by the server, and I'm allowed to modify it. I notice I've misspelled my name, so I want to > correct that on the PO. I could PUT a corrected copy of the whole PO, but what method do > I use if I only want to send the name field? The name is "subordinate" to the PO, but this is > not an append type operation, and it happens to be idempotent, too. If I use an XML PO > document with only the name field used, should that be a PUT, or is it always assumed that > PUT carries the full state of the addressed resource? Yup, the full state needs to go in a PUT. You could negotiate name-changing behaviour such that a POST of a representation of a name to the document resulted in the change, but that's extra work for little benefit, as I see it. You could also give the name its own URI, and do a PUT on it, but that has its own problems; that the PO is a contract, and so should be self-contained. In other non-contract cases, this might be ok. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> From: Paul Prescod [mailto:paul@...] > > > Julian Reschke wrote: > > > Interesting. Could you elaborate? > > Truthfully, not really. I haven't thought it through yet. > Basically it would be cool if you could use all RDF tools on > WebDAV properties. Maybe you can do that now by just using > RDF in properties. Mixing WebDAV with RDF is a win imo. The idea pops up every now and them on rdf lists. . I /think/ the WebDAV folks considered using RDF and decided not to. You should also look into DASL queries returning RDF graphs regards, Bill de hra .. Propylon www.propylon.com
Hello, We are developing a REST system using straight HTTP and RDF. We have n clients (both machine and humans) GETting and PUTting RDF into the system via HTTP. The question is, are there any security frameworks for a HTTP world where the URI is opaque? By that I mean, if the URI is virtual and doesn't have enough information in it to answer authorization questions, how would I go about securing my application? Since that is, obviously, a huge question, I'll try to add some requirements. Hopefully they are REST generic, as we are trying to stay within HTTP and REST. The interface into the system is HTTP, so our methods are PUT, GET, and DELETE. We then have users, and the objects they are PUT, GET, and DELETE. Using Apache as an example, I can control who can access what URIs via GET. That's fine if GET was the only method /and/ if the URIs are physical. In our case, we can PUT and DELETE, plus the URIs point to virtual resources (constructed from data in a database). We need to construct policies that have: - Actor - Method - URI - Content Filter Where: - Actor is the person (or machine) performing the HTTP call - Method is GET, PUT, or DELETE - URI is the (regexp?) pattern of the URI - Content Filter is a collection of filters that can validate the content (body) of the HTTP call. For instance, we need to allow Frank to PUT to /service/stuff/* ONLY documents that pass validations (like validate on an XML Schema or DAML+OIL schema) What we've found is that simple Actor+Method+URI policies aren't enough. We need to validate the incoming body of the HTTP request as well. So, are there frameworks out there that do this sort of thing? I looked at Apache and it doesn't seem to offer this type of control. Our application is written in Java and Servlets, and the servlet environment doesn't seem to have those types of controls, either. Any experience with this type of security system would be greatly appreciated! I'll post a summary of useful information. Thanks again, Seth
I would say that servlet has most of what you want, and the part it doesn't have has to come from your app anyhow. Servelt config allows you to use servlet-mapping syntax and HTTP methods to describe security domains, on each of which you can establish authentication and other security attributes. See the latest Servlet spec, or pick up Jason Hunter's O'Reilly book on the subject. Your application still needs to *authorize* users after they've been HTTP authenticated. And your application needs to apply whatever filters to the content to "authorize" that as well. Hope this helps, Walden Mathews > -----Original Message----- > From: Seth Ladd [mailto:seth@...] > Sent: Wednesday, August 21, 2002 10:06 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Security in a REST world? > > > Hello, > > We are developing a REST system using straight HTTP and RDF. > We have n > clients (both machine and humans) GETting and PUTting RDF into the > system via HTTP. > > The question is, are there any security frameworks for a HTTP world > where the URI is opaque? By that I mean, if the URI is virtual and > doesn't have enough information in it to answer authorization > questions, > how would I go about securing my application? > > Since that is, obviously, a huge question, I'll try to add some > requirements. Hopefully they are REST generic, as we are > trying to stay > within HTTP and REST. > > The interface into the system is HTTP, so our methods are > PUT, GET, and > DELETE. We then have users, and the objects they are PUT, GET, and > DELETE. Using Apache as an example, I can control who can > access what > URIs via GET. That's fine if GET was the only method /and/ > if the URIs > are physical. In our case, we can PUT and DELETE, plus the > URIs point > to virtual resources (constructed from data in a database). > > We need to construct policies that have: > > - Actor > - Method > - URI > - Content Filter > > Where: > > - Actor is the person (or machine) performing the HTTP call > - Method is GET, PUT, or DELETE > - URI is the (regexp?) pattern of the URI > - Content Filter is a collection of filters that can validate the > content (body) of the HTTP call. For instance, we need to > allow Frank > to PUT to /service/stuff/* ONLY documents that pass validations (like > validate on an XML Schema or DAML+OIL schema) > > What we've found is that simple Actor+Method+URI policies > aren't enough. > We need to validate the incoming body of the HTTP request as well. > > So, are there frameworks out there that do this sort of > thing? I looked > at Apache and it doesn't seem to offer this type of control. Our > application is written in Java and Servlets, and the servlet > environment > doesn't seem to have those types of controls, either. > > Any experience with this type of security system would be greatly > appreciated! I'll post a summary of useful information. > > Thanks again, > Seth >
Mark Baker wrote: > >... > > Yup, the full state needs to go in a PUT. > > You could negotiate name-changing behaviour such that a POST of a > representation of a name to the document resulted in the change, but > that's extra work for little benefit, as I see it. > > You could also give the name its own URI, and do a PUT on it, but that > has its own problems; that the PO is a contract, and so should be > self-contained. In other non-contract cases, this might be ok. So you are saying: "Use PUT but send the whole PO?" -- Paul Prescod
>Yup, the full state needs to go in a PUT.
> You could negotiate name-changing behaviour such that a POST of a
> re presentation of a name to the document resulted in the change, but
> that 's extra work for little benefit, as I see it.
If I POST the following XML (sans XML Schema namespace clutter)
<PO>
<name>Walden H. Mathews</name>
</PO>
to the URI at which the PO is living, what would need to be negotiated? In
other words,
what other interpretation of my intent do you see in that example?
Walden
On Wed, Aug 21, 2002 at 07:33:55AM -0700, Paul Prescod wrote: > So you are saying: "Use PUT but send the whole PO?" Yep. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, Aug 21, 2002 at 10:38:11AM -0400, Mathews, Walden wrote: > If I POST the following XML (sans XML Schema namespace clutter) > > <PO> > <name>Walden H. Mathews</name> > </PO> > > to the URI at which the PO is living, what would need to be negotiated? In > other words, > what other interpretation of my intent do you see in that example? Other interpretations of that action could be; - adding a contact who's allowed to sign for the package - adding a co-signer on the contract - adding information about the manager who authorized the purchase etc.. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Okay, but XML Schema could clear up all that confusion, couldn't it? Since I didn't share the schema here, I couldn't expect you to know that <PO/> allows exactly one <name/> element at that level. Do you still see multiple interpretations? > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Wednesday, August 21, 2002 10:47 AM > To: Mathews, Walden > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: PUT or POST Clarification > > > On Wed, Aug 21, 2002 at 10:38:11AM -0400, Mathews, Walden wrote: > > If I POST the following XML (sans XML Schema namespace clutter) > > > > <PO> > > <name>Walden H. Mathews</name> > > </PO> > > > > to the URI at which the PO is living, what would need to be > negotiated? In > > other words, > > what other interpretation of my intent do you see in that example? > > Other interpretations of that action could be; > > - adding a contact who's allowed to sign for the package > - adding a co-signer on the contract > - adding information about the manager who authorized the purchase > etc.. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
On Wed, Aug 21, 2002 at 11:01:50AM -0400, Mathews, Walden wrote: > Okay, but XML Schema could clear up all that confusion, couldn't it? > Since I didn't share the schema here, I couldn't expect you to know > that <PO/> allows exactly one <name/> element at that level. Do you > still see multiple interpretations? We might be able to construct an example where there's only one interpretation of a POST example, but that doesn't suggest that this is a good general solution. It would require rethinking how schemas are designed. For example, you wouldn't want to use "name" elements in multiple places, you'd have to use "purchaserName" and "shipToName", etc.. rather than using a "purchaser" element which includes a "name" element. That's quite a burden to place on schema designers. IMO, the best approach is to separate the concerns of specifying the valid state of resources (XML schema, RDF, etc..), from the ways in which the state is manipulated. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> Your application still needs to *authorize* users after they've been HTTP > authenticated. And your application needs to apply whatever filters to the > content to "authorize" that as well. Exactly. Authentication is easy, and nicely taken care of by the servlet container. It's the Authentication that becomes more difficult. What we're looking for is a framework that allows us to plug in rules for authorization and ask the question "Can User U PUT Data D?" easily. I haven't seen much in controling PUT and DELETE. I would love to do it in the Apache level, much like I can control GET there. Seth
<PO> <purchaser> <name>Walden H. Mathews</name> </purchaser> <ship-to> <name>Mark Q. Baker</name> </ship-to> </PO> I come from a market data feed application environment in which bandwidth conservation is king, and the rule of thumb is "send only the changes". According to our understanding of HTTP "morph" methods, it's not a good fit. But the above looks clearly intended to me. Of course the kind of optimization I'm trying for here depends on the MTU, something which in HTTP/TCP I can't influence, whereas I "owned" that part of the transport in my datafeed apps. Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Wednesday, August 21, 2002 11:14 AM > To: Mathews, Walden > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: PUT or POST Clarification > > > On Wed, Aug 21, 2002 at 11:01:50AM -0400, Mathews, Walden wrote: > > Okay, but XML Schema could clear up all that confusion, couldn't it? > > Since I didn't share the schema here, I couldn't expect you to know > > that <PO/> allows exactly one <name/> element at that level. Do you > > still see multiple interpretations? > > We might be able to construct an example where there's only one > interpretation of a POST example, but that doesn't suggest that this > is a good general solution. It would require rethinking how schemas > are designed. For example, you wouldn't want to use "name" elements > in multiple places, you'd have to use "purchaserName" and > "shipToName", > etc.. rather than using a "purchaser" element which includes a "name" > element. That's quite a burden to place on schema designers. > > IMO, the best approach is to separate the concerns of specifying the > valid state of resources (XML schema, RDF, etc..), from the ways in > which the state is manipulated. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
I'd implement it as a proxy, and put all my rules there. Authentication would remain at the origin server, and the proxy would know that. MB On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote: > > > Your application still needs to *authorize* users after they've been HTTP > > authenticated. And your application needs to apply whatever filters to the > > content to "authorize" that as well. > > Exactly. Authentication is easy, and nicely taken care of by the > servlet container. It's the Authentication that becomes more difficult. > What we're looking for is a framework that allows us to plug in rules > for authorization and ask the question "Can User U PUT Data D?" easily. > I haven't seen much in controling PUT and DELETE. I would love to do > it in the Apache level, much like I can control GET there. > > Seth -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, Aug 21, 2002 at 11:34:08AM -0400, Mathews, Walden wrote: > <PO> > <purchaser> > <name>Walden H. Mathews</name> > </purchaser> > <ship-to> > <name>Mark Q. Baker</name> > </ship-to> > </PO> Ok, like I say I'm sure there's a way to construct an example with a single interpretation. You'd just have to jump through hoops to do this as a general solution. It also doesn't help if you don't control the schemas you're using, which will become increasingly common as their standardized. > I come from a market data feed application environment in which > bandwidth conservation is king, and the rule of thumb is "send only > the changes". According to our understanding of HTTP "morph" > methods, it's not a good fit. But the above looks clearly intended > to me. Have you looked at RFC 3229? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
FYI, http://www.oetrends.com/cgi-bin/page_display.cgi?82 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Hmmm, coming from an "entitlement" application background, I'm wondering whether standard entitlement (authorization) proxy software already exists, or whether we should beat feet and get ours out there in HTTP proxy land. Seth, when you say "can user U PUT data D?", by "data" do you mean the URI, or do you mean the content (which I understand you wish to filter). If the former, then I think you're missing the full power of the servlet spec if you believe this can be done for GET but not for PUT, DELETE, etc. Walden -----Original Message----- From: Mark Baker [mailto:distobj@...] Sent: Wednesday, August 21, 2002 11:35 AM To: Seth Ladd Cc: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] Security in a REST world? I'd implement it as a proxy, and put all my rules there. Authentication would remain at the origin server, and the proxy would know that. MB On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote: > > > Your application still needs to *authorize* users after they've been HTTP > > authenticated. And your application needs to apply whatever filters to the > > content to "authorize" that as well. > > Exactly. Authentication is easy, and nicely taken care of by the > servlet container. It's the Authentication that becomes more difficult. > What we're looking for is a framework that allows us to plug in rules > for authorization and ask the question "Can User U PUT Data D?" easily. > I haven't seen much in controling PUT and DELETE. I would love to do > it in the Apache level, much like I can control GET there. > > Seth -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca <http://www.markbaker.ca> http://www.idokorro.com <http://www.idokorro.com> Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=228862.2128520.3581629.2204139/D=egroupweb/S=17057010 14:HM/A=1182694/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-336> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
> Have you looked at RFC 3229? Just did, THANKS! Where do I send your librarian fee? Walden
> Seth, when you say "can user U PUT data D?", by "data" do you mean the > URI, or do you mean > the content (which I understand you wish to filter). If the former, > then I think you're missing the > full power of the servlet spec if you believe this can be done for GET > but not for PUT, DELETE, > etc. Good question. I mean the content (the body of the HTTP message). I have to do validation on the content for obvious reasons. In my mind there is basic validation which I can easily mark up as rules (regexp, xpath statements, even xml schema). That's the stuff I want to validate automatically. Of course, there is some business validation which would be harder to do via declarative rules which I would still have to support. Controlling the URI is easy. Problem is, the URI doesn't have enough information in it to help me do all validation (by design). So there is a second level of authorization control by looking at the actual content of the message. That is what I was wondering if existed before. A step closer is to do XML Schema validation on the content. That's close, but not perfect. For example: Bob can PUT <stuff>A</stuff> Alice can PUT <stuff>B</stuff> Notice the contents of the stuff tag are different for each person. If I need to support rules like that, I'd need two versions of the XML Schema. To me, XPath statements are small enough to collect a large number of them for each user. They can also be stored in the database. Problem with that is our data is RDF/XML. Since the RDF can be encoded in multiple valid ways, I can't write an XPath that can validate any RDF. I'm currently toying with the idea of creating an XML Schema that can parse correctly as RDF. That way, I still get benefits of RDF (once I tie into DAML+OIL schemas and do my inferencing) plus I can do XPath statements that I know will validate the document. Also, I can store my validation rules in a database, and attach these rules as policies to URI patterns. *phew* Does this gel, or am I going at it completely wrong? Thanks! Seth
Mark Baker wrote: > I'd implement it as a proxy, and put all my rules there. Authentication > would remain at the origin server, and the proxy would know that. Yes. In fact, we're doing it as a servlet filter (a convenient way to pre and post process HTTP requests). Question is: is there a security framework for HTTP servers already (other than GET)? Seth
> Bob can PUT <stuff>A</stuff> > Alice can PUT <stuff>B</stuff> I assume you mean to the same URI. That's wierd, in my experience. Usually, the test is "what object can I access?", and "through what methods?". Then, the content, while a valid concern from a data integrity angle, is kind of orthogonal to security issues per se. Makes me wonder if your application design has identified the right resources, and whether reanalysis might clear up your "security" problem. Well, they don't call me "Mr-Start-Over-From-Scratch" for nothing, but FWIW. Walden
At 01:50 AM 22/08/2002, Mark Baker wrote: >http://www.oetrends.com/cgi-bin/page_display.cgi?82 One factual error - in the resources and links section it says "OET found one of the *best* interviews on "real world" of REST at the Tech Target network ...". If you read that interview it has a couple of gems in it such as "If it's (REST) so simple, why hasn't it caught on like SOAP has? - It's not as powerful. With REST, you're just grabbing content. " and "Let's say I got the values from you, and I wanted to let you know that they're wrong. If I wanted to send you back something that says they're wrong, with REST that can't be done. With REST, you request information, you get it, and that's where it ends." Unfortunately, there is no facility to make comments on either of the articles. Robert PS Thinking on it, it may not be a factual error - if the real world thinks that way about REST, it may actually be one of the *best* interviews on "real world" of REST :-)
You might want to look at Netegrity - they have a bunch of security software that is HTTP aware. I doubt they can do /everything/ you are talking about, but they probably have URI based filtering & stuff.
I'm suprised Apache doesn't have rules that can operate against headers (like Content-Type, Content-Length, etc.)
----- Original Message -----
From: Mathews, Walden
To: 'Mark Baker' ; Seth Ladd
Cc: rest-discuss@yahoogroups.com
Sent: Wednesday, August 21, 2002 8:57 AM
Subject: RE: [rest-discuss] Security in a REST world?
Hmmm, coming from an "entitlement" application background, I'm wondering whether standard
entitlement (authorization) proxy software already exists, or whether we should beat feet and
get ours out there in HTTP proxy land.
Seth, when you say "can user U PUT data D?", by "data" do you mean the URI, or do you mean
the content (which I understand you wish to filter). If the former, then I think you're missing the
full power of the servlet spec if you believe this can be done for GET but not for PUT, DELETE,
etc.
Walden
-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, August 21, 2002 11:35 AM
To: Seth Ladd
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Security in a REST world?
I'd implement it as a proxy, and put all my rules there. Authentication
would remain at the origin server, and the proxy would know that.
MB
On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote:
>
> > Your application still needs to *authorize* users after they've been HTTP
> > authenticated. And your application needs to apply whatever filters to the
> > content to "authorize" that as well.
>
> Exactly. Authentication is easy, and nicely taken care of by the
> servlet container. It's the Authentication that becomes more difficult.
> What we're looking for is a framework that allows us to plug in rules
> for authorization and ask the question "Can User U PUT Data D?" easily.
> I haven't seen much in controling PUT and DELETE. I would love to do
> it in the Apache level, much like I can control GET there.
>
> Seth
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Just making the implicit hyperlink into an explicit one...
RFC 3229
http://www.faqs.org/rfcs/rfc3229.html
Abstract
This document describes how delta encoding can be supported as a
compatible extension to HTTP/1.1.
Many HTTP (Hypertext Transport Protocol) requests cause the retrieval
of slightly modified instances of resources for which the client
already has a cache entry. Research has shown that such modifying
updates are frequent, and that the modifications are typically much
smaller than the actual entity. In such cases, HTTP would make more
efficient use of network bandwidth if it could transfer a minimal
description of the changes, rather than the entire new instance of
the resource. This is called "delta encoding."
[...]
The goals do not include:
[...]
- Delta encoding of request messages, or of responses to methods
other than GET.
----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
To: "'Mark Baker'" <distobj@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, August 21, 2002 9:06 AM
Subject: RE: [rest-discuss] Re: PUT or POST Clarification
> > Have you looked at RFC 3229?
>
> Just did, THANKS!
>
> Where do I send your librarian fee?
>
> Walden
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> I assume you mean to the same URI. That's wierd, in my experience. > Usually, > the test is "what object can I access?", and "through what methods?". Then, > the content, while a valid concern from a data integrity angle, is kind of > orthogonal to security issues per se. Makes me wonder if your application > design > has identified the right resources, and whether reanalysis might clear up > your > "security" problem. Excellent points! And I've thought of them a lot, so they are totally valid concerns. Our security has to control the object itself, PLUS the content of the object. Take the example of PUTting an object from client to server. The object's URI has no information about what the object is. So the server can not base security around the URI. In our app, there is no difference between /blah/foo and /lee/laa. Both are merely primary keys/URIs. So to say that Seth can PUT /blah/foo/* isn't saying enough. Because all the content is XML, I need to verify that what Seth is putting into /blah/foo/* makes sense. The only real check I need to do for a PUT is if the URI has been created yet or not. You're right in that this (what I've been talking about) is a data integrity concern. We've been modeling it as "Does Seth have permission to say that?" with 'that' being the contents of the HTTP message. The issue is very hard with PUT, since we can't write a policy for the object ID of the thing the client is PUTting since it doesn't exist yet. We can only look at the incoming data to see if it is correct. One way around this problem is to start using POST. We can write a policy around POST and the object the client is POSTing to. Since that object has to exist for the client to POST to it, we're able to control access to it. POST would then become this "doIt" type of action/method, which we'd like to avoid. In a SOAP world I don't have to worry too much about the contents of the message, since they have to be marshalled and unmarshalled by the SOAP engine anyway. Any errors in content and formating will be picked up and result in a SOAP Fault of some sort. In the REST world, I have to build that validation into every PUT. With GET, it's a bit easier, since the object itself exists in the system. I can place policies around existing objects easily to control access via GET. It's fun to find these real world issues involved with building a pure HTTP/RDF+XML system. I'm hoping that the solutions that come out of this project will be reusable in the ever so wished for "REST Toolkit". thoughts? thanks! Seth
http://hjukalsk.tripod.com/index.html
On Wed, Aug 21, 2002 at 11:02:08AM -0700, S. Mike Dierken wrote: > The goals do not include: > [...] > - Delta encoding of request messages, or of responses to methods > other than GET. Right. But it also says; "Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used." RFC 2774 should help with that problem. There would still be some issues with PUT, such as ensuring that the message remains stateless. I think that specifying a target etag as part request would help, but I haven't thought it through. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, Aug 21, 2002 at 09:11:31PM -0400, Mark Baker wrote: > There would still be some issues with PUT, such as ensuring that the > message remains stateless. I think that specifying a target etag as > part request would help, but I haven't thought it through. Erm, with If-Match, of course. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
So here is the problem we are talking about:
We start by PUTting a resource on a server. The server returns a URL to the
newly created resource. Later, we realize that we need to change a part of
the resource, so we want to update only that part. So why not just POST the
entire "resource" (the same that was PUT earlier, but now with the change)
to the given URL for the resource? The server can then compare them and
determine if the change is allowed or not.
As an alternative, when the original resource is PUT on the server, the
server could return a series of URLs. The first URL would be for the
resource itself. The additional URLs would be for different representations
of the resource that effectively allow limited interaction with parts of the
resource. For instance, you may get a response like this:
<purchaseOrder>
<URL>http://sample.com/path/purchaseOrders/12345</URL>
<editable>
<ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship
pingAddressURL>
<ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship
pingMethodURL>
</editable>
</purchaseOrder>
Now, you could POST to any of the above URLs the parts that you want to
update. If the requested update is in the shipping address only, then you
could use <ShippingAddressURL> and send only that part of the purchaseOrder.
This technique would allow each business to determine how much or how little
of the resource can be edited simply by returning only the URLs that allow
editing. Of course, this technique is that it requires both parties to know
a common vocabulary, which may or may not be a good thing. :)
Or has all of this been covered already? :)
---
Seairth Jacobs
seairth@...
Woohoo. REST spam. I wonder if it's best to get the pictures using GET,
PUT, or POST? (:-)
-----Original Message-----
From: usgqmsku [mailto:usgqmsku@...]
Sent: Wednesday, August 21, 2002 5:39 PM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] New Pics Here...
http://hjukalsk.tripod.com/index.html
Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Seairth,
I've found this to pretty much be a bad idea. Originally, in my app, I was going with a design that called for urls like:
/users/{UserID} ---> represents the user
/users/{UserID}/realname ---> the real name of the user
/users/{UserID}/email ---> the email addy of the user
Your application simply needs to be smart enough to figure out what's going on. This allows users to only expose specific information as well as allowing users to update only specific parts of their profile. eg
PUT /users/{UserID}/email
<rwss:user><rwss:email>dwfefwfwefwe</rwss:email></rwss:user>
The problem with this is that I've found it essentially destroys HTTP caching controls. A client webservice can do a GET on /users/{userID}/email. Then another webservice can do a PUT /users/{userID} to change all information about the user including the email. Then when the first webservice does another GET on /users/{userID}/email they don't get the new email.
This could just be due to my poor understanding of caching, but I think the issue simply goes to the heart of REST. Only objects which are truly resources, that is informationally significant, should be assigned URIs. Further, all messages should be coarse-grained and represent the complete state of the resource. Adam Bosworth has said a lot on coarse-grained messaging -- http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/
Anywyas, just my 2c
Seairth Jacobs wrote:So here is the problem we are talking about:
We start by PUTting a resource on a server. The server returns a URL to the
newly created resource. Later, we realize that we need to change a part of
the resource, so we want to update only that part. So why not just POST the
entire "resource" (the same that was PUT earlier, but now with the change)
to the given URL for the resource? The server can then compare them and
determine if the change is allowed or not.
As an alternative, when the original resource is PUT on the server, the
server could return a series of URLs. The first URL would be for the
resource itself. The additional URLs would be for different representations
of the resource that effectively allow limited interaction with parts of the
resource. For instance, you may get a response like this:
<purchaseOrder>
<URL>http://sample.com/path/purchaseOrders/12345</URL>
<editable>
<ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship
pingAddressURL>
<ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship
pingMethodURL>
</editable>
</purchaseOrder>
Now, you could POST to any of the above URLs the parts that you want to
update. If the requested update is in the shipping address only, then you
could use <ShippingAddressURL> and send only that part of the purchaseOrder.
This technique would allow each business to determine how much or how little
of the resource can be edited simply by returning only the URLs that allow
editing. Of course, this technique is that it requires both parties to know
a common vocabulary, which may or may not be a good thing. :)
Or has all of this been covered already? :)
---
Seairth Jacobs
seairth@...
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New JobsYah, it looks like the spammers have got the auto-subscribe bot working for Yahoo Groups, because this "person" signed up last week (why the lag?). If this becomes a problem, I'll have to moderate membership (*not* the list, just who can join). Bah. BTW, we were at 200 members until I deleted the spammer. 8-) Very cool. MB On Wed, Aug 21, 2002 at 07:29:32PM -0700, Ramin Firoozye wrote: > Woohoo. REST spam. I wonder if it's best to get the pictures using GET, > PUT, or POST? (:-)
> We start by PUTting a resource on a server. The server returns a URL to the > newly created resource. If you use PUT, then the URI you PUT to /is/ the created resource. It may be possible that some response headers to PUT provide for a more 'canonical' location, but I don't know much about that. If you use POST, then the server would/could return the URI of any new resource created. > Later, we realize that we need to change a part of > the resource, so we want to update only that part. So why not just POST the > entire "resource" (the same that was PUT earlier, but now with the change) > to the given URL for the resource? The server can then compare them and > determine if the change is allowed or not. Sounds reasonable, but PUT means the same thing and is more specific. For modifying portions of a resource, you could URI-ify those via sub-uris or 'segment parameters'. For example: "property32" could be the name of the shipping address of a PO or something. http://www.example.org/resources/resource27;property32/ or http://www.example.org/resources/resource27/property32/ > > As an alternative, when the original resource is PUT on the server, the > server could return a series of URLs. The first URL would be for the > resource itself. The additional URLs would be for different representations > of the resource that effectively allow limited interaction with parts of the > resource. For instance, you may get a response like this: > > <purchaseOrder> > <URL>http://sample.com/path/purchaseOrders/12345</URL> > <editable> > > <ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship > pingAddressURL> > > <ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship > pingMethodURL> > </editable> > </purchaseOrder> Sure. I'd use POST, and relative URIs but the concept is sound. You might even be able to 'annotate' existing PO schemas with href attributes and not have to invent too much on your own. > > > Now, you could POST to any of the above URLs the parts that you want to > update. PUT may make more sense. PUT = set, POST = add/extend/remove/etc. > If the requested update is in the shipping address only, then you > could use <ShippingAddressURL> and send only that part of the purchaseOrder. > This technique would allow each business to determine how much or how little > of the resource can be edited simply by returning only the URLs that allow > editing. Very nice. Or provide the URI - so people can 'get' - but have permissions for the other operations. > Of course, this technique is that it requires both parties to know > a common vocabulary, which may or may not be a good thing. :) > > > Or has all of this been covered already? :) > > --- > Seairth Jacobs > seairth@... > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
----- Original Message -----
From: "Terrence Molson" <inthedarkplace@...>
> The problem with this is that I've found it essentially destroys HTTP
caching controls.
> A client webservice can do a GET on /users/{userID}/email.
> Then another webservice can do a PUT /users/{userID} to change all
> information about the user including the email.
> Then when the first webservice does another GET on /users/{userID}/email
they don't get the new email.
This is a very good point. I haven't found any good answers.
> This could just be due to my poor understanding of caching, but I think
the issue
> simply goes to the heart of REST. Only objects which are truly resources,
that is informationally significant,
> should be assigned URIs.
I'm not sure this is a good constraint or not. I think of it in terms of
'overlapping' resources. I don't know that it /can/ be avoided in any
practical system.
> Further, all messages should be coarse-grained and represent the complete
state of the resource.
All for that. I still don't rule out 'overlapping' resources though. I'd
like to hear some more discussion on this point.
This topic seems to be a real stickler for REST newbies, so I've written up a rather long winded explanation of the role that each method plays in the Big Picture - and outlined said Big Picture in the process, in (hopefully) more approach language than with RestRDF. http://www.markbaker.ca/2002/08/HowContainersWork/ MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Wed, Aug 21, 2002 at 08:35:27PM -0700, S. Mike Dierken wrote:
> > The problem with this is that I've found it essentially destroys HTTP
> caching controls.
> > A client webservice can do a GET on /users/{userID}/email.
> > Then another webservice can do a PUT /users/{userID} to change all
> > information about the user including the email.
> > Then when the first webservice does another GET on /users/{userID}/email
> they don't get the new email.
>
> This is a very good point. I haven't found any good answers.
It was the late Phil Karlton who said that there were two hard problems
in computer science; naming, and cache invalidation. Sounds about
right. 8-)
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
>
> ----- Original Message -----
> From: "Terrence Molson" <inthedarkplace@...>
>
> > The problem with this is that I've found it essentially destroys HTTP
> caching controls.
> > A client webservice can do a GET on /users/{userID}/email.
> > Then another webservice can do a PUT /users/{userID} to change all
> > information about the user including the email.
> > Then when the first webservice does another GET on /users/{userID}/email
> they don't get the new email.
>
> This is a very good point. I haven't found any good answers.
It might be possible that if the intermediary does a HEAD/GET
If-modified-since or possibly using etag then it can detect changes -
assuming the origin server correctly knows the relationship between
/users/{userID}/email and /users/{userID}
This is more networking and probably not worth it unless the responses are
huge (many packets).
Another brute force approach would be to have the cache indicate interest in
/users/{userID}/email via a subscription and have the origin server echo
changes to /users/{userID}to listeners.
> If you use PUT, then the URI you PUT to /is/ the created resource. It may be > possible that some response headers to PUT provide for a more 'canonical' > location, but I don't know much about that. > If you use POST, then the server would/could return the URI of any new > resource created. That is pretty much my understanding. My problem I'm wrestling with when I use PUT is I can't set up a security policy for the PUT. I don't know how to control access to a resource that doesn't exist yet. It is because of that I am currently considering POST, since the resource must exist before hand, and therefor I can control access to it. Any ideas? Seth
Just RESTifying the email, Dierken-style: RFC 2774: http://www.ietf.org/rfc/rfc2774.txt?number=2774 <http://www.ietf.org/rfc/rfc2774.txt?number=2774> -----Original Message----- From: Mark Baker [mailto:distobj@...] Sent: Wednesday, August 21, 2002 9:12 PM To: S. Mike Dierken Cc: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] Re: PUT or POST Clarification On Wed, Aug 21, 2002 at 11:02:08AM -0700, S. Mike Dierken wrote: > The goals do not include: > [...] > - Delta encoding of request messages, or of responses to methods > other than GET. Right. But it also says; "Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used." RFC 2774 should help with that problem. There would still be some issues with PUT, such as ensuring that the message remains stateless. I think that specifying a target etag as part request would help, but I haven't thought it through. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca <http://www.markbaker.ca> http://www.idokorro.com <http://www.idokorro.com> Yahoo! Groups Sponsor <http://rd.yahoo.com/M=229641.2166546.3626727.2204139/D=egroupweb/S=17057010 14:HM/A=1142328/R=0/*http://promo.yahoo.com/debtscape/> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
Mathews, Walden wrote: > Seth, > > I'm left having to infer a lot from your description of your app because > you're not saying > what the application domain is. That's your call, but it might be > easier if you said. Yeah, sorry about being vague with the application. I felt it wasn't important to the security discussion, so I didn't want to create the noise. > except that within your server application core there MUST be some > mapping from > URI to object, even if it's just a hash, or the app has no chance of > working. So your > objection is that you can't push data validation out into the servlet > container... That mapping you speak of is done by looking at the content. The content of the PUT is RDF, and there is a Statement that tells me what type the RDF object is. I can look at that to determine where to store this object. The URI unfortunately doesn't tell me enough information to determine (and often infer) the type of the resource. I'm not objecting to pushing data validation into the servlet container. In fact, I think that's the only place I can do it. I was wondering if there was an existing framework for the types of security checks I need to it. Here is an example: http://example.com/car - A car object that people can drive In the NON-REST world, if I wanted to drive it, I would do: car.drive(start, finish) But we all know and love REST, so I would do this in the REST world: car.create(new Trip(start, finish)) or even: server.create( new Trip(car, start, finish) ) In other words, I have to create a noun (an object/resource) that describes the action that I want to take place. So instead of driving the car via drive(), I have to create (or PUT) a Trip. If I'm wrong about the above assumption, please let me know. That might be the root of my problems. :) Assuming I need to create a Trip, let's now talk about security. Person A can drive the car from Point P1 to Point P2. Person B can drive the car from Point P1 to Point P3. So, Person A can: server.create( new Trip(car, P1, P2) ) And that should pass. If Person A tries to: server.create( new Trip(car, P1, P3) ) That should fail. So now I'm looking at data validation as a means to control access to the data. REST is about information, not methods, so it makes sense I have to create a security framework that validates the data. What do the RESTphiles think of the above example? > > If you use POST to an 'object container' URI and let the server assign > URIs upon > object creation, does that solve that part of the problem? Note that That certainly does make it easier. I'm currently leaning towards the container idea and appending objects to it. Makes controlling access to a resource a lot easier. Still have to do data validation, though, but that's cool. Seth
Mark, HowContainersWork does a nice job of explaining how an application should use HTTP to *create* new resources. I'd like it if you'd append a section that details the *updating* of resources, especially to make it clear that when you PUT, you are including the ENTIRE state of the addressed resource, and that if you wish to update a subset of that state, you need to either view that through some kind of composite model in which the subset has identity, or you need to negotiate a way for the server to distinguish the POST of a subordinate (subset) as "update" vs "create". Thanks, Walden -----Original Message----- From: Mark Baker [mailto:distobj@...] Sent: Wednesday, August 21, 2002 11:46 PM To: Seairth Jacobs Cc: rest-discuss Subject: Re: [rest-discuss] PUT or POST Clarification This topic seems to be a real stickler for REST newbies, so I've written up a rather long winded explanation of the role that each method plays in the Big Picture - and outlined said Big Picture in the process, in (hopefully) more approach language than with RestRDF. http://www.markbaker.ca/2002/08/HowContainersWork/ <http://www.markbaker.ca/2002/08/HowContainersWork/> MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca <http://www.markbaker.ca> http://www.idokorro.com <http://www.idokorro.com> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
> Yeah, sorry about being vague with the application. I felt it wasn't > important to the security discussion, so I didn't want to > create the noise. Yes, but now we know it's not a security issue. > That mapping you speak of is done by looking at the content. The > content of the PUT is RDF, and there is a Statement that > tells me what > type the RDF object is. I can look at that to determine > where to store > this object. The URI unfortunately doesn't tell me enough > information > to determine (and often infer) the type of the resource. I think you're carrying the opaqueness of URI too far. As I understand, URI should be opaque *to clients*, but are allowed to be (and should be encouraged to be) meaningful for servers. Else you're constrained to "bag" storage at the conceptual level, and that looks like your problem at this point. > I'm not objecting to pushing data validation into the servlet > container. > In fact, I think that's the only place I can do it. You read me wrong. I said you objected to NOT being able to push validation all the way out. Not knowing your application, it's not for me to say, except that pushing ALL validation out to the container leaves you what for an application? > Here is an example: > > http://example.com/car - A car object that people can drive > > In the NON-REST world, if I wanted to drive it, I would do: > > car.drive(start, finish) Curious as to what that means. To begin with, the car ought to know where it's starting from, i.e., where it is now, no? > > But we all know and love REST, so I would do this in the REST world: Note the order above: KNOW comes before LOVE :-) > In other words, I have to create a noun (an object/resource) that > describes the action that I want to take place. So instead > of driving > the car via drive(), I have to create (or PUT) a Trip. In my most orthodox interpretation of Representational State Transfer, I believe you can accomplish your trip by PUTting a version of your car whose current location is the destination you seek. But we don't really know what the purpose of Car is, so again we're kind of stuck giving advice. > Assuming I need to create a Trip, let's now talk about security. > > Person A can drive the car from Point P1 to Point P2. > Person B can drive the car from Point P1 to Point P3. > > So, Person A can: > > server.create( new Trip(car, P1, P2) ) > > And that should pass. If Person A tries to: > > server.create( new Trip(car, P1, P3) ) > > That should fail. > > So now I'm looking at data validation as a means to control access to > the data. REST is about information, not methods, so it > makes sense I > have to create a security framework that validates the data. > > What do the RESTphiles think of the above example? The model seems broken because you can only drive the car from P1 to P-something if the car is at P1. As I process it, P2 is a resource accessible person A, while P3 is a resource not accessible to person A. So if you modeled destinations as resources and make their URIs meaningful to the server, then you can "push" some of that validation out, it seems. But I have low confidence yet that I understand your application. > > > > > If you use POST to an 'object container' URI and let the > server assign > > URIs upon > > object creation, does that solve that part of the problem? > Note that > > That certainly does make it easier. I'm currently leaning > towards the > container idea and appending objects to it. Makes > controlling access to > a resource a lot easier. Still have to do data validation, > though, but > that's cool. Yes, validation is cool. Walden
I think "thinking it through" is a matter of making the 3229-introduced headers symmetric for requests and responses, which seems messy. Because of the problem of determining "Delta-Base" for deltas, the "pull" model seems cleaner overall, and suggests a solution in which "current version" information is all that gets pushed. Looks like event notification. Walden -----Original Message----- From: Mark Baker [mailto:distobj@...] Sent: Wednesday, August 21, 2002 9:21 PM To: Mark Baker Cc: S. Mike Dierken; rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] Re: PUT or POST Clarification On Wed, Aug 21, 2002 at 09:11:31PM -0400, Mark Baker wrote: > There would still be some issues with PUT, such as ensuring that the > message remains stateless. I think that specifying a target etag as > part request would help, but I haven't thought it through. Erm, with If-Match, of course. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca <http://www.markbaker.ca> http://www.idokorro.com <http://www.idokorro.com> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
http://www.sys-con.com/xml/article.cfm?id=454 -- Paul Prescod
> I think you're carrying the opaqueness of URI too far. As I understand, > URI should be opaque *to clients*, but are allowed to be (and should be > encouraged to be) meaningful for servers. Else you're constrained to > "bag" storage at the conceptual level, and that looks like your problem > at this point. Probably. I agree that the URI has to be at least mildly understood by the container. > You read me wrong. I said you objected to NOT being able to push > validation all the way out. Not knowing your application, it's not for > me to say, except that pushing ALL validation out to the container > leaves you what for an application? Well, the app still needs to do something intelligent. That's the servlet itself (or the implementation). The information would only get to the servlet if it passed all authorization and validation checks. I used the car example below to simplify the example. Our application deals with security and access control to resources (physical and virtual) so the question of "Can this person do this method to this thing" is essentially our application. In trying to apply REST to it, we're changing "do this method" to "PUT/GET/DELETE/POST". The car example below illustrates this. Suppose I can only drive the car to the repair center, while my sister can drive to the movies. I have to somehow ask the car, "Can I drive you to the movies" which it should then say no. So, question is: Am I sending the state of myself at the movies to the car? Am I sending the state of the car at the movies to the car? Would would I be PUTting and to what resource is where I'm getting all confused. I keep thinking the car knows whether or not I'm allowed at the movies, so I need to ask the car. Pretend all this talk of me, the car, and the movies each has a URI and are web enabled and very RESTful. :) > Curious as to what that means. To begin with, the car ought to know > where it's starting from, i.e., where it is now, no? Good point. Let's remove starting from in this example. Let's just use where I want to take it as an example (see movies example above). > In my most orthodox interpretation of Representational State Transfer, > I believe you can accomplish your trip by PUTting a version of your > car whose current location is the destination you seek. But we don't > really know what the purpose of Car is, so again we're kind of stuck > giving advice. I think you understand really well! I also think you're right... to get the car to the movies, I would PUT a version of the car at the movies, with me at the steering wheel. In the HTTP request, via HTTP Auth, the server knows who is asking the question, so the Who and the What are all known. This is cool. Now comes the interesting part. How do we secure this? We need to say: Seth can PUT this: PUT /car HTTP/1.0 <car> <at rdf:resource="http://example.com/movies"/> </car> But can't PUT this: PUT /car HTTP/1.0 <car> <at rdf:resource="http://example.com/liquorstore"/> </car> Basic web site security will govern if I can PUT to a resource or not, but doesn't talk about WHAT I'm PUTting. That's where this discussion stems from. I need to control certain states of resources, plus who is trying to put them into that state. To do this, I need to look at the RDF/XML and ask "Are all Statements correct for this person?" Phew! :) Thanks for helping me sort all this out, Seth
Mathews, Walden wrote: > I think, in your example, the car is irrelevant. Seth wants to put > himself at the movies, and that's not allowed. Movies is the resource, > Seth is the principal, PUT is the method, and NO is the answer, > presumably because Seth is in the wrong *role*, if we're talking servlet > authorization. That's an excellent point! If we split this into two questions: Can Seth Use Car? Can Seth Go To Movies? Then it's easier, because each resource (car, movies) controls their destiny. How would the car know whether or not I can go to the movies? > state), then the application has to decide, via its business rules, whether > he can drive to the movies. And I bet this is where distributed security models come in. If the whole system is wired together and very smart, the car could then pass the PUT request all the way to the movie theatre. If the movies said NO to Seth being there, the car could then say "Sorry, I'm not going to drive you there". BTW your thoughts are excellent understand not only the security model but REST in general. So now the question becomes: Seth hasParent Mother Mother grants Permission1 Permission1 allowsActor Seth Permission1 allowsMethod Enter Permission1 allowsActee Store Now, who does Mother tell this Permission1 to? We decided up above that the car doesn't know/care about that. In a real world, would Store allow Mother to PUT Permission1 there? Or would Store delegate those permission questions back to Mother? We can take this offline or drop this any time you want. It's getting fuzzy but I think the lessons learned are excellent ones. Thanks, Seth
Another angle on the above subjects: As Mark Baker wrote, an order is a contract. In formal contract situations, neither the buyer nor the seller may change the contract unilaterally. All changes to a bound contract must be accepted by both parties. So what they do in EDI is create Change Orders, which are documents defining either a changed contract in total, or just the requested changes to an existing contract. One party requests changes by issuing a Change Order, and the other party either accepts or rejects them or they may go into negotiation. So in this situation, I think a Change Order could be POSTed by one party to the original contract resource as a sub-resource, and if the other party accepts the changes, the contract resource would be changed, and also the Change Order and its acceptance would be retained as part of the audit trail of the contract. Takes care of both authorization for changes as well as deltas. I know, it seems like admitting an operation through the back door, but that's the way it's done when people want to be formal about it. Possibly overkill for many situations, but I'd be interested if anybody thinks it's unRESTful. (RESTless?) -Bob Haugen
I thought I had finally figured out the POST vs. PUT thing, then this last thread (PUT and POST clarification) comes along and everything gets fuzzy again. Here is what I understand (I think) so far: GET ------ Retrieves a resource (actually, a representation of a resource). Resource must exist. Action should/must be idempotent, meaning that the state of the resource should not change. PUT ------ Creates a resource. The client dictates the URL for the new resource. Newly created resource on the server should/must be identical to the resource sent via PUT when retrieved through GET. In other words, the returned representation must match the original contents of the PUT. If a client wants to create a new resource, but does not have the authority to dictate the resource's URL, then the client should use POST instead (see below). If the client wants to update a resource by replacing the entire resource, PUT may be used. Ootherwise, use POST (again, see below). POST ------ Edit/Update a resource. Resource must exist. However, this does not necessarily mean that a subsequent GET will return a different representation from a GET issued before the POST. POSTs may update a resource such that an existing URL will return a different representation via GET, or POST may cause the creation of a new resource. Likewise, it may be possible for a POST to effect only interal changes such that subsequent GETs return the same representation as before the POST. In the case where POST causes the creation of a new resource, the server will assign the new URL, not the client. Unlike PUT, if the server returns a URL for the new resource, there is no requirement for the new resource to return an identical representation that that which was POSTed in the first place. While POST will most often be used to update a resource or create a new resource, it is also possible to use POST as a "black box" method, where data is being sent to the server, but the client has no knowledge of whether anything was done with the data or not. Now, I know this is /possible/. However, with REST, is this /acceptable/? When I compare the HTTP verbs to SQL actions (HTTP POST => SQL UPDATE), I have trouble seeing the use of POST as a "black box" function. In other words, I have never encountered an example of using SQL UPDATE that did anything other than update exactly the table I told it to update (though, as a side effect, it may also update additional tables). In this comparison, it seems to me that either I have a gross missunderstanding of what POST is used for, or else POST is much more general-purpose that SQL UPDATE. DELETE ------ Deletes a resource. Resource must(?) exist. So, what do I have wrong? Are there any scenarios for these verbs (particularly PUT and POST) that I have not mentioned which are also possible within the REST model? --- Seairth Jacobs seairth@...
[This is not realy a response to Seairth - I already had most of this written when I saw Seairth's new thread, so instead of starting yet another thread, I'll just attach it to this one] In following some of the threads on PUT vs POST, I've become somewhat less comfortable with my understanding of the RESTful use of those two methods. All along, I've thought of the RESTful use of HTTP's GET/PUT/POST/DELETE as analogous to CRUD or SQL's SELECT/INSERT/UPDATE/DELETE - the mapping I had in my head was something like: HTTP CRUD SQL ---- ---- --- GET READ SELECT PUT CREATE INSERT POST UPDATE UPDATE DELETE DELETE DELETE While reading Paul's new article [1], I suddenly realized what part of my problem was. In his article, Paul makes that now standard comparison of HTTP's GET/PUT/POST/DELETE with SQL's SELECT/INSERT/UPDATE/DELETE. At some level, this is probably a reasonable comparison to make. Unfortunately, I think a lot of people people take that high level analogy and then try to do a one-to-one mapping between the methods of the two schemes - something that for me ended up being very misleading. As far as HTTP's GET and DELETE mapping to SQL's SELECT and DELETE - I don't see there being any problem. However, trying to do a one-to-one mapping of PUT to INSERT or POST to UPDATE doesnt work so well. PUT actually maps to either INSERT or UPDATE depending on whether the target resource already exists. POST maps to either INSERT or UPDATE depending on whether or not the resource you're POSTing to is a container (using Mark's model of HTTP resource state [2],[3]). So, realizing my mistake, I now have a model of RESTful use of HTTP methods that's something like this: GET - retrieve (a representation of) the resource's state PUT - directly set the resource's state POST - indirectly change the resource's state DELETE - delete the resource It seems to me, then, that the difference between PUT and POST is in part related to whether or not you are directly manipulating a resource's state. With PUT, you are directly setting the resource's state by explicitly providing a representation of the resource's (entire) new state. With POST, you can only indirectly change the resource's state by providing a representation of something that the resource will then use in a manner of its choosing to change its own state. In other words, you dont directly or explicitly specify the resource's new state - you just provide the resource with some information and it decides how to change its state based on that new information. I think this is more or less just a restatement of what Mark has said in [2] and [3]. I'm just suggesting that maybe some of us have trouble understanding the difference between PUT and POST because we've made too literal an association between HTTP's methods and the methods of SQL or CRUD. Yes, both HTTP and SQL can do CRUD. But, unlike SQL, HTTP's methods do not have a one-to-one mapping to CRUD's create, read, update and delete. --Chuck [1] http://www.sys-con.com/xml/article.cfm?id=454 [2] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model [3] http://www.markbaker.ca/2002/08/HowContainersWork/
This is all a question of modeling. If you can model your security
concerns in terms of principal, method and resource, then you can use
the existing security framework in servlet/HTTP. If Seth becomes
a resource instead of a principal, you're screwed. If what Seth wants
to do to the Store is something that needs more granularity than
{GET, PUT, POST, DELETE}, then you're screwed. "Screwed" in the
sense that you have to write an application. :-)
That sounds like a bottom line to me.
Walden
> -----Original Message-----
> From: Seth Ladd [mailto:seth@...]
> Sent: Thursday, August 22, 2002 11:50 AM
> To: rest-discuss
> Subject: Re: [rest-discuss] Security in a REST world?
>
>
> Mathews, Walden wrote:
> > I think, in your example, the car is irrelevant. Seth wants to put
> > himself at the movies, and that's not allowed. Movies is
> the resource,
> > Seth is the principal, PUT is the method, and NO is the answer,
> > presumably because Seth is in the wrong *role*, if we're
> talking servlet
> > authorization.
>
> That's an excellent point!
>
> If we split this into two questions:
>
> Can Seth Use Car?
> Can Seth Go To Movies?
>
> Then it's easier, because each resource (car, movies) controls their
> destiny. How would the car know whether or not I can go to
> the movies?
>
> > state), then the application has to decide, via its
> business rules, whether
> > he can drive to the movies.
>
> And I bet this is where distributed security models come in. If the
> whole system is wired together and very smart, the car could
> then pass
> the PUT request all the way to the movie theatre. If the
> movies said NO
> to Seth being there, the car could then say "Sorry, I'm not going to
> drive you there".
>
> BTW your thoughts are excellent understand not only the
> security model
> but REST in general.
>
> So now the question becomes:
>
> Seth hasParent Mother
> Mother grants Permission1
> Permission1 allowsActor Seth
> Permission1 allowsMethod Enter
> Permission1 allowsActee Store
>
> Now, who does Mother tell this Permission1 to? We decided up
> above that
> the car doesn't know/care about that. In a real world, would Store
> allow Mother to PUT Permission1 there? Or would Store delegate those
> permission questions back to Mother?
>
> We can take this offline or drop this any time you want.
> It's getting
> fuzzy but I think the lessons learned are excellent ones.
>
> Thanks,
> Seth
>
Seairth, Whenever I have questions like yours, I always consult RFC 2616. Here is an excerpt from section 9.6[1] regarding the PUT/POSt contrast: "The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource." To paraphrase, POST identifies the resource that will handle your request, and PUT identifies the resource itself. -Philip 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 -----Original Message----- From: Seairth Jacobs [mailto:seairth@...] Sent: Thursday, August 22, 2002 12:20 PM To: rest-discuss Subject: [rest-discuss] Just when I thought I had it... I thought I had finally figured out the POST vs. PUT thing, then this last thread (PUT and POST clarification) comes along and everything gets fuzzy again. Here is what I understand (I think) so far: [snip] ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
On Thu, Aug 22, 2002 at 01:09:28PM -0400, Chuck Hinson wrote: > So, realizing my mistake, I now have a model of RESTful use of HTTP > methods that's something like this: > > GET - retrieve (a representation of) the resource's state > PUT - directly set the resource's state > POST - indirectly change the resource's state > DELETE - delete the resource > > It seems to me, then, that the difference between PUT and POST is in > part related to whether or not you are directly manipulating a > resource's state. With PUT, you are directly setting the resource's > state by explicitly providing a representation of the resource's > (entire) new state. > > With POST, you can only indirectly change the resource's state by > providing a representation of something that the resource will then use > in a manner of its choosing to change its own state. In other words, > you dont directly or explicitly specify the resource's new state - you > just provide the resource with some information and it decides how to > change its state based on that new information. Bingo, exactly. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mathews, Walden wrote:
> This is all a question of modeling. If you can model your security
> concerns in terms of principal, method and resource, then you can use
> the existing security framework in servlet/HTTP. If Seth becomes
> a resource instead of a principal, you're screwed. If what Seth wants
> to do to the Store is something that needs more granularity than
> {GET, PUT, POST, DELETE}, then you're screwed. "Screwed" in the
> sense that you have to write an application. :-)
Hehe true, true. I actually like writing applications like this, so
it's a good time. :)
One last point about all of this that I would love your feedback on.
Let's take a simple example of opening a door (the door to the Store for
instance). To open a door, Seth would try to PUT the state of the door
as OPEN. The door would then say "Yup, seth can put me in an open state".
If the above it true, then the door has to do data validation based on
rules and permissions. For only certain people can change the state of
the door to open.
So a security policy would look a little like:
Allow Seth to change Door1's isOpen property to true.
Deny Bob to change Door1's isOpen property to true.
I am controlling access to an object's properties and its values.
That way, when I say:
PUT /door1 HTTP/1.0
WWW-Authentication: seth
<door id="Door1">
<isOpen>true</isOpen>
</door>
The authorization filter can easily check if this a valid state, not
only for the door, but if Seth can put that door into that state.
SELECT count(*) FROM security_policy
WHERE actor = 'seth' AND -- from WWW-Authentication
object = 'Door1' AND -- from id attr, or rdf:about attr
object_prop = 'isOpen' AND
prop_value = 'true'
All one has to do now is enumerate all properties of the object that is
being PUT (easy to do if RDF) and compare all against a security_policy
table which can be fast.
Are we there? Does this make sense?
feelin good,
Seth
In my (orthodox for the hell of it) view, resources have no meaning to the rest of the world beyond the state they can expose through representations. The gist of orthodox REST is this: describe changes through representations of end-state, not through named operations. Since you're limited to state-centric interaction, it follows that the word "subordinate" means precisely "subset of state", no more and no less. In particular, an operation or processing instruction cannot be subordinate to a resource defined solely in terms of state, any more than an apple can be subordinate to an orange. But that's the rule we seem to love to bend! One side-effect of describing change only in representations of post-state is that the client *has to know* the rules for getting there. Oh my, that works fine when you're building a document, but when you're trying to interact with the Oracle it doesn't work at all. What would software be without the magical transformations that result from the application of behind-the-scenes business logic? Am I making any sense at all? Walden -----Original Message----- From: bhaugen32 [mailto:bhaugen32@...] Sent: Thursday, August 22, 2002 11:48 AM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] PUT, POST, authorization and purchase orders Another angle on the above subjects: As Mark Baker wrote, an order is a contract. In formal contract situations, neither the buyer nor the seller may change the contract unilaterally. All changes to a bound contract must be accepted by both parties. So what they do in EDI is create Change Orders, which are documents defining either a changed contract in total, or just the requested changes to an existing contract. One party requests changes by issuing a Change Order, and the other party either accepts or rejects them or they may go into negotiation. So in this situation, I think a Change Order could be POSTed by one party to the original contract resource as a sub-resource, and if the other party accepts the changes, the contract resource would be changed, and also the Change Order and its acceptance would be retained as part of the audit trail of the contract. Takes care of both authorization for changes as well as deltas. I know, it seems like admitting an operation through the back door, but that's the way it's done when people want to be formal about it. Possibly overkill for many situations, but I'd be interested if anybody thinks it's unRESTful. (RESTless?) -Bob Haugen To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
Walden, I think your description totally makes sense. This is exactly how I think of resources and their subordinates. I see it in metaphysical terms. If you're more of a believer in the temporal philosophy of perdurance [than in endurance], the identity of a resource is seen as a perduring collection of its initial state (upon creation) and all subordinate states as parts that make up the whole. So in our case, resource can't be transferred themselves because only representations of it, or its parts, can be transferred between components. In our lingo, you have an intial PUT and subsequent PUTs and/or POSTs that give a resource its perduring "spatiotemporal" [sic] identity. Thanks, Philip -----Original Message----- From: Mathews, Walden [mailto:waldenm@...] Sent: Thursday, August 22, 2002 1:41 PM To: 'bhaugen32'; rest-discuss@yahoogroups.com Subject: RE: [rest-discuss] PUT, POST, authorization and purchase orders In my (orthodox for the hell of it) view, resources have no meaning to the rest of the world beyond the state they can expose through representations. The gist of orthodox REST is this: describe changes through representations of end-state, not through named operations. Since you're limited to state-centric interaction, it follows that the word "subordinate" means precisely "subset of state", no more and no less. In particular, an operation or processing instruction cannot be subordinate to a resource defined solely in terms of state, any more than an apple can be subordinate to an orange. But that's the rule we seem to love to bend! One side-effect of describing change only in representations of post-state is that the client *has to know* the rules for getting there. Oh my, that works fine when you're building a document, but when you're trying to interact with the Oracle it doesn't work at all. What would software be without the magical transformations that result from the application of behind-the-scenes business logic? Am I making any sense at all? Walden -----Original Message----- From: bhaugen32 [mailto:bhaugen32@...] Sent: Thursday, August 22, 2002 11:48 AM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] PUT, POST, authorization and purchase orders Another angle on the above subjects: As Mark Baker wrote, an order is a contract. In formal contract situations, neither the buyer nor the seller may change the contract unilaterally. All changes to a bound contract must be accepted by both parties. So what they do in EDI is create Change Orders, which are documents defining either a changed contract in total, or just the requested changes to an existing contract. One party requests changes by issuing a Change Order, and the other party either accepts or rejects them or they may go into negotiation. So in this situation, I think a Change Order could be POSTed by one party to the original contract resource as a sub-resource, and if the other party accepts the changes, the contract resource would be changed, and also the Change Order and its acceptance would be retained as part of the audit trail of the contract. Takes care of both authorization for changes as well as deltas. I know, it seems like admitting an operation through the back door, but that's the way it's done when people want to be formal about it. Possibly overkill for many situations, but I'd be interested if anybody thinks it's unRESTful. (RESTless?) -Bob Haugen To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . Yahoo! Groups Sponsor <http://rd.yahoo.com/M=229641.2166546.3626727.2204139/D=egroupweb/S=17057010 14:HM/A=1142330/R=0/*http://promo.yahoo.com/debtscape/> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
Hi On Thu 22-Aug-2002 at 12:19:43 -0400, Seairth Jacobs wrote: > > PUT > ------ > Creates a resource. The client dictates the URL for the new resource. > Newly created resource on the server should/must be identical to the > resource sent via PUT when retrieved through GET. In other words, the > returned representation must match the original contents of the PUT. What about using PUT to place a file that has some SSI that do things like write the last modified date and include a navigation bar -- it wouldn't be identical then? Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
I don't see any reason why you can't do what you've proposed below,
but at the same time, it's only for you to decide if you're "there",
and the reservation I have is leverage:
When they say "security policy", the mean policy, i.e., generalizations
about what makes things "secure". You're going away from policy and
into a sort of interpreter-based implementation where instead of general
rules you have a zillion specific ones. Do you have to?
If you can be more general about who can see or affect what, then
you can push more out to the servlet authorization mechanism. This
is, arguably, one of the powers of "generic methods". So, is Seth
allowed to open and close doors? (PUT/POST) Is he allowed to sense
the state of a door? (GET). Is he allowed to remodel the building?
(DELETE)
Thanks, this example has been fun and educational!
Walden
> -----Original Message-----
> From: Seth Ladd [mailto:seth@...]
> Sent: Thursday, August 22, 2002 1:44 PM
> Cc: rest-discuss
> Subject: Re: [rest-discuss] Security in a REST world?
>
>
> Mathews, Walden wrote:
> > This is all a question of modeling. If you can model your security
> > concerns in terms of principal, method and resource, then
> you can use
> > the existing security framework in servlet/HTTP. If Seth becomes
> > a resource instead of a principal, you're screwed. If what
> Seth wants
> > to do to the Store is something that needs more granularity than
> > {GET, PUT, POST, DELETE}, then you're screwed. "Screwed" in the
> > sense that you have to write an application. :-)
>
> Hehe true, true. I actually like writing applications like this, so
> it's a good time. :)
>
> One last point about all of this that I would love your feedback on.
>
> Let's take a simple example of opening a door (the door to
> the Store for
> instance). To open a door, Seth would try to PUT the state
> of the door
> as OPEN. The door would then say "Yup, seth can put me in an
> open state".
>
> If the above it true, then the door has to do data validation
> based on
> rules and permissions. For only certain people can change
> the state of
> the door to open.
>
> So a security policy would look a little like:
>
> Allow Seth to change Door1's isOpen property to true.
> Deny Bob to change Door1's isOpen property to true.
>
> I am controlling access to an object's properties and its values.
>
> That way, when I say:
>
> PUT /door1 HTTP/1.0
> WWW-Authentication: seth
>
> <door id="Door1">
> <isOpen>true</isOpen>
> </door>
>
> The authorization filter can easily check if this a valid state, not
> only for the door, but if Seth can put that door into that state.
>
> SELECT count(*) FROM security_policy
> WHERE actor = 'seth' AND -- from WWW-Authentication
> object = 'Door1' AND -- from id attr, or
> rdf:about attr
> object_prop = 'isOpen' AND
> prop_value = 'true'
>
> All one has to do now is enumerate all properties of the
> object that is
> being PUT (easy to do if RDF) and compare all against a
> security_policy
> table which can be fast.
>
> Are we there? Does this make sense?
>
> feelin good,
> Seth
>
I am beginning to think you use a POST in this case, except that it has to be to an existing resource (since you cannot POST to a URL that does not exist). The server should then return a URL to the newly created resource. --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Chris Croome" <chris@...> To: <rest-discuss@yahoogroups.com> Sent: Thursday, August 22, 2002 2:02 PM Subject: Re: [rest-discuss] Just when I thought I had it... > Hi > > On Thu 22-Aug-2002 at 12:19:43 -0400, Seairth Jacobs wrote: > > > > PUT > > ------ > > Creates a resource. The client dictates the URL for the new resource. > > Newly created resource on the server should/must be identical to the > > resource sent via PUT when retrieved through GET. In other words, the > > returned representation must match the original contents of the PUT. > > What about using PUT to place a file that has some SSI that do things > like write the last modified date and include a navigation bar -- it > wouldn't be identical then? > > Chris > > -- > Chris Croome <chris@...> > web design http://www.webarchitects.co.uk/ > web content management http://mkdoc.com/ > everything else http://chris.croome.net/ > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Walden, I'm not sure if you meant your reply as a comment on or correction to my message which you left attached. If so, I don't understand. But I will comment on some of your statements on their own. "Mathews, Walden" wrote: > In my (orthodox for the hell of it) view, resources > have no meaning to the rest of the > world beyond the state they can expose through representations. I thought that was what RDF was for. > The gist of orthodox REST is this: > describe changes through representations of end-state, > not through named operations. Agreed. > Since you're limited to state-centric interaction, > it follows that the word "subordinate" means precisely > "subset of state", no more and no less. Disagreed, depending on what you mean. See Mark's recent paper. If the resource is a container, then to post a subordinate is to request that the server create a new resource linked to the container. If the resource can act as a container (as an order to its audit trail), why wouldn't the same apply? > One side-effect of describing change only in representations > of post-state is that the client *has to know* the rules > for getting there. Make the rules into a related resource. -Bob Haugen
On Thu, Aug 22, 2002 at 07:36:54PM -0000, bhaugen32 wrote: > If the resource is a container, > then to post a subordinate is to request > that the server create a new resource > linked to the container. Actually, it doesn't. I should fix that in my note, as it isn't clear. Creating a new resource might be a side effect, but need not be. The POSTed data could just be processed, effect some state change, and then be discarded. This would correspond to a non-201 HTTP response. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > On Thu, Aug 22, 2002 at 07:36:54PM -0000, bhaugen32 wrote: > > If the resource is a container, > > then to post a subordinate is to request > > that the server create a new resource > > linked to the container. > > Actually, it doesn't. I should fix that in my note, as it isn't clear. > Creating a new resource might be a side effect, but need not be. The > POSTed data could just be processed, effect some state change, and then > be discarded. This would correspond to a non-201 HTTP response. The context was "the resource is a container". Ok, let me try again, because there is a lot of confusion on this point: *If* the resource is a container, then it is *allowed* to post a subordinate and request that the server create a new resource linked to the container. Or would you put it some other way? The reason I'm belaboring the point is that people read into these statements all kinds of things, and it would be possible to read into your statement that my assertion was incorrect, and you cannot POST a subordinate resource to a container and have the server create a new resource for you. And yes of course POST can have other effects as well. -Bob Haugen
On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote:
> The context was "the resource is a container".
Right. Not all containers create subordinate resources.
In my abstract model, and in RestRDF, I presented the following
hierarchy;
Resource
-> Container
-> StatePreservingContainer (ne IdentityPreservingContainer) (1)
-> Processor (2)
->
-> Replaceable
etc..
(1) is meant to describe containers who create a resource and return a
201
(2) is meant to describe containers who do not create a resource, but
instead just use the data to somehow do something, but do not hold
any state themselves.
I suppose it might be useful to add a class to the taxonomy that
represents non-state preserving, but state-holding resources, but I
didn't do that. But anyhow, the point being that "Container" is
very high up in the hierarchy, and therefore covers a whole lot of
varied functionality, including process-and-forget.
> Ok, let me try again, because there is a lot of confusion on this
> point:
> *If* the resource is a container,
> then it is *allowed* to post a subordinate
> and request that the server create a new resource
> linked to the container.
Nope, at least not with this definition of container. And FWIW, I think
it's pretty standard. It would be equivalent to a tuple space, or an
OpenDoc container, or a Java Beans Context, etc..
> Or would you put it some other way?
As above.
> The reason I'm belaboring the point is that people read into these
> statements all kinds of things, and it would be possible to read into
> your statement that my assertion was incorrect, and you cannot POST a
> subordinate resource to a container and have the server create a new
> resource for you.
Hmm, ok. I certainly don't mean that. I just mean that if you only
know the thing is a container, it may or may not create a resource for
you. If you know it's a StatePreservingContainer, then you know that
it will.
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
My thoughts: > In my abstract model, and in RestRDF, I presented the following > hierarchy; > > Resource > -> Container > -> StatePreservingContainer (ne IdentityPreservingContainer) (1) > -> Processor (2) > -> > -> Replaceable > etc.. > > (1) is meant to describe containers who create a resource and return a > 201 > > (2) is meant to describe containers who do not create a resource, but > instead just use the data to somehow do something, but do not hold > any state themselves. Personally, I would strongly suggest avoiding the use of RDF to describe the structure of a restful webservice. RDF is not expressive enough as real XML, nor is it meant to hold 'concrete' data that should be used in a real XML document. Further, there are really only two types of objects in REST. There are resources which expose the methods GET, PUT, DELETE, POST, (TRACE, and OPTIONS). Then there are 'collection' resources (a subclass of resource) which expose the aditional method 'FindById (String id)'. This object model can be derived from examining the nature of URLs. URLs are hiearchical and it's understood that when one 'part' (let's call it 'resource-id') of a url appears behind another part of a URL then the former is said to be contained by the latter. This is the thinking behind /purchase-orders/3242342342 <-- this URL should be understood to mean there is a resource '3242343342' within the resource 'purchase-orders'. - inthedarkplace
From: "inthedarkplace" <inthedarkplace@...> > > This object model can be derived from examining the nature of URLs. > URLs are hiearchical and it's understood that when one 'part' (let's > call it 'resource-id') of a url appears behind another part of a URL > then the former is said to be contained by the latter. This is the > thinking behind /purchase-orders/3242342342 <-- this URL should be > understood to mean there is a resource '3242343342' within the > resource 'purchase-orders'. As I understand it, this is absolutely wrong. Absolutely nothing should be assumed based on what is in the URI. It is just as valid to have the following two URLs where the first is a container of the second: /purchase-orders /3242342342 Only the server can apply meaning to the internal structure of a URI. The client cannot assume anything. Period. All it knows is that when it POSTed data to "/purchase-orders", it got back "/3242342342". You can then say that the first is a container of the second, but only because the server told that it was. (boy, if I am wrong about this, I am chuckin' the entire REST stuff and go join a monestary that's never heard of the stuff....) --- Seairth Jacobs seairth@...
Communication is so difficult....8( Mark Baker wrote: > On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote: > > The context was "the resource is a container". > > Right. Not all containers create subordinate resources. > > In my abstract model, and in RestRDF, I presented the following > hierarchy; > > Resource > -> Container > -> StatePreservingContainer (ne IdentityPreservingContainer) (1) > (1) is meant to describe containers who create a resource and return a 201 > > Ok, let me try again, because there is a lot of confusion on this > > point: > > *If* the resource is a container, > > then it is *allowed* to post a subordinate > > and request that the server create a new resource > > linked to the container. > > Nope, at least not with this definition of container. > And FWIW, I think it's pretty standard. > It would be equivalent to a tuple space, or an > OpenDoc container, or a Java Beans Context, etc.. > > > Or would you put it some other way? > > As above. Nope?!! I thought I said the same thing. What's the difference? Where am I wrong? I don't get it at all. > > The reason I'm belaboring the point is that people read into these > > statements all kinds of things, and it would be possible to read into > > your statement that my assertion was incorrect, and you cannot POST a > > subordinate resource to a container and have the server create a new > > resource for you. > > Hmm, ok. I certainly don't mean that. I just mean that if you only > know the thing is a container, it may or may not create a resource for > you. If you know it's a StatePreservingContainer, then you know that > it will. Ok, I'm gonna keep trying until I get this right. *If* the resource is a StatePreservingContainer, and if I post the proper request to create a subordinate resource, then the container will create a resource and return a 201. By the way, I've tried to repeat the same thing you wrote in slightly different words three times now and been told I was wrong by both you and Walden Mathews and still don't know what I'm doing wrong. I know this is possible, and you seem to agree it's possible, but there is obviously some sublety that I am missing. Also, the name StatePreservingContainer is not very clear, at least to me. Nor is IdentityPreservingContainer. But maybe that's because I'm still missing some subtlety. I think this is an important capability for meeting business requirements. I'm happy to revert to a hybrid of REST + SOAP, but am still trying to figure out how far I can go with pure REST. And I do need to know how to describe it so that it meets the business requirements and will not get shot down by the REST gang.
Bob,
First of all, I don't recall telling you you were wrong, and if I did, you should probably
attach no significant to that at all. Right now I'm experimenting with holding up an impossibly
strict interpretation of REST to see what happens to my understanding, with apologies
to all innocent bystanders.
On this issue of data-accepting resource types, Mark has created the taxonomy in order
to help us understand the range of possible responses w.r.t. resource creation and so
forth, but there can be no such thing as "knowing a resource is this type or that", because
the resource is free to handle POST as it sees fit. In other words, "IdentityPreservingResource"
may be what it's doing sometimes, but it's not a contract with you. At least that's the
understanding I've come away with.
I thought the only (minor) slip in your description of the POST where a sub-resource is
created is that you say the client can *request* creation (or expect creation). You can expect
whatever you want, but as I said there's no contract*. And you're not really requesting that
a resource be created. You're trusting the wizard (behind the resource curtain) to do the right
thing.
* I guess you could negotiate a contract like this, but what I meant is that it's not REST
or HTTP baseline stuff.
PS - thanks for trying to understand my esoteric ramblings, and yes, every bit does help.
Walden
----- Original Message -----
From: bhaugen32
To: rest-discuss@yahoogroups.com
Sent: Thursday, August 22, 2002 7:36 PM
Subject: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Communication is so difficult....8(
Mark Baker wrote:
> On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote:
> > The context was "the resource is a container".
>
> Right. Not all containers create subordinate resources.
>
> In my abstract model, and in RestRDF, I presented the following
> hierarchy;
>
> Resource
> -> Container
> -> StatePreservingContainer (ne IdentityPreservingContainer)
(1)
> (1) is meant to describe containers who create a resource and
return a 201
> > Ok, let me try again, because there is a lot of confusion on this
> > point:
> > *If* the resource is a container,
> > then it is *allowed* to post a subordinate
> > and request that the server create a new resource
> > linked to the container.
>
> Nope, at least not with this definition of container.
> And FWIW, I think it's pretty standard.
> It would be equivalent to a tuple space, or an
> OpenDoc container, or a Java Beans Context, etc..
>
> > Or would you put it some other way?
>
> As above.
Nope?!! I thought I said the same thing.
What's the difference? Where am I wrong?
I don't get it at all.
> > The reason I'm belaboring the point is that people read into
these
> > statements all kinds of things, and it would be possible to read
into
> > your statement that my assertion was incorrect, and you cannot
POST a
> > subordinate resource to a container and have the server create a
new
> > resource for you.
>
> Hmm, ok. I certainly don't mean that. I just mean that if you only
> know the thing is a container, it may or may not create a resource
for
> you. If you know it's a StatePreservingContainer, then you know
that
> it will.
Ok, I'm gonna keep trying until I get this right.
*If* the resource is a StatePreservingContainer,
and if I post the proper request to create a subordinate resource,
then the container will create a resource and return a 201.
By the way, I've tried to repeat the same thing you wrote in slightly
different words three times now and been told I was wrong by both you
and Walden Mathews and still don't know what I'm doing wrong.
I know this is possible, and you seem to agree it's possible, but
there is obviously some sublety that I am missing.
Also, the name StatePreservingContainer is not very clear, at least
to me. Nor is IdentityPreservingContainer. But maybe that's because
I'm still missing some subtlety.
I think this is an important capability for meeting business
requirements. I'm happy to revert to a hybrid of REST + SOAP, but am
still trying to figure out how far I can go with pure REST.
And I do need to know how to describe it so that it meets the
business requirements and will not get shot down by the REST gang.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Guys, I'm curious; has anybody established any best practices for performing arbitrary searching of collection resources? Eg, say I have the collection /users and I want to find a user with the username 'kd'. What's the most RESTful and elegant way to do this? It seems like there's basically three options. 1) Have the user POST an XML-document describing the query to the collection Pros: Logically intuitive. If I have a collection, I should ask it to execute queries. Cons: Because searching is not a mutator-method (ie it doesn't change the state of the users collection) it doesn't seem like POST is the best method. But neither do GET, PUT, or DELETE make much sense unless I do a GET with a body which I've been told is in poor taste. This also makes it very difficult to write the collection code because now the collection must parse the XML document, figure out which operation is happening (either user creation or searching) and then essentially reparse the algorithm. 2) Have the user do a GET on the users collection, passing the search query in through the query string. eg /users?username='xxx' Pros: Intuitive. This is what for the query string is for, I think. It also allows the user to bookmark searches which might be potentially very useful for working with sets of users. Cons: Severely limits the expressiveness of queries. Also puts more code in the users code, but this isn't a huge issue. 3) Create a special query resource located at /users/query. This query resource can have simply queries passed in through the query string or more complex queries passed in through a POST. Pros: This seems to the most elegant. It also makes sense because POSTing to a query resource can be seen as creating a query. Potentially, this query could even be assigned a URI. Because queries can be passed in through GET or POST it allows for arbitrarily expressive queries. Cons: Potentially, this could lead to resource explosion because every container resource now needs an additional 'query' resource. This might not be such a good thing. Right now I'm leaning more towards number 3. But I'm curious, what other solutions have people come up with? - inthedarkplace
----- Original Message ----- From: "Chuck Hinson" <cmhinson@...> > I had in my head was something like: > > HTTP CRUD SQL > ---- ---- --- > GET READ SELECT > PUT CREATE INSERT > POST UPDATE UPDATE > DELETE DELETE DELETE > I would use PUT=UPDATE/INSERT and POST=INSERT. The meaning of HTTP PUT is directly analagous to an 'upsert' in DB land. The reason POST is an INSERT is that it is not idempotent - if you call INSERT on your table 3 times, you get 3 records. If you call UPDATE on your table 3 times you get one very fresh record. I think there was a message quite a while ago on the comparison of CRUD & SQL with HTTP methods - can't find it right now...
Walden Mathews wrote: > First of all, I don't recall telling you you were wrong, and if I did, you should probably > attach no significant to that at all. Right now I'm experimenting with holding up an impossibly > strict interpretation of REST to see what happens to my understanding, with apologies > to all innocent bystanders. Don't mind me, I'm just flailing about trying to get unconfused. We're pretty much in the same boat, trying different ways to understand what seem to be powerful ideas that are a different from what (at least I'm) used to. > On this issue of data-accepting resource types, Mark has created the taxonomy in order > to help us understand the range of possible responses w.r.t. resource creation and so > forth, but there can be no such thing as "knowing a resource is this type or that", I thought that's what RDF was for. I also wonder if anybody has bent HTTP Header content-type in this direction? (Can't get to Mark's articles right now to see if he mentioned this possibility. I think I remember somebody doing so in a previous message in this list, but can't find that, either.) > because > the resource is free to handle POST as it sees fit. In other words, "IdentityPreservingResource" > may be what it's doing sometimes, but it's not a contract with you. At least that's the > understanding I've come away with. I want to be able to negotiate legally binding contracts electronically. I am sure it is possible to do that. It requires some kind of predictability of response. It might be predictability of the same type as Mark describes on ws- arch for getting reliable coordination without reliable messaging. > I thought the only (minor) slip in your description of the POST where a sub-resource is > created is that you say the client can *request* creation (or expect creation). You can expect > whatever you want, but as I said there's no contract*. And you're not really requesting that > a resource be created. You're trusting the wizard (behind the resource curtain) to do the right > thing. I want a contract. I don't need to start with a contract. I expect some kind of predictability to emerge from conversation. I think it will involve stereotyped conversational patterns. I think they can be described via RDF or XML. > * I guess you could negotiate a contract like this, but what I meant is that it's not REST > or HTTP baseline stuff. I expect it will require something like an RDF contract for conversational behavior, which could also be a REST resource. > PS - thanks for trying to understand my esoteric ramblings, and yes, every bit does help. I appreciate your ramblings because I sense that you are another person who is honestly trying to get it. If we can help each other, I'm happy. If we just confuse each other more, well, par for the course I guess, and we'll get over it. -Bob
S. Mike Dierken wrote:
>----- Original Message -----
>From: "Chuck Hinson" <cmhinson@...>
>
>>I had in my head was something like:
>>
>> HTTP CRUD SQL
>> ---- ---- ---
>> GET READ SELECT
>> PUT CREATE INSERT
>> POST UPDATE UPDATE
>> DELETE DELETE DELETE
>>
>
>I would use PUT=UPDATE/INSERT and POST=INSERT. The meaning of HTTP PUT is
>directly analagous to an 'upsert' in DB land.
>The reason POST is an INSERT is that it is not idempotent - if you call
>INSERT on your table 3 times, you get 3 records. If you call UPDATE on your
>table 3 times you get one very fresh record.
>
But POST doesn't always mean insert (where insert mean create new
resource). A POST to a resource R can have one of three general results
(ignoring errors):
1. the creation of a new resource S
2. a modification to R's state resulting in R'
3. no change in R's state
--Chuck
Okay, a few threads back, I asked what was the preferred way to handle
sessions. The most popular response was "http authentication". Since I am
working on this project in PHP, I asked php.net's newsgroups where I might
find code for digest authentication (basic authentication is easy enough).
What I got back was that PHP currently does not support digest
authentication (though I would have thought I could code around that
problem). And to make things worse, it seems not a lot of browsers support
digest authentication in a compatible manner. For instance, I came across
one article that says:
Opera and Amaya both support Apache's version of digest authentication
IE5+ both support IIS's version of digest authentication
Opera and Amays do not work with IIS and IE does not work with Apache
Now, this may have changed with IE6, but I have not been able to find
anything to substanciate that.
So, this leaves me with using basic authentication. However, I am not crazy
about using it for two reasons:
1) Repeatedly sending login information over the wire in plaintext. Now, I
realize that I could use SSL, but that would be both expensive and slow the
site down.
2) I don't see a way to "expire" the login information. But maybe there is
a method that I am just not aware of...
So, this brings me to session cookies. Some time back, I recall reading the
statement that "cookies are not RESTful". Now, is this all use of cookies
or just persistant cookies? Is it okay to use a single session cookie? I
would see this as no different from using http authentication (i.e. the
client resending identifying [set of] values over and over again), except
that I can occasionally change the cookie's value to limit replay attacks
and limit the possibility of stealing the password to only one request
instead of every request (assuming basic authentication).
There is one other thing I do like about http authentication: it doesn't
"interfere" with the application process. In other words, the browser just
resubmits the last request with additional headers. To implement html login
forms and cookies, I have to take on the responsibility of keeping track of
the submitted data in the last request. It also means that the browser
caches the login page in it's history (which does not happen with http
authentication).
So, how do you deal with the security issues of http authentication vs. html
form/cookie authentication when you are running over a unsecure conneciton?
And how do you do this and keep it all RESTful?
---
Seairth Jacobs
seairth@...
I have to run, but ...
On Thu, Aug 22, 2002 at 09:52:26PM -0400, Walden Mathews wrote:
> In other words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with you. At least that's the
> understanding I've come away with.
My intent was that exposing a type be equivalent to publishing an intent
to enter into a contract. So you could imagine a hierarchy such as;
Container
StatePreservingContainer
Archiver
EternityArchiver
and if you expose that type, and I give you my data (with POST), I
expect that you will keep it for eternity ... as described by the RDF
you get when you GET the type URI (plus info that relates it to its
parent, so that if you're only looking for an Archiver and don't care
what kind, you can use EternityArchivers.
> * I guess you could negotiate a contract like this, but what I meant is that it's not REST
> or HTTP baseline stuff.
Sure, it's not baseline. But it seems like the only way forward for
laying out a coherrent framework for fitting RDF into REST. At least
that's how I see it.
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
Don't know why I didn't think of this before. Tomcat uses a URL based API for managing web applications. It's documented here: <http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html>. You send it URLs, it returns text/plain responses (essentially, 'ok' and 'fail'). Also it's maybe a live example of a resource with nested resources (the Tomcat model is an uber application which manages nested applications, which manage nested servlets/jsps/images... you get the idea). The thing is, it uses GET to alter|deploy|start|stop applications in its container; ie it has GETs with side effects. Which doesn't seem very RESTful. Thoughts? regards, Bill de hra
Bob,
There are contracts, and there are contracts. I recognize that you are
interested
in a business-level contract, i.e., "contract as REST resource". When I
said there was
no contract, I meant at the application protocol level inside POST. In
other words, you
might compose hypertext entity C and POST it to some business resource as a
contract
work in progress, and that resource may
a. declare itself on vacation and do nothing with your submittal except
to
notify you that no action is being taken
b. take your contract proposal and publish it as a resource to be
modified
collaboratively until both sides are ready to sign it.
The contract I assert does not exist is the contract to recognize another
contract
and host it. And in business, this is also the case, is it not?
By the way, I think the problem here is one of HTTP, not REST. REST says
there
are generic methods, i.e, methods that conceivably apply to all resources.
HTTP says
there is a POST method, and then makes some statements for us to interpret.
If REST, by calling for generic methods, implies in the meaning of
'generic'
that method semantics are clearly defined and understood, then the POST
method of HTTP may violate REST a little. The generality of POST is so
great
that the semantic visibility of POST requests to intermediaries is
highly
questionable, and hence the desired "induced" architectural property is
partly
missing. Another way of saying this is that POST is a built-in tunnel
for doing RPC over HTTP. The exception being that you really shouldn't
use it for data retrieval (GET).
If you want explicit, reliable sub-resource creation through the protocol,
you can
define a method with those semantics, and that would violate neither REST
nor
HTTP as far as I know. Heck, what's to stop you from extending HTTP methods
with the set from SQL? Then you know precisely what INSERT means.
What do you think?
Walden
-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Friday, August 23, 2002 7:49 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Walden Mathews wrote:
> First of all, I don't recall telling you you were wrong, and if I
did, you should probably
> attach no significant to that at all. Right now I'm experimenting
with holding up an impossibly
> strict interpretation of REST to see what happens to my
understanding, with apologies
> to all innocent bystanders.
Don't mind me, I'm just flailing about trying to get unconfused.
We're pretty much in the same boat, trying different ways to
understand what seem to be powerful ideas that are a different from
what (at least I'm) used to.
> On this issue of data-accepting resource types, Mark has created
the taxonomy in order
> to help us understand the range of possible responses w.r.t.
resource creation and so
> forth, but there can be no such thing as "knowing a resource is
this type or that",
I thought that's what RDF was for.
I also wonder if anybody has bent HTTP Header content-type in this
direction? (Can't get to Mark's articles right now to see if he
mentioned this possibility. I think I remember somebody doing so in a
previous message in this list, but can't find that, either.)
> because
> the resource is free to handle POST as it sees fit. In other
words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with
you. At least that's the
> understanding I've come away with.
I want to be able to negotiate legally binding contracts
electronically. I am sure it is possible to do that.
It requires some kind of predictability of response.
It might be predictability of the same type as Mark describes on ws-
arch for getting reliable coordination without reliable messaging.
> I thought the only (minor) slip in your description of the POST
where a sub-resource is
> created is that you say the client can *request* creation (or
expect creation). You can expect
> whatever you want, but as I said there's no contract*. And you're
not really requesting that
> a resource be created. You're trusting the wizard (behind the
resource curtain) to do the right
> thing.
I want a contract. I don't need to start with a contract.
I expect some kind of predictability to emerge from conversation.
I think it will involve stereotyped conversational patterns.
I think they can be described via RDF or XML.
> * I guess you could negotiate a contract like this, but what I
meant is that it's not REST
> or HTTP baseline stuff.
I expect it will require something like an RDF contract for
conversational behavior, which could also be a REST resource.
> PS - thanks for trying to understand my esoteric ramblings, and
yes, every bit does help.
I appreciate your ramblings because I sense that you are another
person who is honestly trying to get it. If we can help each other,
I'm happy. If we just confuse each other more, well, par for the
course I guess, and we'll get over it.
-Bob
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=232673.2253070.3709326.1774049/D=egroupweb/S=17057010
14:HM/A=1194123/R=0/*http://www.adinsdirect.com/>
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
-----Original Message----- From: Mathews, Walden [mailto:waldenm@...] I hope it at least sets responses to non-cacheable! >> It doesn't. I'm using the back button now and hitting refresh to redeploy an application. You do have to login at the get go. regards, Bill de hra
> From: Mathews, Walden [mailto:waldenm@...] > > So then what happens the second time you access a resource like > > GET /manager/refresh?my_app ? > > Does the browser satisfy the request from its cache, meaning > that the "refresh" command never reaches the server? Yes I think so (I don't know how to view traffic on this box); you go back and actively refresh to resubmit. On the hand, I'd need to look at the manager servlet to see what it's really doing up there... regards Bill de hra
The root of all evil here is the fact that *operations* are also first class
abstractions,
every bit as first class as *resource state*, except in REST (and for well
understood
reasons there).
So how do you evaluate the tradeoff between using RDF as part of resource
state
to extend the semantics of 'generic' methods? As opposed to extending the
defined set of
methods for the sake of greater method specificity? As opposed to adding
'control' data
(mentioned in the thesis, but not in association with HTTP) to qualify
methods? As
opposed to any other meta-method for working around generic method
limitations?
Walden
-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Friday, August 23, 2002 10:36 AM
To: Walden Mathews
Cc: bhaugen32; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
I have to run, but ...
On Thu, Aug 22, 2002 at 09:52:26PM -0400, Walden Mathews wrote:
> In other words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with you. At
least that's the
> understanding I've come away with.
My intent was that exposing a type be equivalent to publishing an intent
to enter into a contract. So you could imagine a hierarchy such as;
Container
StatePreservingContainer
Archiver
EternityArchiver
and if you expose that type, and I give you my data (with POST), I
expect that you will keep it for eternity ... as described by the RDF
you get when you GET the type URI (plus info that relates it to its
parent, so that if you're only looking for an Archiver and don't care
what kind, you can use EternityArchivers.
> * I guess you could negotiate a contract like this, but what I meant is
that it's not REST
> or HTTP baseline stuff.
Sure, it's not baseline. But it seems like the only way forward for
laying out a coherrent framework for fitting RDF into REST. At least
that's how I see it.
MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com>
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=228862.2128520.3581629.2204139/D=egroupweb/S=17057010
14:HM/A=1182711/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-336>
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
"Mathews, Walden" wrote: > There are contracts, and there are contracts. > I recognize that you are interested > in a business-level contract, i.e., "contract as REST resource". > > When I said there was no contract, > I meant at the application protocol level inside POST. Yeah, I understood. I am interested in contracts in both senses, business and protocol, and they are related. Can't have real legally binding electronic business contracts without protocol contracts. I know it's not base HTTP POST, but I thought that was the direction Mark was going with RDF. Now, I'm not gonna make the mistake of saying any more about what I think Mark means, since I'm still not sure what I did wrong the last time. But what I mean is that I think it is possible to define a business protocol contract with either RDF or XML or something else computable and have it govern conversations about business contracts as resources. Working on a variety of ways to do it. More to come when I think I got something real. > In other words, you might compose hypertext entity C > and POST it to some business resource as a contract > work in progress, and that resource may > > a. declare itself on vacation and do nothing > with your submittal except to > notify you that no action is being taken ...except that I'm gonna put a time constraint on my contract proposal. If no action when due, the proposal is void. > b. take your contract proposal and publish it > as a resource to be modified collaboratively > until both sides are ready to sign it. > > The contract I assert does not exist is the contract > to recognize another contract and host it. We've discussed two models: 1. one resource, which one party hosts, and 2. two resources, which must be kept in sync. (In real life, there will always be two copies, but in the first model, only one has a URI.) > And in business, this is also the case, is it not? The contract for negotiating contracts must be negotiated first. Fortunately, such things are being developed by standards orgs. Unfortunately, none are RESTful (so far). But after having worked on some of the non-RESTful approaches, I think the REST principle that everything important be a resource with its own URI would solve a lot of currently unsolved problems. (That's why I'm here, by the way.) Can REST can solve all the conversational protocol problems? Don't know for sure. I think so. Can't prove it yet. P.S. In case it wasn't clear, when I wrote that it is possible to have POST create sub-resource, * I didn't mean that POST cannot also be used in other ways, and * I meant that a "sub-resource" or "subordinate resource" is a real resource with its own URI, just hyperlinked to its container.
[ Bob Haugen wrote:] > Can't have real legally binding electronic > business contracts without protocol contracts. > I know it's not base HTTP POST, but I thought > that was the direction Mark was going with RDF. And you can't have protocol contracts without lower level protocol contracts, and so on and so on? I don't believe this is true. There is such a thing as bootstrapping commitment, and I believe it's the norm rather than the exception. Every time you communicate with someone, there's the possibility that they will not even understand you, let alone enter into a contract with you, but when the latter happens mutually, you can recognize it an build upon it. So just because HTTP or REST doesn't guarantee the creation semantics you want from POST does not mean you can't still negotiate through that method to the desired contract state. I see a parallel between this subject and the subject of 'reliable messaging' as the substrate for reliable applications. Do you see my analogy clearly, or should I elaborate? Walden
"Mathews, Walden" wrote: > There is such a thing as bootstrapping commitment, > and I believe it's the norm rather than the exception. I'm not communicating well. That's exactly what I have in mind, except that I think some seeds will be useful (beyond raw POST). > Every time you communicate with someone, there's the possibility > that they will not even understand you, let alone enter into a contract > with you, but when the latter happens mutually, you can recognize > it an build upon it. > > So just because HTTP or REST doesn't guarantee the creation semantics > you want from POST does not mean you can't still negotiate through > that method to the desired contract state. Sure, no disagreement. But business relationships tend to be repetitive. Once I negotiate a protocol with you, we can start with the previous protocol either as something to use or something to tweak, instead of pretending we never met. And if somebody else has defined a conversational pattern that we can reference, that might help, too. And whether we capture our previously negotiated pattern or use somebody else's, it needs to be represented in some form. You can see how difficult communication between humans can be, when we were evolved to be good at it. I think our computers will need all the help they can get. > I see a parallel between this subject and the subject of 'reliable > messaging' > as the substrate for reliable applications. Do you see my analogy > clearly, or should I elaborate? Yes I think there is a parallel, but please do elaborate, because assumptions aren't working very well in this arena.
Seairth, Personally, I've never heard of different versions of digest authentication between the browsers. Plus I don't really see how PHP can not support digest authentication. Digest authentication just involves parsing the 'Authorization' header and generating the 'WWW- Authenticate' header. I'd suggest you look at: http://www.rassoc.com/gregr/weblog/stories/2002/07/09/webServicesSecur ityHttpDigestAuthenticationWithoutActiveDirectory.html That is a 'native' implementation of digest authentication. It doesn't matter on the browser or container. - inthedarkplace --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote: > Okay, a few threads back, I asked what was the preferred way to handle > sessions. The most popular response was "http authentication". Since I am > working on this project in PHP, I asked php.net's newsgroups where I might > find code for digest authentication (basic authentication is easy enough). > What I got back was that PHP currently does not support digest > authentication (though I would have thought I could code around that > problem). And to make things worse, it seems not a lot of browsers support > digest authentication in a compatible manner. For instance, I came across > one article that says: > > Opera and Amaya both support Apache's version of digest authentication > IE5+ both support IIS's version of digest authentication > Opera and Amays do not work with IIS and IE does not work with Apache > > Now, this may have changed with IE6, but I have not been able to find > anything to substanciate that. > > So, this leaves me with using basic authentication. However, I am not crazy > about using it for two reasons: > > 1) Repeatedly sending login information over the wire in plaintext. Now, I > realize that I could use SSL, but that would be both expensive and slow the > site down. > > 2) I don't see a way to "expire" the login information. But maybe there is > a method that I am just not aware of... > > > > So, this brings me to session cookies. Some time back, I recall reading the > statement that "cookies are not RESTful". Now, is this all use of cookies > or just persistant cookies? Is it okay to use a single session cookie? I > would see this as no different from using http authentication (i.e. the > client resending identifying [set of] values over and over again), except > that I can occasionally change the cookie's value to limit replay attacks > and limit the possibility of stealing the password to only one request > instead of every request (assuming basic authentication). > > > There is one other thing I do like about http authentication: it doesn't > "interfere" with the application process. In other words, the browser just > resubmits the last request with additional headers. To implement html login > forms and cookies, I have to take on the responsibility of keeping track of > the submitted data in the last request. It also means that the browser > caches the login page in it's history (which does not happen with http > authentication). > > > So, how do you deal with the security issues of http authentication vs. html > form/cookie authentication when you are running over a unsecure conneciton? > And how do you do this and keep it all RESTful? > > --- > Seairth Jacobs > seairth@s...
> > PUT should never insert, it really only means UPDATE. Sorry, but that is not the way the HTTP specification works. It RDBMS/SQL terms it means "UPSERT". -- http://www.ietf.org/rfc/rfc2616.txt -- 9.6 PUT The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem.
First, thanks for the link. That certainly makes it more clear how it works. The RFC is a bit "dry". :) Second, here is the article I encountered: http://www.eweek.com/print_article/0,3668,a%3D24177,00.asp --- Seairth Jacobs seairth@... ----- Original Message ----- From: "inthedarkplace" <inthedarkplace@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, August 23, 2002 12:49 PM Subject: [rest-discuss] Re: session stuff (again) > Seairth, > > Personally, I've never heard of different versions of digest > authentication between the browsers. Plus I don't really see how PHP > can not support digest authentication. Digest authentication just > involves parsing the 'Authorization' header and generating the 'WWW- > Authenticate' header. > > I'd suggest you look at: > http://www.rassoc.com/gregr/weblog/stories/2002/07/09/webServicesSecur > ityHttpDigestAuthenticationWithoutActiveDirectory.html > > That is a 'native' implementation of digest authentication. It > doesn't matter on the browser or container. > > - inthedarkplace > > --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote: > > Okay, a few threads back, I asked what was the preferred way to > handle > > sessions. The most popular response was "http authentication". > Since I am > > working on this project in PHP, I asked php.net's newsgroups where > I might > > find code for digest authentication (basic authentication is easy > enough). > > What I got back was that PHP currently does not support digest > > authentication (though I would have thought I could code around that > > problem). And to make things worse, it seems not a lot of browsers > support > > digest authentication in a compatible manner. For instance, I came > across > > one article that says: > > > > Opera and Amaya both support Apache's version of digest > authentication > > IE5+ both support IIS's version of digest authentication > > Opera and Amays do not work with IIS and IE does not work with > Apache > > > > Now, this may have changed with IE6, but I have not been able to > find > > anything to substanciate that. > > > > So, this leaves me with using basic authentication. However, I am > not crazy > > about using it for two reasons: > > > > 1) Repeatedly sending login information over the wire in > plaintext. Now, I > > realize that I could use SSL, but that would be both expensive and > slow the > > site down. > > > > 2) I don't see a way to "expire" the login information. But maybe > there is > > a method that I am just not aware of... > > > > > > > > So, this brings me to session cookies. Some time back, I recall > reading the > > statement that "cookies are not RESTful". Now, is this all use of > cookies > > or just persistant cookies? Is it okay to use a single session > cookie? I > > would see this as no different from using http authentication (i.e. > the > > client resending identifying [set of] values over and over again), > except > > that I can occasionally change the cookie's value to limit replay > attacks > > and limit the possibility of stealing the password to only one > request > > instead of every request (assuming basic authentication). > > > > > > There is one other thing I do like about http authentication: it > doesn't > > "interfere" with the application process. In other words, the > browser just > > resubmits the last request with additional headers. To implement > html login > > forms and cookies, I have to take on the responsibility of keeping > track of > > the submitted data in the last request. It also means that the > browser > > caches the login page in it's history (which does not happen with > http > > authentication). > > > > > > So, how do you deal with the security issues of http authentication > vs. html > > form/cookie authentication when you are running over a unsecure > conneciton? > > And how do you do this and keep it all RESTful? > > > > --- > > Seairth Jacobs > > seairth@s... > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Mike, Oops, it looks like you're totally right, PUT can be used for resource creation. Thanks for pointing that out. - inthedarkplace --- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > > > > > PUT should never insert, it really only means UPDATE. > Sorry, but that is not the way the HTTP specification works. > It RDBMS/SQL terms it means "UPSERT". > > -- http://www.ietf.org/rfc/rfc2616.txt -- > 9.6 PUT > > The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already > existing resource, the enclosed entity SHOULD be considered as a > modified version of the one residing on the origin server. If the > Request-URI does not point to an existing resource, and that URI is > capable of being defined as a new resource by the requesting user > agent, the origin server can create the resource with that URI. If a > new resource is created, the origin server MUST inform the user agent > via the 201 (Created) response. If an existing resource is modified, > either the 200 (OK) or 204 (No Content) response codes SHOULD be sent > to indicate successful completion of the request. If the resource > could not be created or modified with the Request-URI, an appropriate > error response SHOULD be given that reflects the nature of the > problem.
On Thu, Aug 22, 2002 at 11:36:11PM -0000, bhaugen32 wrote: > Communication is so difficult....8( So I hear. 8-) > return a 201 > > > > Ok, let me try again, because there is a lot of confusion on this > > > point: > > > *If* the resource is a container, > > > then it is *allowed* to post a subordinate > > > and request that the server create a new resource > > > linked to the container. > > > > Nope, at least not with this definition of container. > > And FWIW, I think it's pretty standard. > > It would be equivalent to a tuple space, or an > > OpenDoc container, or a Java Beans Context, etc.. > > > > > Or would you put it some other way? > > > > As above. > > Nope?!! I thought I said the same thing. > What's the difference? Where am I wrong? > I don't get it at all. It's your use of the word "request". The client can't request it. It just sends the data, and it's up to the container to do it, or not. I suppose you could consider the use of SOAPAction with a URI identifying the expected type (in this case, a StatePreservingContainer), a "request". But I didn't get the impression that that's what you were suggesting. If so, then you were right. > Ok, I'm gonna keep trying until I get this right. > > *If* the resource is a StatePreservingContainer, > and if I post the proper request to create a subordinate resource, > then the container will create a resource and return a 201. Modulo the "request" issue, yes. > By the way, I've tried to repeat the same thing you wrote in slightly > different words three times now and been told I was wrong by both you > and Walden Mathews and still don't know what I'm doing wrong. > I know this is possible, and you seem to agree it's possible, but > there is obviously some sublety that I am missing. > > Also, the name StatePreservingContainer is not very clear, at least > to me. Nor is IdentityPreservingContainer. But maybe that's because > I'm still missing some subtlety. No, it could be the name. If you've got any suggestions after this, I'm all ears. > I think this is an important capability for meeting business > requirements. I'm happy to revert to a hybrid of REST + SOAP, but am > still trying to figure out how far I can go with pure REST. > And I do need to know how to describe it so that it meets the > business requirements and will not get shot down by the REST gang. SOAP's still purely optional. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
*sigh* Do you ever have the feeling that the solutions set before you are
all not-quite-good-enough, each in their own way? Currently, this is how I
am feeling about session management when it comes to REST...
Known options:
1) HTTP Authentication: This is a simple, non-intrusive solution. However,
"basic" is insecure and "digest" is not consistently implemented.
2) Generating your own "session id". This has the problem that you must
provide an "intrusive" login screen/process. Further, you then need to
continue tracking the session id. With this, there are two techniques
(well, three sorta):
a) Session Cookie: If done properly, this is effectively no different
than http authentication in the sense that the browser is sending an
"authenticating" identifier with each request. Session cookies are somewhat
nicer than http authentication in that they are potentially more secure (if
done correctly) and that it is easier for the server to handle them (e.g.
deleting them, updating them, etc.). The major down side is that current
browsers allow the users to reject session cookies.
b) Query String: This one, from a REST POV, seems like a really bad
technique. This effectively creates non-permanent unique URL spaces for
each user session. Further, the session id may not actually be related to
the resource that the URL (with the query string) is pointing to. However,
the good thing about query strings is that, short of a user typing an
address into the browser or using a stored link, the server has control over
them and the user does not have the ability to reject them.
c) Hidden Field: if you are not using the QueryString method and are
have a form, you could put the session id in a hidden field. However, you
are then limited to using only the POST method. Otherwise, the browser will
generate a URL with your hidden field showing up in a QueryString. But, if
the request is guaranteed to be idempotent, then it is my understanding that
the GET method should be used, not POST.
Now, I know that all of the above methods (with the possible exception of
digest authentication, if done correctly and at a certain cost) still allows
someone to sniff the connection and get enough information to potentially
mimic the session. This could all be taken care of using SSL (at which
point, even basic authentication is secure), but that seems to be adding a
lot of overhead. When I only need to authenticate the request, not secure
the response, this seems like overkill (and it can be expensive too).
Frankly, I think I am leaning towards session cookies at this point. Since
the site will primarily be for web developers, I am hoping that they at
least accept session cookies. I would have liked to go the HTTP
authentication route, but it just seems to unsecure for my taste
(considering the fact that I am not using SSL). If anyone out there can
convince my why I should not follow this route, esp. as far as REST is
concerned, please say so. I really would like to be convinced of another
method.
IN THE MEANTIME....
I have been thinking of this dilemma (the one above). And I have an idea.
I am wondering whether the idea would work well with the REST model or not.
If it would, I would like to get a group of people together to formalize it
and get it submitted to the right people.
What I propose is that web browsers should support a new HTTP header called
"session-id". This header would conform to the following rules:
1) The header works sort of like a session cookie. When the header is sent
to the browser, you can specify the domain and path (http authentication
realm?) and an expiration timestamp. The timestamp only ensures that the
header will stop being sent back to the server if the browser is not closed
by that point. Just like current cookies, setting the timestamp to the past
will cause the session-id header to become immediately stale.
2) THE USER MAY NOT REJECT THE HEADER. Browsers that allow optional
rejection will be considered NON-STANDARDS-COMPLIANT. Proxies SHOULD NOT
REJECT THE HEADER. I would prefer to make this MAY NOT, but I doubt it
would stick. What are proxies allowed to do with the www-authenticate
header?
3) the www-authenticate and session-id headers are mutually exclusive. In
other words, if a browser receives a session-id header which matches the
existing realm, the browser dumps the www-authenticate response and uses
session-id instead. This allows the http authentication methods to still be
used, but also allows the request headers to be replaced with something that
is more controllable by the server.
Though I know that more thought needs to be put into the idea, I feel it
would provide the consistency of basic authentication, the flexibility and
overhead of cookies, and the security of digest authentication. Note that
it is not even necessary to use HTML forms, since http authentication could
be used as the first step then replaced as in #3 above. However, if one
*really* wants the nice look, they could do that as well.
So, what do you all think? Would this interfere with the REST model?
---
Seairth Jacobs
seairth@...
This may be helpful: "There is no session" and "You'll come to realize, as I did, that there's a difference between knowing the resource and representing the resource." (with apologies) ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Sunday, August 25, 2002 7:46 PM Subject: [rest-discuss] Beating my head against the "session management" wall > *sigh* Do you ever have the feeling that the solutions set before you are > all not-quite-good-enough, each in their own way? Currently, this is how I > am feeling about session management when it comes to REST... > > Known options: > > 1) HTTP Authentication: This is a simple, non-intrusive solution. However, > "basic" is insecure and "digest" is not consistently implemented. > > 2) Generating your own "session id". This has the problem that you must > provide an "intrusive" login screen/process. Further, you then need to > continue tracking the session id. With this, there are two techniques > (well, three sorta): > > a) Session Cookie: If done properly, this is effectively no different > than http authentication in the sense that the browser is sending an > "authenticating" identifier with each request. Session cookies are somewhat > nicer than http authentication in that they are potentially more secure (if > done correctly) and that it is easier for the server to handle them (e.g. > deleting them, updating them, etc.). The major down side is that current > browsers allow the users to reject session cookies. > > b) Query String: This one, from a REST POV, seems like a really bad > technique. This effectively creates non-permanent unique URL spaces for > each user session. Further, the session id may not actually be related to > the resource that the URL (with the query string) is pointing to. However, > the good thing about query strings is that, short of a user typing an > address into the browser or using a stored link, the server has control over > them and the user does not have the ability to reject them. > > c) Hidden Field: if you are not using the QueryString method and are > have a form, you could put the session id in a hidden field. However, you > are then limited to using only the POST method. Otherwise, the browser will > generate a URL with your hidden field showing up in a QueryString. But, if > the request is guaranteed to be idempotent, then it is my understanding that > the GET method should be used, not POST. > > > Now, I know that all of the above methods (with the possible exception of > digest authentication, if done correctly and at a certain cost) still allows > someone to sniff the connection and get enough information to potentially > mimic the session. This could all be taken care of using SSL (at which > point, even basic authentication is secure), but that seems to be adding a > lot of overhead. When I only need to authenticate the request, not secure > the response, this seems like overkill (and it can be expensive too). > > > > Frankly, I think I am leaning towards session cookies at this point. Since > the site will primarily be for web developers, I am hoping that they at > least accept session cookies. I would have liked to go the HTTP > authentication route, but it just seems to unsecure for my taste > (considering the fact that I am not using SSL). If anyone out there can > convince my why I should not follow this route, esp. as far as REST is > concerned, please say so. I really would like to be convinced of another > method. > > > IN THE MEANTIME.... > > I have been thinking of this dilemma (the one above). And I have an idea. > I am wondering whether the idea would work well with the REST model or not. > If it would, I would like to get a group of people together to formalize it > and get it submitted to the right people. > > What I propose is that web browsers should support a new HTTP header called > "session-id". This header would conform to the following rules: > > 1) The header works sort of like a session cookie. When the header is sent > to the browser, you can specify the domain and path (http authentication > realm?) and an expiration timestamp. The timestamp only ensures that the > header will stop being sent back to the server if the browser is not closed > by that point. Just like current cookies, setting the timestamp to the past > will cause the session-id header to become immediately stale. > > 2) THE USER MAY NOT REJECT THE HEADER. Browsers that allow optional > rejection will be considered NON-STANDARDS-COMPLIANT. Proxies SHOULD NOT > REJECT THE HEADER. I would prefer to make this MAY NOT, but I doubt it > would stick. What are proxies allowed to do with the www-authenticate > header? > > 3) the www-authenticate and session-id headers are mutually exclusive. In > other words, if a browser receives a session-id header which matches the > existing realm, the browser dumps the www-authenticate response and uses > session-id instead. This allows the http authentication methods to still be > used, but also allows the request headers to be replaced with something that > is more controllable by the server. > > > Though I know that more thought needs to be put into the idea, I feel it > would provide the consistency of basic authentication, the flexibility and > overhead of cookies, and the security of digest authentication. Note that > it is not even necessary to use HTML forms, since http authentication could > be used as the first step then replaced as in #3 above. However, if one > *really* wants the nice look, they could do that as well. > > So, what do you all think? Would this interfere with the REST model? > > --- > Seairth Jacobs > seairth@... > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
Guys, Lately I've been putting a lot of time into learning/mastering XML Schema and I have to say I'm extremely disappointed with this technology. It's horrendously complex and it's not even simple enough to solve some of the trivial problems I'm throwing at it (unless you revert to using xs:token for every datatype which kind of defeats the purpose). I really don't like it and I don't see the average developer liking and/or using it. I've done a bit of research on the alternatives and I've come across RELAX NG which is muuch better and simpler but the problem is that the tool support for RELAX NG is non-existent. I'm not aware of a RELAX NG API for either Java or .NET which is my primary audience at this point. That being said, I remember a while back Roger suggested that HTML should be used to describe the XML/Interface for RESTful webservices (eg what gets POSTed to resource X). I didn't really understand what he was saying then, but now it makes perfect sense to me. The primary goal for interface specifications (primarily describing data structures, that is the structure of XML documents) should be for documentation purposes, not code generation purposes (which is the only real goal of XML Schema). Since no elegant or simple technologies exist to describe XML document structure, I'm starting to lean towards Roger's solution of using HTML which is undeniably the most accessible and understood markup language out there today. What do others think?
On Mon, Aug 26, 2002 at 08:28:15AM -0000, inthedarkplace wrote: > > I've done a bit of research on the alternatives and I've come across > RELAX NG which is muuch better and simpler but the problem is that > the tool support for RELAX NG is non-existent. I'm not aware of a > RELAX NG API for either Java or .NET which is my primary audience at > this point. Well, for Java there's Jing: http://www.thaiopensource.com/relaxng/jing.html > only real goal of XML Schema). Since no elegant or simple > technologies exist to describe XML document structure, DTDs are arguably both elegant and simple. But maybe you need to use namespaces? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Mark Baker wrote: > > Nope?!! I thought I said the same thing. > > What's the difference? Where am I wrong? > > I don't get it at all. > > It's your use of the word "request". The client can't request it. It > just sends the data, and it's up to the container to do it, or not. I meant "request" in the sense of HTTP Request. (Not the everyday use of the word.) I thought HTTP was a Request-Response protocol. The URI for the new resource comes back on the Response. No? But I'm happy to change the word. What would you say instead? > I suppose you could consider the use of SOAPAction with a URI > identifying the expected type (in this case, a > StatePreservingContainer), a "request". But I didn't get the impression > that that's what you were suggesting. If so, then you were right. No, I want to stay away from SOAP in these discussions as long as possible. > > Also, the name StatePreservingContainer is not very clear, at least > > to me. Nor is IdentityPreservingContainer. But maybe that's because > > I'm still missing some subtlety. > > No, it could be the name. If you've got any suggestions after this, > I'm all ears. The feature we are discussing is the creation of a new resource in response to a POST, right? "IdentityPreserving" sounds like it already has an identity, and the container is preserving it, whereas the server is creating the identity. How long the identity is preserved is another consideration; "forever" may not be needed. "ResourceCreatingContainer" would work for me, if that is the main distinguishing feature of this type.
That wasn't helpful at all (with apologies :)). If "there is no session" means to say that you get rid of the concept of sessions when using the REST model, then I honestly do not see how REST could be successfully applied to the majority of existing web applications today. Further, if anyone considers HTTP authentication to not be a session-handling method (though I know you didn't say this), I strongly disagree. And what do you mean by the second quote? If these quotes are the answers to my session-handling issues, then I obviously have a gross misunderstanding about how REST is meant to work... --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Mark Nottingham" <mnot@...> > This may be helpful: > > "There is no session" > > and > > "You'll come to realize, as I did, that there's a difference between > knowing the resource and representing the resource." > > (with apologies) > > > > ----- Original Message ----- > From: "Seairth Jacobs" <seairth@...> > To: "rest-discuss" <rest-discuss@yahoogroups.com> > Sent: Sunday, August 25, 2002 7:46 PM > Subject: [rest-discuss] Beating my head against the "session management" > wall > > > > *sigh* Do you ever have the feeling that the solutions set before you > are > > all not-quite-good-enough, each in their own way? Currently, this is > how I > > am feeling about session management when it comes to REST... > > > > Known options: > > > > 1) HTTP Authentication: This is a simple, non-intrusive solution. > However, > > "basic" is insecure and "digest" is not consistently implemented. > > > > 2) Generating your own "session id". This has the problem that you must > > provide an "intrusive" login screen/process. Further, you then need to > > continue tracking the session id. With this, there are two techniques > > (well, three sorta): > > > > a) Session Cookie: If done properly, this is effectively no > different > > than http authentication in the sense that the browser is sending an > > "authenticating" identifier with each request. Session cookies are > somewhat > > nicer than http authentication in that they are potentially more secure > (if > > done correctly) and that it is easier for the server to handle them > (e.g. > > deleting them, updating them, etc.). The major down side is that > current > > browsers allow the users to reject session cookies. > > > > b) Query String: This one, from a REST POV, seems like a really bad > > technique. This effectively creates non-permanent unique URL spaces for > > each user session. Further, the session id may not actually be related > to > > the resource that the URL (with the query string) is pointing to. > However, > > the good thing about query strings is that, short of a user typing an > > address into the browser or using a stored link, the server has control > over > > them and the user does not have the ability to reject them. > > > > c) Hidden Field: if you are not using the QueryString method and are > > have a form, you could put the session id in a hidden field. However, > you > > are then limited to using only the POST method. Otherwise, the browser > will > > generate a URL with your hidden field showing up in a QueryString. But, > if > > the request is guaranteed to be idempotent, then it is my understanding > that > > the GET method should be used, not POST. > > > > > > Now, I know that all of the above methods (with the possible exception > of > > digest authentication, if done correctly and at a certain cost) still > allows > > someone to sniff the connection and get enough information to > potentially > > mimic the session. This could all be taken care of using SSL (at which > > point, even basic authentication is secure), but that seems to be adding > a > > lot of overhead. When I only need to authenticate the request, not > secure > > the response, this seems like overkill (and it can be expensive too). > > > > > > > > Frankly, I think I am leaning towards session cookies at this point. > Since > > the site will primarily be for web developers, I am hoping that they at > > least accept session cookies. I would have liked to go the HTTP > > authentication route, but it just seems to unsecure for my taste > > (considering the fact that I am not using SSL). If anyone out there can > > convince my why I should not follow this route, esp. as far as REST is > > concerned, please say so. I really would like to be convinced of > another > > method. > > > > > > IN THE MEANTIME.... > > > > I have been thinking of this dilemma (the one above). And I have an > idea. > > I am wondering whether the idea would work well with the REST model or > not. > > If it would, I would like to get a group of people together to formalize > it > > and get it submitted to the right people. > > > > What I propose is that web browsers should support a new HTTP header > called > > "session-id". This header would conform to the following rules: > > > > 1) The header works sort of like a session cookie. When the header is > sent > > to the browser, you can specify the domain and path (http authentication > > realm?) and an expiration timestamp. The timestamp only ensures that > the > > header will stop being sent back to the server if the browser is not > closed > > by that point. Just like current cookies, setting the timestamp to the > past > > will cause the session-id header to become immediately stale. > > > > 2) THE USER MAY NOT REJECT THE HEADER. Browsers that allow optional > > rejection will be considered NON-STANDARDS-COMPLIANT. Proxies SHOULD > NOT > > REJECT THE HEADER. I would prefer to make this MAY NOT, but I doubt it > > would stick. What are proxies allowed to do with the www-authenticate > > header? > > > > 3) the www-authenticate and session-id headers are mutually exclusive. > In > > other words, if a browser receives a session-id header which matches the > > existing realm, the browser dumps the www-authenticate response and uses > > session-id instead. This allows the http authentication methods to > still be > > used, but also allows the request headers to be replaced with something > that > > is more controllable by the server. > > > > > > Though I know that more thought needs to be put into the idea, I feel it > > would provide the consistency of basic authentication, the flexibility > and > > overhead of cookies, and the security of digest authentication. Note > that > > it is not even necessary to use HTML forms, since http authentication > could > > be used as the first step then replaced as in #3 above. However, if one > > *really* wants the nice look, they could do that as well. > > > > So, what do you all think? Would this interfere with the REST model? > > > > --- > > Seairth Jacobs > > seairth@... > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
On Fri, Aug 23, 2002 at 11:32:19AM -0400, Mathews, Walden wrote: > The root of all evil here is the fact that *operations* are also first class > abstractions, > every bit as first class as *resource state*, except in REST (and for well > understood > reasons there). > > So how do you evaluate the tradeoff between using RDF as part of resource > state > to extend the semantics of 'generic' methods? As opposed to extending the > defined set of > methods for the sake of greater method specificity? Extending the methods means being able to reuse the semantics of the existing contract between client and server; aka firewall safe. If I POST some data to /foo with an intent of /bar, I'm still doing a POST, and it's still the server that has the ultimate say (because it's still a POST). This is in contrast to invoking the BAR method, which could mean anything. > As opposed to adding > 'control' data > (mentioned in the thesis, but not in association with HTTP) to qualify > methods? AFAIK, "control data" refers to fringe "management" aspects of the connection; caching, varyability, connection stuff, mux, ordering, etc.. It doesn't change or extend the methods. > As > opposed to any other meta-method for working around generic method > limitations? Not sure what other approaches there might be. PEP had the "PEP" method, which was sort of a wildcard so that you could URI-identify an extension method. Think of it as a layer 6 construct, so that the URI could identify the layer 7 extension. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Mon, Aug 26, 2002 at 11:44:06AM -0000, bhaugen32 wrote: > > It's your use of the word "request". The client can't request it. > It > > just sends the data, and it's up to the container to do it, or not. > > I meant "request" in the sense of HTTP Request. > (Not the everyday use of the word.) > I thought HTTP was a Request-Response protocol. > The URI for the new resource comes back on the Response. > > No? Ok, but I took your use of the word to imply that there was something about the HTTP request message that made the server think that this message was explicitly asking that a new resource be created. > But I'm happy to change the word. > What would you say instead? "Intent" is the word that SOAP uses to describe SOAPAction. I like it. i.e. "this HTTP POST request is sent with the intent of archiving the data". > > I suppose you could consider the use of SOAPAction with a URI > > identifying the expected type (in this case, a > > StatePreservingContainer), a "request". But I didn't get the > impression > > that that's what you were suggesting. If so, then you were right. > > No, I want to stay away from SOAP in these discussions as long as > possible. Ok, but this mechanism is needed in vanilla HTTP too, whether or not it comes from SOAP. Basically, a header that must be understood by the recipient, otherwise the intent will be lost and communication will be unclear. > > No, it could be the name. If you've got any suggestions after this, > > I'm all ears. > > The feature we are discussing is the creation of a new resource in > response to a POST, right? "IdentityPreserving" sounds like it > already has an identity, and the container is preserving it, whereas > the server is creating the identity. Right. Hence the change .. > How long the identity is > preserved is another consideration; "forever" may not be needed. > "ResourceCreatingContainer" would work for me, if that is the main > distinguishing feature of this type. It sort of is, but it's not that any old resource is created, it's that one whose initial state is equivalent to what was POSTed is created. That's what we need a good name for. "ResourceCreatingContainer" describes the behaviour - resource creation - not the purpose of the container. I'm not sure how that would be used. Or to rephrase, the interesting thing is not to know whether or not a resource is to be created, because you'll know that anyhow after the POST - the interesting thing to know is *why* it will be created and what it means that it was. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Mon, Aug 26, 2002 at 11:21:26AM -0400, Mathews, Walden wrote: > > Extending the methods means being able to reuse the semantics of the > > existing contract between client and server; aka firewall safe. If I > > POST some data to /foo with an intent of /bar, I'm still doing a POST, > > and it's still the server that has the ultimate say (because > > it's still > > a POST). This is in contrast to invoking the BAR method, which could > > mean anything. > > > > I'd like to understand this point better. Nothing I can do as a client > in the HTTP method space can change the fact that "it's still the server > that has the ultimate say". BAR *could* mean anything, while POST already > *does* mean anything (virtually). Whatever BAR might mean, if the community (i.e. IETF) has specified that HTTP implementations MUST support BAR, then the server doesn't have the final say, the spec does. > A little clarification: the fact that a server doesn't have to do what I > say in a POST is not a property of POST; it's a property of HTTP, and more > broadly, of server side applications that are autonomous in their > respective domains, regardless of which level 7 protocol they use. In the broader space of "server side applications", I'd say that the party(s) that define the contract get the final say. With most RPC systems, this could be the very people who implement the system, and so they do/can have the final say. But when the world sits down to design an application protocol, it is done with the expectation that implementors - many/most of whom won't be at the standardization table - will follow the rules in the specification. And this is, in fact, what happens most of the time. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Monday, August 26, 2002 11:37 AM > To: Mathews, Walden > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: PUT, POST, authorization and purchase > orde rs > > > On Mon, Aug 26, 2002 at 11:21:26AM -0400, Mathews, Walden wrote: > > > Extending the methods means being able to reuse the > semantics of the > > > existing contract between client and server; aka firewall > safe. If I > > > POST some data to /foo with an intent of /bar, I'm still > doing a POST, > > > and it's still the server that has the ultimate say (because > > > it's still > > > a POST). This is in contrast to invoking the BAR method, > which could > > > mean anything. > > > > > > > I'd like to understand this point better. Nothing I can do > as a client > > in the HTTP method space can change the fact that "it's > still the server > > that has the ultimate say". BAR *could* mean anything, > while POST already > > *does* mean anything (virtually). > > Whatever BAR might mean, if the community (i.e. IETF) has > specified that > HTTP implementations MUST support BAR, then the server > doesn't have the > final say, the spec does. Sorry, I'm confused. By "HTTP implementations" do you mean things like libwww, or applications that use HTTP? Then, I'll infer the meaning of "support BAR" from that, hopefully. But in the meantime, for technologies like libwww, HttpClient and Servlet to "support BAR" means little more than forwarding messages with them. On the other hand, applications seem to be free to choose which methods they will and will not support (or else there are some superfluous response codes). Like I said, I'm confused... > > > A little clarification: the fact that a server doesn't have > to do what I > > say in a POST is not a property of POST; it's a property of > HTTP, and more > > broadly, of server side applications that are autonomous in their > > respective domains, regardless of which level 7 protocol they use. > > In the broader space of "server side applications", I'd say that the > party(s) that define the contract get the final say. With most RPC > systems, this could be the very people who implement the > system, and so > they do/can have the final say. But when the world sits down > to design > an application protocol, it is done with the expectation that > implementors - many/most of whom won't be at the > standardization table - > will follow the rules in the specification. And this is, in > fact, what > happens most of the time. And that's fine for methods GET, PUT and DELETE, all of whose meanings are bounded to a single conceptual resource. POST is in a different class, as you know. One might say that it's *underspecified* as an application semantic, or from the other point of view, that it's overloaded to catch everything that's not meant by the other methods. What I'm trying to understand is why it is more of a security concern to use a very underspecified HTTP method (e.g., "BAR", which is not specified at all as an HTTP method) as opposed to a somewhat underspecified method, "POST". POST seems like a ready-made tunnel for resource mutation, and hence even in RESTful design it is used this way. Why should a firewall treat POST any differently than BAR, given the real limitations to visibility? Thanks, Walden
We're creeping into rest-explore territory here. On Mon, Aug 26, 2002 at 12:05:37PM -0400, Mathews, Walden wrote: > > Whatever BAR might mean, if the community (i.e. IETF) has > > specified that > > HTTP implementations MUST support BAR, then the server > > doesn't have the > > final say, the spec does. > > Sorry, I'm confused. By "HTTP implementations" do you mean things > like libwww, or applications that use HTTP? Mostly the former, but ultimately both, since it takes both together to complete the task. For example, a servlet can give you doGet(), and manage etags and cache control and stuff for you, but it's still up to the app to not to change state when it's invoked. > Then, I'll infer the meaning > of "support BAR" from that, hopefully. But in the meantime, for > technologies like libwww, HttpClient and Servlet to "support BAR" > means little more than forwarding messages with them. On the other > hand, applications seem to be free to choose which methods they will > and will not support (or else there are some superfluous response > codes). Like I said, I'm confused... > > > > > > A little clarification: the fact that a server doesn't have > > to do what I > > > say in a POST is not a property of POST; it's a property of > > HTTP, and more > > > broadly, of server side applications that are autonomous in their > > > respective domains, regardless of which level 7 protocol they use. > > > > In the broader space of "server side applications", I'd say that the > > party(s) that define the contract get the final say. With most RPC > > systems, this could be the very people who implement the > > system, and so > > they do/can have the final say. But when the world sits down > > to design > > an application protocol, it is done with the expectation that > > implementors - many/most of whom won't be at the > > standardization table - > > will follow the rules in the specification. And this is, in > > fact, what > > happens most of the time. > > And that's fine for methods GET, PUT and DELETE, all of whose meanings > are bounded to a single conceptual resource. POST is in a different > class, as you know. One might say that it's *underspecified* as an > application > semantic, or from the other point of view, that it's overloaded to catch > everything that's not meant by the other methods. I wouldn't say that it's underspecified at all. Why do you believe it is? > What I'm trying to understand is why it is more of a security concern > to use a very underspecified HTTP method (e.g., "BAR", which is not > specified > at all as an HTTP method) as opposed to a somewhat underspecified method, > "POST". POST seems like a ready-made tunnel for resource mutation, and > hence even in RESTful design it is used this way. Why should a firewall > treat POST any differently than BAR, given the real limitations to > visibility? The fundamental issue to firewall admins is that somebody on the other side of the firewall should not be able to extend the semantics of the connection such that visibility to the firewall is reduced. i.e. the system shouldn't be able to break itself. People have, for some time, talked about being able to *prove* the security of application protocols like HTTP, by examining exactly these sorts of issues; what kinds of extended agreement can be created, and can it ever be used to do something that goes against a security policy enacted by an intermediary. For RFC 2616 POST, this *cannot* be done. But it's not automatically the case for extension methods - they need to be studied closely. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
My pop culture references weren't meant to answer your questions; I was hoping/assuming that someone more REST enlightened than I would do so. Since noone has, here are my thoughts; HTTP authentication clearly involves keeping state on the client; as such, whenever I try to resource model an application, this is the main means of identifying a client in order to tailor information for it. As you surmise, cookies are often used in place of HTTP authentication because they can be persistent across invocations of the browser (although modern browsers address this with a 'password store' mechanism), they can be deleted, and because there is more control over the UI. Authentication, OTOH, has advantages in that the state can be incorporated into the URI (cookies can't), and the mechanism is standardized, allowing for machines to present credentials (this could be possible with cookies, but practically, it's impossible; they'd have to understand your specific authentication scheme). Doing it in the request body (POST) is clearly not RESTful, and doing it correctly with the URI query is tricky at best, IMHO. So, when choosing between these mechanisms, I prefer HTTP authentication wherever possible; if you investigate modern browsers, you should find that Digest has been implemented correctly (I use it opften with IE6, Mozilla and Amaya; IIRC it also works on Opera). All of this notwithstanding, and most importantly, if you approach your application from a model of 'sessions' (which most environments encourage you to do), you'll find it very hard to keep it RESTful. Model your application as resources which expose state as representations, and the issue of sessions will (hopefully) dissolve into the background, for the most part. Architecting applications that don't require client state brings many benefits. Witness search engines, translation services, annotation services, shared caching, 'this page has changed' bots, etc., etc. Requiring client state reduces the effectiveness or even eliminates these benefits, and locks your users into exactly one way of seeing the data: the way that you lead them through it. While this is attractive to the application developer, it isn't to users, and hence ultimately reduces the potential benefit of making the application part of the Web. Regards, ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Monday, August 26, 2002 7:06 AM Subject: Re: [rest-discuss] Beating my head against the "session management" wall > That wasn't helpful at all (with apologies :)). If "there is no session" > means to say that you get rid of the concept of sessions when using the REST > model, then I honestly do not see how REST could be successfully applied to > the majority of existing web applications today. Further, if anyone > considers HTTP authentication to not be a session-handling method (though I > know you didn't say this), I strongly disagree. > > And what do you mean by the second quote? > > > If these quotes are the answers to my session-handling issues, then I > obviously have a gross misunderstanding about how REST is meant to work... > > --- > Seairth Jacobs > seairth@... > > > ----- Original Message ----- > From: "Mark Nottingham" <mnot@...> > > > This may be helpful: > > > > "There is no session" > > > > and > > > > "You'll come to realize, as I did, that there's a difference between > > knowing the resource and representing the resource." > > > > (with apologies) > > > > > > > > ----- Original Message ----- > > From: "Seairth Jacobs" <seairth@...> > > To: "rest-discuss" <rest-discuss@yahoogroups.com> > > Sent: Sunday, August 25, 2002 7:46 PM > > Subject: [rest-discuss] Beating my head against the "session management" > > wall > > > > > > > *sigh* Do you ever have the feeling that the solutions set before you > > are > > > all not-quite-good-enough, each in their own way? Currently, this is > > how I > > > am feeling about session management when it comes to REST... > > > > > > Known options: > > > > > > 1) HTTP Authentication: This is a simple, non-intrusive solution. > > However, > > > "basic" is insecure and "digest" is not consistently implemented. > > > > > > 2) Generating your own "session id". This has the problem that you must > > > provide an "intrusive" login screen/process. Further, you then need to > > > continue tracking the session id. With this, there are two techniques > > > (well, three sorta): > > > > > > a) Session Cookie: If done properly, this is effectively no > > different > > > than http authentication in the sense that the browser is sending an > > > "authenticating" identifier with each request. Session cookies are > > somewhat > > > nicer than http authentication in that they are potentially more secure > > (if > > > done correctly) and that it is easier for the server to handle them > > (e.g. > > > deleting them, updating them, etc.). The major down side is that > > current > > > browsers allow the users to reject session cookies. > > > > > > b) Query String: This one, from a REST POV, seems like a really bad > > > technique. This effectively creates non-permanent unique URL spaces for > > > each user session. Further, the session id may not actually be related > > to > > > the resource that the URL (with the query string) is pointing to. > > However, > > > the good thing about query strings is that, short of a user typing an > > > address into the browser or using a stored link, the server has control > > over > > > them and the user does not have the ability to reject them. > > > > > > c) Hidden Field: if you are not using the QueryString method and are > > > have a form, you could put the session id in a hidden field. However, > > you > > > are then limited to using only the POST method. Otherwise, the browser > > will > > > generate a URL with your hidden field showing up in a QueryString. But, > > if > > > the request is guaranteed to be idempotent, then it is my understanding > > that > > > the GET method should be used, not POST. > > > > > > > > > Now, I know that all of the above methods (with the possible exception > > of > > > digest authentication, if done correctly and at a certain cost) still > > allows > > > someone to sniff the connection and get enough information to > > potentially > > > mimic the session. This could all be taken care of using SSL (at which > > > point, even basic authentication is secure), but that seems to be adding > > a > > > lot of overhead. When I only need to authenticate the request, not > > secure > > > the response, this seems like overkill (and it can be expensive too). > > > > > > > > > > > > Frankly, I think I am leaning towards session cookies at this point. > > Since > > > the site will primarily be for web developers, I am hoping that they at > > > least accept session cookies. I would have liked to go the HTTP > > > authentication route, but it just seems to unsecure for my taste > > > (considering the fact that I am not using SSL). If anyone out there can > > > convince my why I should not follow this route, esp. as far as REST is > > > concerned, please say so. I really would like to be convinced of > > another > > > method. > > > > > > > > > IN THE MEANTIME.... > > > > > > I have been thinking of this dilemma (the one above). And I have an > > idea. > > > I am wondering whether the idea would work well with the REST model or > > not. > > > If it would, I would like to get a group of people together to formalize > > it > > > and get it submitted to the right people. > > > > > > What I propose is that web browsers should support a new HTTP header > > called > > > "session-id". This header would conform to the following rules: > > > > > > 1) The header works sort of like a session cookie. When the header is > > sent > > > to the browser, you can specify the domain and path (http authentication > > > realm?) and an expiration timestamp. The timestamp only ensures that > > the > > > header will stop being sent back to the server if the browser is not > > closed > > > by that point. Just like current cookies, setting the timestamp to the > > past > > > will cause the session-id header to become immediately stale. > > > > > > 2) THE USER MAY NOT REJECT THE HEADER. Browsers that allow optional > > > rejection will be considered NON-STANDARDS-COMPLIANT. Proxies SHOULD > > NOT > > > REJECT THE HEADER. I would prefer to make this MAY NOT, but I doubt it > > > would stick. What are proxies allowed to do with the www-authenticate > > > header? > > > > > > 3) the www-authenticate and session-id headers are mutually exclusive. > > In > > > other words, if a browser receives a session-id header which matches the > > > existing realm, the browser dumps the www-authenticate response and uses > > > session-id instead. This allows the http authentication methods to > > still be > > > used, but also allows the request headers to be replaced with something > > that > > > is more controllable by the server. > > > > > > > > > Though I know that more thought needs to be put into the idea, I feel it > > > would provide the consistency of basic authentication, the flexibility > > and > > > overhead of cookies, and the security of digest authentication. Note > > that > > > it is not even necessary to use HTML forms, since http authentication > > could > > > be used as the first step then replaced as in #3 above. However, if one > > > *really* wants the nice look, they could do that as well. > > > > > > So, what do you all think? Would this interfere with the REST model? > > > > > > --- > > > Seairth Jacobs > > > seairth@... > > > > > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > > > > > Your use of Yahoo! Groups is subject to > > http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
I agree with Mark completely. The main problem is that the current generation of browsers don't provide sufficient functionality to allow the client-side to maintain the necessary state required for some operations. We've talked about shopping baskets here before; their state should ideally be maintained at the client, not the server. But currently there is no means for handling this on the client. But you could imagine browsing through a web site, dragging off products you want and dropping them in a local folder, then at some point dragging that folder and dropping it onto the "checkout" symbol within the web page. No session required. I wonder how far you could take "file upload" in this direction? And/or some Javascript to provide the local containers ... Hmm. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
That's an important distinction that I didn't make (and hadn't fully appreciated until Mark pointed it out) - client state in itself isn't bad, it's enshrining it in the protocol interactions that brings the problems. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Monday, August 26, 2002 12:13 PM Subject: Re: [rest-discuss] Beating my head against the "session management" wall > I agree with Mark completely. > > The main problem is that the current generation of browsers don't > provide sufficient functionality to allow the client-side to maintain > the necessary state required for some operations. We've talked about > shopping baskets here before; their state should ideally be maintained > at the client, not the server. But currently there is no means for > handling this on the client. > > But you could imagine browsing through a web site, dragging off > products you want and dropping them in a local folder, then at some > point dragging that folder and dropping it onto the "checkout" > symbol within the web page. No session required. > > I wonder how far you could take "file upload" in this direction? And/or > some Javascript to provide the local containers ... Hmm. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
inthedarkplace wrote: > Guys, > > I'm curious; has anybody established any best practices for > performing arbitrary searching of collection resources? Eg, say I > have the collection /users and I want to find a user with the > username 'kd'. What's the most RESTful and elegant way to do this? > 2) Have the user do a GET on the users collection, passing the search > query in through the query string. eg /users?username='xxx' > > Pros: Intuitive. This is what for the query string is for, I think. > It also allows the user to bookmark searches which might be > potentially very useful for working with sets of users. > > Cons: Severely limits the expressiveness of queries. Also puts more > code in the users code, but this isn't a huge issue. To me, the above (2) is the most HTTP way of doing it. I like it because it fits the query parameter model. It's idempotent. It's also very simple. The value of username can be a string, a regexp, or whatever. Our app uses just values that have to match. If the parameter is "dateLessThan" then the date must be less than. Of course, if that's not expressive enough, the client can get the entire resource and perform its own searches. It may help to think why your client does not know what it is looking for. There may be a better way to model the app such that the client has a much clearer path to getting to the object. Anyhoot, my vote: use query parameters to "whittle down" that particular resource. If the resource is a collection, I don't believe this violates any RESTful thinking. Seth
Just to pipe in a quick comment -- I totally appreciate this viewpoint, thanks for sharing it. To me, styles such as client state really represent what REST promises in terms of a really truly scalable architecture. Scalability becomes less of a problem and more of an attribute of the architectural style of your solution, because session is distributed across all the clients that access a server's services. In many existing web applications, sessions take up lots of memory, cause state management headaches, and make clustering/load balancing more complicated/expensive than it needs to be. Perhaps curing these evils will eventually become a selling point (to distributed programmers, not marketing types) of the RESTful approach. -----Original Message----- From: Mark Nottingham [mailto:mnot@...] Sent: Monday, August 26, 2002 3:26 PM To: Mark Baker Cc: rest-discuss Subject: Re: [rest-discuss] Beating my head against the "session management" wall That's an important distinction that I didn't make (and hadn't fully appreciated until Mark pointed it out) - client state in itself isn't bad, it's enshrining it in the protocol interactions that brings the problems. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Monday, August 26, 2002 12:13 PM Subject: Re: [rest-discuss] Beating my head against the "session management" wall > I agree with Mark completely. > > The main problem is that the current generation of browsers don't > provide sufficient functionality to allow the client-side to maintain > the necessary state required for some operations. We've talked about > shopping baskets here before; their state should ideally be maintained > at the client, not the server. But currently there is no means for > handling this on the client. > > But you could imagine browsing through a web site, dragging off > products you want and dropping them in a local folder, then at some > point dragging that folder and dropping it onto the "checkout" > symbol within the web page. No session required. > > I wonder how far you could take "file upload" in this direction? And/or > some Javascript to provide the local containers ... Hmm. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
Just found this; http://www.concentric.net/~aleph0/www/interactive/drafts/draft-burchard-www-arch.html Pretty interesting. It isn't dated, but I'd guess it's probably from around 95/96 when Paul was most active in Web stuff. I think that IDL is the wrong language in which to create this type of model, but if I had to use it, my model would probably look a whole lot like that. The explicit calling out of compound documents is good, though I think he missed the ball on tying it to the model, since he seems to be under the impression that there are "presentation resources". But the seeds are there anyhow. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Let's start at the top and describe what problems session management solves for you. With that, we can stay concrete in our suggestions on how to maintain a RESTful design. From my experience, session management has been a mechanism to achieve higher performance through servers-side caching of some data. What does 'session management' mean to you?
> The explicit calling out of compound documents is good, > though I think he missed the ball on tying it to the model, since he > seems to be under the impression that there are "presentation > resources". I think his concept of 'presentation resources' as being named items on the client is interesting. For example, in HTML DOM, there are items in the user agent that are named and referenceable in HTML - e.g. the <a target=""> stuff. Pushing this to be generalized in that you 'post' to the display area is a bit much abstraction though.
> Finally --- and I *WISH* that somebody in the server implementation > world would finally get a clue and realize this --- in e.g. most > enterprise IT settings the folks that manage server configuration are > different from the folks that manage application data are different from > the folks that develop the apps! It's not the case that these are the > same people, or that folks in either of the latter two camps even have > shell access to the machines that the apps run on, much less the ability > to muck with various configuration files. If the Apache guys wanted to > see HTTP authentication used for more than just small-scale Intranet / > group use, they should create a generic and standard authentication > framework into which arbitrary authentication schemes could be > plugged --- and no, I'm not talking about PAM-like stuff that > authenticates against the typical system / user DBs, I'm talking about > an API into which any app developer could plug an arbitrary module to > authenticate against e.g. the application's own user DB. (It might be > there already, but if it is I haven't found it. ;-) Bottom line, HTTP > authentication doesn't get used on the larger scales because the guys > building the apps don't own the config, the guys that own the config > aren't in the business of user management for a given app, and never the > twain shall meet (today.) I can't express how much I agree, but I can try. One of the banes of my existence is the poor support for metadata in Web servers; not just authentication, but HTTP headers, status codes, etc. in general. It's absurd that if I want to generate a redirect, I have to go and modify the server configuration; no wonder so many people use HTML refresh! Same with caching headers, etc. This is not a trivial problem, doubly so if it needs to be standardized across servers. We can try, however (and I'll glady lend my hand if someone's interested in starting...) > But > identifying a sequence of HTTP "transactions" as related by grouping > them in a session is not by itself a killer for REST. I generally agree, but it's very easy for developers to over-rely on sessions.
On Mon, Aug 26, 2002 at 01:22:19PM -0700, Mark Nottingham wrote: > I can't express how much I agree, but I can try. Yah, ditto. Mark, I recall an old I-D of yours - that I can't track down now - that talked about the practical problems with Web servers not exposing enough, or exposing too much info to their users. It was really excellent. Do you have an archive copy around? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Do you mean: http://www.mnot.net/papers/capabilities.pdf Would be interesting to update that now... ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Monday, August 26, 2002 1:29 PM Subject: Re: [rest-discuss] Beating my head against the "session management" wall > On Mon, Aug 26, 2002 at 01:22:19PM -0700, Mark Nottingham wrote: > > I can't express how much I agree, but I can try. > > Yah, ditto. > > Mark, I recall an old I-D of yours - that I can't track down now - that > talked about the practical problems with Web servers not exposing > enough, or exposing too much info to their users. It was really > excellent. Do you have an archive copy around? > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote: > I agree with Mark completely. > > But you could imagine browsing through a web site, dragging off > products you want and dropping them in a local folder, then at some > point dragging that folder and dropping it onto the "checkout" > symbol within the web page. No session required. > > I wonder how far you could take "file upload" in this direction? And/or > some Javascript to provide the local containers ... Hmm. Personally, I'd advise against forcing the client to maintain state and particularly potentially sensitive data like a shopping. It restricts what your client can do and it just invites all sorts of security breaches. The way I maintain session in some apps is simply to expose a /sessions/ resource. The session of each individual user is stored below this, usually just by appending a user-id to the /sessions/ resource -- eg /sessions/3423423423/ would be my session. This simple architecture has a lot of benefits. Particularly, I can create a session on one computer in the red building and then walk over to my lab and retrieve my previous session. The real problem is not necessarily maintaining session, but identifying new users and returning users. There really is no clean way to do this and it's a big drawback of HTTP. The solutions are: 1) Use HTTP digest authentication. If the user doesn't authenticate then they become the generic 'Anonymous User' and no session state will be maintained for them. 2) Use cookies. Simple and cheap, and it doesn't require you to create accounts for each user, especially for anonymous users. For example, it's often the case that you want to maintain state for a client without forcing that client to login. Cookies let you do this. Cookies do complicate your client code since developers creating non- browser apps must understand cookies. 3) Create a session ID and embed it in the URI. This is very simple but it has a lot of problems. Users can no longer bookmark URLs and every URL exposed to the user must be 'sessionified'. My suggestion: Just use cookies. I know Fielding says cookies are non-restful, but there's really no better way. It's what they're there for. Note that just because a user has a cookie should not grant that user extra permissions. Cookies aren't an authentication mechanism. If a user needs to perform some security-sensitive mechansim then you should make them login using digest authentication. The great thing about http digest authentication (whether Fielding admits it or not) is that it's essentially a standardized cookie/session-id. The user is required to authenticate themself with every request so you get all the benefits of cookie plus security. - inthedarkplace
Ooh, cool, hadn't seen that. But I was thinking of an Internet-Draft. I'd guess that this table was constructed as part of the same task that produced the I-D. MB On Mon, Aug 26, 2002 at 02:03:59PM -0700, Mark Nottingham wrote: > Do you mean: > http://www.mnot.net/papers/capabilities.pdf > > Would be interesting to update that now... MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > My pop culture references weren't meant to answer your questions; I was > hoping/assuming that someone more REST enlightened than I would do so. *whew* While I know I am not understanding this concept as well as I want, I was worried that those answers were either zen statements meant to shock me into enlightenment or that the answer was so obvious that nothing more needed to be said. :) > Since noone has, here are my thoughts; > > HTTP authentication clearly involves keeping state on the client; as such, > whenever I try to resource model an application, this is the main means of > identifying a client in order to tailor information for it. As you > surmise, cookies are often used in place of HTTP authentication because > they can be persistent across invocations of the browser (although modern > browsers address this with a 'password store' mechanism), they can be > deleted, and because there is more control over the UI. Authentication, > OTOH, has advantages in that the state can be incorporated into the URI > (cookies can't), and the mechanism is standardized, allowing for machines > to present credentials (this could be possible with cookies, but > practically, it's impossible; they'd have to understand your specific > authentication scheme). I'm not sure what you mean by "Authentication [...] can be incorporated into the URI". Otherwise, I agree with everything else you said. > Doing it in the request body (POST) is clearly not RESTful, and doing it > correctly with the URI query is tricky at best, IMHO. I absolutely agree. As a result, I am not even considering these as options. > So, when choosing between these mechanisms, I prefer HTTP authentication > wherever possible; if you investigate modern browsers, you should find > that Digest has been implemented correctly (I use it opften with IE6, > Mozilla and Amaya; IIRC it also works on Opera). Well, this is the first time I have seen mention that IE6 is compatible (IE5 wasn't, appearently). This is certainly good news. And yes, Opera does properly support digest authentication. > All of this notwithstanding, and most importantly, if you approach your > application from a model of 'sessions' (which most environments encourage > you to do), you'll find it very hard to keep it RESTful. Model your > application as resources which expose state as representations, and the > issue of sessions will (hopefully) dissolve into the background, for the > most part. That is what I have been trying to do. In fact, part of the purpose of this project is to gain better understanding and experience with the REST model. At first, I only focused on the resource model, ignoring authentication issues. This allowed me to construct what I believe to be a very clean and simple model. This model works quite well when was issuing unauthenticated GET requests. However, I then got to the part where people had the ability to modify and create (well, request creation of) new resources via POST. For these operations, it is necessary to be authenticated. Then I also came across a part of the model that required authenticated GET access. As I started workding this part out, all that came to mind was the use of sessions. I admit that this was an "easy" conclusion partly because I have written several other web applications in the past that were heavily dependent on the session-oriented model. Then I started learning more abouth HTTP authentication. I knew that basic authentication had the fundamental flaw that the user/pwd were submitted with every request. This did not seem a very good solution to me considering the security implications. I then started learning about digest authentication, but this too seemed to suffer some drawbacks: * inconsistant implemenation between MS and non-MS browsers: As I know now, this is no longer an issue since now IE6 seems to be compliant. * it only really added protection to the password: That's fine, really. The password was the important part, since their e-mail addresses were going to be their userId. * someone could still potentially use replay attacks and man-in-the-middle attacks (can't remember if there were others): I know that you could frequently change the nonce to limit the attacks, but at the cost of additional server-side application overhead. I am beginning to think this is worth the security. If I needed complete privacy, I would just use SSL on top of it all. * and an extreme lack of code demonstrating its use. This isn't really a problem with the method. It's really more of a problem because it's harder for me to figure out how to properly implement it. > Architecting applications that don't require client state brings many > benefits. Witness search engines, translation services, annotation > services, shared caching, 'this page has changed' bots, etc., etc. I absolutely agree. > Requiring client state reduces the effectiveness or even eliminates these > benefits, and locks your users into exactly one way of seeing the data: > the way that you lead them through it. While this is attractive to the > application developer, it isn't to users, and hence ultimately reduces the > potential benefit of making the application part of the Web. Again, I agree. Which is why I want to get this authentication thing right the first time... Now that I know that digest authentication works properly in IE6, this is looking like a much, much more attractive solution than cookies. Now all I need to do is find some code to implement it properly in PHP. Any suggestions? I'll take anything I can get at this point. Resources of this type for PHP seem to be non-existent. --- Seairth Jacobs seairth@...
(or should this be going to rest-explore?) ----- Original Message ----- From: "Mark Baker" <distobj@...> > > The main problem is that the current generation of browsers don't > provide sufficient functionality to allow the client-side to maintain > the necessary state required for some operations. We've talked about > shopping baskets here before; their state should ideally be maintained > at the client, not the server. But currently there is no means for > handling this on the client. Why not handle the shopping cart as it's own resource on the server? In fact, if done correctly, I could even see having an HTTP server that was dedicated and optimized to doing nothing but maintaining one or more site's "shopping cart resource". I'm not sure how this would work exactly, but I can vaguely see it working. As for the client program being capable of maintaining state, I can see doing that sort of thing now (with a bit of client-side programming, mint you). For instance, If you were at Amazon, each of the items you view is represented by an identifier (it's URL). Suppose you could right-click on the page and select the "add to amazon.com cart". This would cause the current URL you were at to be stored locally in a "cart" that was specific to amazon (though I suppose it could be more generic too). Now, suppose you have found everything you wanted to buy. You go up to your brower's menu (or taskbar or whatever) and bring up the amazon.com shopping cart ( which basically contains nothing but URLs). You then click on the "buy" button. This prompts your browser to submit (via POST) all of the URLs to an amazon.com location (not sure how that would be know, but let's assume it is) and amazon would now create the check-out resource that contains the items you are buying... then it's business as usual. Now, I know that it would be possible to add this functionality to IE6. Obviously, it would also require the amazon.com's of the world to provide their part of the functionality. But I think it would be possible. Further, it would be possible to merge this concept with the one above (dedicated "shopping cart" server), if wanted. This would potentially allow someone to access their shopping cart from any browser later on, as well as some other interesting benefits I can think of (such as the ability to share shopping carts with friends regardless of where you shop at). > But you could imagine browsing through a web site, dragging off > products you want and dropping them in a local folder, then at some > point dragging that folder and dropping it onto the "checkout" > symbol within the web page. No session required. Oh yeah. That's what I was saying too. :) Shoulda read the whole post first... --- Seairth Jacobs seairth@...
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> > > Let's start at the top and describe what problems session management solves > for you. > With that, we can stay concrete in our suggestions on how to maintain a > RESTful design. >From the more informative reply from Mark Nottingham, I am more confident in using digest authentication (assuming I can implement it in PHP). I have some questions about how it will work exactly, but I hope to find the answers as I go... > From my experience, session management has been a mechanism to achieve > higher performance through servers-side caching of some data. > What does 'session management' mean to you? To me, session management is a two-part device: 1) Persisting authentication (so that a user doesn't have to type in their password on each request) 2) Persisting data attached to the user for a limited period of time. In my case, I am really only concerned about the first half. I have worked to ensure (so far) that the second half is not a part of my application model. Hopefully, it will stay that way. :) --- Seairth Jacobs seairth@... > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Monday, August 26, 2002 1:03 PM > To: Mathews, Walden > Cc: rest-discuss@yahoogroups.com > Subject: HTTP and safety > > > We're creeping into rest-explore territory here. How so? My aim is to understand the claims that tunneling RPC traffic through HTTP POST creates a security problem that doesn't already exist with compliant uses of POST. A POST body will contain a representation of something that is loosely characterized as 'subordinate' to the referenced resource, which will invoke some processing of some kind. That representation may be the *record* of some desired action, and so will be interpreted on the server as the action. The meaning of this exchange will not be available to a firewall or other intermediary except at the most general level. And what it "means" there can be expressed approximately as "some side effect may occur, but don't bet on it". Above I've described what I understand to be RESTful use of the POST method. Please tell me how that differs in the security dimension from the dreaded 'tunneled RPC'. Note that I'm interested only in the security dimension right now. I understand that tunneling GETs through POST diminishes the capability of the layered system, and I suppose tunneling DELETE or PUT may diminish something as well. But in none of these cases is security diminished. At least I can't think of a reasonable admin policy toward POST that would result in such a diminishment. That's why, for the time being, I regard claims about diminished security to be exaggerations based on overgeneralization. What I need to see are some specific cases of firewall configuration and method abuse to better understand. > I wouldn't say that it's underspecified at all. Why do you believe it > is? Having just read that part of the spec again, I don't, actually. But that pushes me to a different conclusion: that the semantics of POST are being misrepresented on this mail list to include careful craftings of remote procedure calls in which the instructions have 'representations' that pass the 'representational state' test (which is a null test), and so appear to be 'state transfers' but are not. I'll give an example Request: PUT /some/number 2 Response: 201 Created Request: GET /some/number Response: 200 OK 2 Request: POST /some/number 'square' Response: 204 No Content Request: GET /some/number Response: 200 OK 4 This example achieves the squaring of 2 in a way that is quite different from the more obvious interpretations of "state transfer". Can we please discuss whether the above is "RESTful" and if not, what would it take to make it so? I believe that by tweaking the example above, we can arrive at one which illuminates the distinction I see between rest-discuss and RFC 2616 on the intended semantics of POST. The specification of POST in RFC 2616 relies on the term 'subordinate' to characterize the relationship between the POST entity and the referenced resource. It then avoids comprehensive definition of 'subordinate' in favor of an enumeration. It leaves us to infer that the 'subordinate' relation is the 'part->composite' relation, because all the enumerated examples are such, but I'd like to hear others' interpretations on this. Then there's the circumstantial stuff, like the fact that otherwise intelligent human beings typically stumble all over the meanings of the HTTP methods (and it's all because of POST) on first encounter, the fact that supplementary models of "resource type" have to be developed to delineate the possible POST behaviors, the appearance of the word "intent" to describe the fleshing out of application semantics for POST, which seems unnecessary for all of the other HTTP methods, and a comment by someone who signs his emails with your signature to the effect that "POST is the catch-all mutator method". What I think is happening here is that we're still feeling the growing pains of HTTP/REST as it tries to be more than a document maintenance pattern and less than a 'protocol prostitute' (sorry, the alliteration made me do that!). This is super-long, so thanks in advance to all who made it to the end! Walden
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> To: "'Mark Baker'" <distobj@...> Cc: <rest-discuss@yahoogroups.com> Sent: Tuesday, August 27, 2002 10:47 AM Subject: [rest-discuss] RE: HTTP and safety > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Monday, August 26, 2002 1:03 PM > To: Mathews, Walden > Cc: rest-discuss@yahoogroups.com > Subject: HTTP and safety > > > We're creeping into rest-explore territory here. How so? My aim is to understand the claims that tunneling RPC traffic through HTTP POST creates a security problem that doesn't already exist with compliant uses of POST. A POST body will contain a representation of something that is loosely characterized as 'subordinate' to the referenced resource, which will invoke some processing of some kind. That representation may be the *record* of some desired action, and so will be interpreted on the server as the action. The meaning of this exchange will not be available to a firewall or other intermediary except at the most general level. And what it "means" there can be expressed approximately as "some side effect may occur, but don't bet on it". Above I've described what I understand to be RESTful use of the POST method. Please tell me how that differs in the security dimension from the dreaded 'tunneled RPC'. Note that I'm interested only in the security dimension right now. I understand that tunneling GETs through POST diminishes the capability of the layered system, and I suppose tunneling DELETE or PUT may diminish something as well. But in none of these cases is security diminished. At least I can't think of a reasonable admin policy toward POST that would result in such a diminishment. That's why, for the time being, I regard claims about diminished security to be exaggerations based on overgeneralization. What I need to see are some specific cases of firewall configuration and method abuse to better understand. > I wouldn't say that it's underspecified at all. Why do you believe it > is? Request: POST /some/number 'square' Response: 204 No Content Request: GET /some/number Response: 200 OK 4 This example achieves the squaring of 2 in a way that is quite different from the more obvious interpretations of "state transfer". Can we please discuss whether the above is "RESTful" and if not, what would it take to make it so? I believe that by tweaking the example above, we can arrive at one which illuminates the distinction I see between rest-discuss and RFC 2616 on the intended semantics of POST. The specification of POST in RFC 2616 relies on the term 'subordinate' to characterize the relationship between the POST entity and the referenced resource. It then avoids comprehensive definition of 'subordinate' in favor of an enumeration. It leaves us to infer that the 'subordinate' relation is the 'part->composite' relation, because all the enumerated examples are such, but I'd like to hear others' interpretations on this. Then there's the circumstantial stuff, like the fact that otherwise intelligent human beings typically stumble all over the meanings of the HTTP methods (and it's all because of POST) on first encounter, the fact that supplementary models of "resource type" have to be developed to delineate the possible POST behaviors, the appearance of the word "intent" to describe the fleshing out of application semantics for POST, which seems unnecessary for all of the other HTTP methods, and a comment by someone who signs his emails with your signature to the effect that "POST is the catch-all mutator method". What I think is happening here is that we're still feeling the growing pains of HTTP/REST as it tries to be more than a document maintenance pattern and less than a 'protocol prostitute' (sorry, the alliteration made me do that!). This is super-long, so thanks in advance to all who made it to the end! Walden To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[I apologize for the previous null-reply!] >> We're creeping into rest-explore territory here. > That's why, for the time being, I regard claims about diminished > security to be exaggerations based on overgeneralization. What > I need to see are some specific cases of firewall configuration > and method abuse to better understand. I've been suspicious of this myself. I've heard two different issues with regards to RPC vs. REST security issues: 1. That a firewall can be configured to allow only the HTTP methods that the administrator considers safe for a user (e.g., no POSTs from certain users etc.) 2. RPC is more prone to issue like buffer-overrun problems that would require a more diligent security analysis. But it seems to me that similar problems could potentially exist with POSTed data no matter what style is used. >> I wouldn't say that it's underspecified at all. Why do you believe it >> is? > Having just read that part of the spec again, I don't, actually. But > that pushes me to a different conclusion: that the semantics of POST > are being misrepresented on this mail list to include careful craftings > of remote procedure calls in which the instructions have 'representations' > that pass the 'representational state' test (which is a null test), > and so appear to be 'state transfers' but are not. > I'll give an example > > Request: > PUT /some/number > 2 > > Response: > 201 Created > > Request: > GET /some/number > > Response: > 200 OK > 2 As for the squaring action, one possibility could be: Request: POST /squarer /some/number Response: 200 OK 4 I think it would be stretching the intended meaning of 'subordinate' to claim that the name of an action was a subordinate resource in the original POST.
> As for the squaring action, one possibility could be:
>
> Request:
> POST /squarer
> /some/number
>
> Response:
> 200 OK
> 4
>
> I think it would be stretching the intended meaning of
> 'subordinate' to claim
> that
> the name of an action was a subordinate resource in the original POST.
>
I'm not so much looking for a way to square numbers as I am trying
to illustrate a subtlty in the specification and its interpretations.
I'd say your example suffers from the same weakness because '/some/number'
is also not logically subordinate in the composite sense to a calculator,
('/squarer') while /squarer/complex (a squarer for complex numbers) might
be, but note the totally different meaning of POSTing that.
What I'd like to happen now is instead of folks proposing other
possibly RESTful ways to do integer squaring, have them tell me precicely
what is unRESTful in my example so I can evolve it to that point
of enlightenment. Or tell me that the example is already RESTful.
Thanks,
Walden
> I'm not so much looking for a way to square numbers as I am trying
> to illustrate a subtlty in the specification and its interpretations.
Sorry, I didn't mean to imply that you were only looking for such a thing...
> I'd say your example suffers from the same weakness because '/some/number'
> is also not logically subordinate in the composite sense to a calculator,
I don't think the subordinate should be thought of strictly in the
compositional
sense. While RFC2616 does explicitly mention such examples as "the posted
entity
is subordinate to that URI in the same way that a file is subordinate to a
directory
containing it," it also gives the example of using POST for "Providing a block
of data,
such as the result of submitting a form, to a data-handling process." Not all
POSTs will
result in another resource being created, even implicitly.
So I think my example is a better way of doing things since you are POSTing
the state
of a subordinate resource (or a reference to the resource in that particular
case.)
> ('/squarer') while /squarer/complex (a squarer for complex numbers) might
> be, but note the totally different meaning of POSTing that.
> What I'd like to happen now is instead of folks proposing other
> possibly RESTful ways to do integer squaring, have them tell me precicely
> what is unRESTful in my example so I can evolve it to that point
> of enlightenment.
In your original example, you are not posting a representation of a resource,
only
a name of an action.
On Tue, Aug 27, 2002 at 10:47:12AM -0400, Mathews, Walden wrote: > > We're creeping into rest-explore territory here. > > How so? Just that it's a bit of an advanced topic that REST newbies may not be interested in. It's not a bad thing. 8-) > My aim is to understand the claims that tunneling RPC > traffic through HTTP POST creates a security problem that doesn't > already exist with compliant uses of POST. A POST body will > contain a representation of something that is loosely characterized > as 'subordinate' to the referenced resource, which will invoke > some processing of some kind. That representation may be the > *record* of some desired action, and so will be interpreted on > the server as the action. The meaning of this exchange will > not be available to a firewall or other intermediary except at > the most general level. And what it "means" there can be > expressed approximately as "some side effect may occur, but > don't bet on it". Pretty much. > Above I've described what I understand to be RESTful use of > the POST method. Please tell me how that differs in the security > dimension from the dreaded 'tunneled RPC'. The key is to focus on the wire. Think about telnetting to port 80. At that very instant, a contract is in effect, and that contract and any messages conforming to it are visibile to all participants; you, any firewall you might be going through, the server, and any surrogates it might be using. If, using that contract, you could trick the system into providing you a richer contract, i.e. guaranteeing you things that were not guaranteed at time 0, and do this in a way that is not visible to intermediaries (i.e. not using HTTP's extension features), then that is a security problem (as well as a problem to other aspects of the system that require visibility, e.g. caching). Designing interfaces that cannot break themselves is *hard*. You're working against entropy. "Tunneled RPC"'s raison d'etre is to build arbitrary contracts over existing ones. So in addition to nullifying any safety in the existing contract, cheap method-creation is an easy way to guarantee that most contracts created with it will in turn be unsafe. > Note that I'm interested only in the security dimension right > now. I understand that tunneling GETs through POST diminishes > the capability of the layered system, and I suppose tunneling > DELETE or PUT may diminish something as well. But in none of these > cases is security diminished. At least I can't think of a > reasonable admin policy toward POST that would result in such > a diminishment. If GET - and only GET - were tunneled through POST, I agree about security probably not being diminished, because the augmented contract is no more capable than the existing one (though I'd have to verify that there wasn't any POST-specific race conditions, etc.. there). But an intermediary wouldn't know that, so there's still a management issue that the firewall admins wouldn't be comfortable with, I'm sure. > That's why, for the time being, I regard claims about diminished > security to be exaggerations based on overgeneralization. What > I need to see are some specific cases of firewall configuration > and method abuse to better understand. > > > I wouldn't say that it's underspecified at all. Why do you believe it > > is? > > Having just read that part of the spec again, I don't, actually. But > that pushes me to a different conclusion: that the semantics of POST > are being misrepresented on this mail list to include careful craftings > of remote procedure calls in which the instructions have 'representations' > that pass the 'representational state' test (which is a null test), > and so appear to be 'state transfers' but are not. > > I'll give an example > > Request: > PUT /some/number > 2 > > Response: > 201 Created > > Request: > GET /some/number > > Response: > 200 OK > 2 > > Request: > POST /some/number > 'square' > > Response: > 204 No Content > > Request: > GET /some/number > > Response: > 200 OK > 4 > > This example achieves the squaring of 2 in a way that is quite > different from the more obvious interpretations of "state > transfer". Can we please discuss whether the above is "RESTful" > and if not, what would it take to make it so? It's not RESTful, because 'square' is an instruction to be followed, not data to be submitted. In addition, this is a poor example because the client *expects* that squaring is done, which kind of begs the question as to why it can't do it itself and then PUT the result ... 8-O > I believe that > by tweaking the example above, we can arrive at one which > illuminates the distinction I see between rest-discuss and > RFC 2616 on the intended semantics of POST. > > > The specification of POST in RFC 2616 relies on the term 'subordinate' > to characterize the relationship between the POST entity and the > referenced resource. It then avoids comprehensive definition of > 'subordinate' in favor of an enumeration. It leaves us to infer that > the 'subordinate' relation is the 'part->composite' relation, because > all the enumerated examples are such, but I'd like to hear others' > interpretations on this. I think that "Part->Composite" is a tad more specific than HTTP suggests, but I might be picking nits. It would seem to exclude the posting of data to a form processor, for example, since the composite relationship only exists for the duration of the processing. It doesn't persist like a StatePreservingContainer. Pretty close though, but I prefer "accept as a subordinate" for describing the most generic form of containment as present in my RestRDF "Container". > Then there's the circumstantial stuff, like the fact that otherwise > intelligent human beings typically stumble all over the meanings of > the HTTP methods (and it's all because of POST) on first encounter, > the fact that supplementary models of "resource type" have to be developed > to delineate the possible POST behaviors, the appearance of the word > "intent" > to describe the fleshing out of application semantics for POST, which > seems unnecessary for all of the other HTTP methods, and a > comment by someone who signs his emails with your signature to the > effect that "POST is the catch-all mutator method". 8-) > What I think is happening here is that we're still feeling the > growing pains of HTTP/REST as it tries to be more than a document > maintenance pattern and less than a 'protocol prostitute' (sorry, > the alliteration made me do that!). No, that's a really good way of explaining the tension, but HTTP/REST *is* already a fixed thing (at least at any given point in time). It's only our view of it that we're adjusting by talking about it. > This is super-long, so thanks in advance to all who made it to the end! Phew! MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Mon, Aug 26, 2002 at 09:35:06PM -0400, Seairth Jacobs wrote: > Why not handle the shopping cart as it's own resource on the server? In How would I transfer representations of what I'm purchasing to it? > fact, if done correctly, I could even see having an HTTP server that was > dedicated and optimized to doing nothing but maintaining one or more site's > "shopping cart resource". I'm not sure how this would work exactly, but I > can vaguely see it working. You'd need some session info to do that. > As for the client program being capable of maintaining state, I can see > doing that sort of thing now (with a bit of client-side programming, mint > you). For instance, If you were at Amazon, each of the items you view is > represented by an identifier (it's URL). Suppose you could right-click on > the page and select the "add to amazon.com cart". This would cause the > current URL you were at to be stored locally in a "cart" that was specific > to amazon (though I suppose it could be more generic too). The thing about keeping the URI around, rather than the data, is that what's "behind" the URI might change. e.g. the model might be upgraded between the time you decide you want it just the old model), and the time you checkout. You base your purchasing decision on the *data* not the URI. So you should keep hold of that. > Now, suppose you > have found everything you wanted to buy. You go up to your brower's menu > (or taskbar or whatever) and bring up the amazon.com shopping cart ( which > basically contains nothing but URLs). You then click on the "buy" button. > This prompts your browser to submit (via POST) all of the URLs to an > amazon.com location (not sure how that would be know, but let's assume it > is) and amazon would now create the check-out resource that contains the > items you are buying... then it's business as usual. Pretty close, except for s/URL/representation > Now, I know that it would be possible to add this functionality to IE6. > Obviously, it would also require the amazon.com's of the world to provide > their part of the functionality. But I think it would be possible. > Further, it would be possible to merge this concept with the one above > (dedicated "shopping cart" server), if wanted. This would potentially allow > someone to access their shopping cart from any browser later on, as well as > some other interesting benefits I can think of (such as the ability to share > shopping carts with friends regardless of where you shop at). You can still save your shopping cart either way - just drag and drop on the "hold cart" (or whatever) button in the page. > > But you could imagine browsing through a web site, dragging off > > products you want and dropping them in a local folder, then at some > > point dragging that folder and dropping it onto the "checkout" > > symbol within the web page. No session required. > > Oh yeah. That's what I was saying too. :) Shoulda read the whole post > first... Oops, me too. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> > Above I've described what I understand to be RESTful use of > > the POST method. Please tell me how that differs in the security > > dimension from the dreaded 'tunneled RPC'. > > The key is to focus on the wire. Think about telnetting to port 80. > At that very instant, a contract is in effect, and that contract and > any messages conforming to it are visibile to all participants; you, > any firewall you might be going through, the server, and any > surrogates > it might be using. > > If, using that contract, you could trick the system into providing > you a richer contract, i.e. guaranteeing you things that were not > guaranteed at time 0, and do this in a way that is not visible to > intermediaries (i.e. not using HTTP's extension features), then that > is a security problem (as well as a problem to other aspects of the > system that require visibility, e.g. caching). Designing interfaces > that cannot break themselves is *hard*. You're working against > entropy. > > "Tunneled RPC"'s raison d'etre is to build arbitrary contracts over > existing ones. So in addition to nullifying any safety in the > existing contract, cheap method-creation is an easy way to guarantee > that most contracts created with it will in turn be unsafe. As I see it, there are two problems with these arguments, and both stem from their generality, and would be cleared up by a real life story, if anyone can contribute one. The first problem is distinguishing this breakdown in "safety" from the common business case in which a sales pitch lures you into making a bad purchase. On whom does the responsibility for avoiding that lie? The second problem is distinguishing this breakdown in "safety" from the case in which you use HTTP POST to send an arbitrary "block of data ... to a handling process". Or should we say a "block of arguments to a remote handling procedure"? [example elided for brevity] > > This example achieves the squaring of 2 in a way that is quite > > different from the more obvious interpretations of "state > > transfer". Can we please discuss whether the above is "RESTful" > > and if not, what would it take to make it so? > > It's not RESTful, because 'square' is an instruction to be > followed, not > data to be submitted. In addition, this is a poor example because the > client *expects* that squaring is done, which kind of begs > the question > as to why it can't do it itself and then PUT the result ... 8-O I'm glad to hear it's not RESTful. That's a start. (The reason the client doesn't square is because it doesn't know how to, kind of like why you don't do your own dental work, assuming you don't, but none of that is relevant now.) Okay, can you make it restful by changing the way you think about it? For instance, can we call it a *record* of an action, or perhaps a short 'action document', or a 'delta representation' of future resource state, or any other 'trick' that gets us beyond this hitch? What if we argue that it came straight from an HTTP form submission? Please anticipate where I'm going with the above and help me find the boundary. > I think that "Part->Composite" is a tad more specific than HTTP > suggests, but I might be picking nits. It would seem to exclude the > posting of data to a form processor, for example, since the > composite relationship only exists for the duration of the processing. > It doesn't persist like a StatePreservingContainer. Pretty close > though, but I prefer "accept as a subordinate" for describing the most > generic form of containment as present in my RestRDF "Container". Well, I went back and read that section yet again (whew!), and while it does list as a goal the processing of form data, all the examples offered to clarify 'subordinate' are clearly container (part/assembly) examples. I'd say it looks inconsistent, with the 'forms' stuff the odd-man-out. > No, that's a really good way of explaining the tension, but HTTP/REST > *is* already a fixed thing (at least at any given point in > time). It's > only our view of it that we're adjusting by talking about it. I think views can only adjust so far. To me, POST is broken like a too-small pelvis trying to give birth to a cranial giant. (Ouch. I've got to stop ending these messages so vividly.) In gratitude, Walden
[snip] > > > This example achieves the squaring of 2 in a way that is quite > > > different from the more obvious interpretations of "state > > > transfer". Can we please discuss whether the above is "RESTful" > > > and if not, what would it take to make it so? > > > > It's not RESTful, because 'square' is an instruction to be > > followed, not data to be submitted. In addition, this is a poor > > example because the client *expects* that squaring is done, which > > kind of begs the question as to why it can't do it itself and then > > PUT the result ... 8-O > > I'm glad to hear it's not RESTful. That's a start. (The reason > the client doesn't square is because it doesn't know how to, kind of > like why you don't do your own dental work, assuming you don't, but > none of that is relevant now.) > > Okay, can you make it restful by changing the way you think about > it? For instance, can we call it a *record* of an action, or perhaps > a short 'action document', or a 'delta representation' of future > resource state, or any other 'trick' that gets us beyond this > hitch? What if we argue that it came straight from an HTTP form > submission? > > Please anticipate where I'm going with the above and help me find > the boundary. [snip] Ahah...I was wondering if I was missing a very subtle semantic point in your example, or if I was correct in thinking that you were putting a remote procedure call into a POST request. It looks like the later is true, because no matter how you slice it, you're effectively doing a square(x, y) across a network, which is good for SOAP-RPC, but goes against the RESTful style. What *would* be more RESTful? An abstract approach might be to transfer a representation in a POST request that sends a 201 (Created) response including a 'Location' response-header field that specifies the subordinate's location. The recent shopping basket (in the client state posts) example is a good place to start. In other words, once you're ready to check out, you might POST the basket representation to an order taking resource. This might cause the server to create a subordinate of a container resource, and hand you a URI in the 201 response that you can then use to do subsequent GET/PUT/POST/DELETE requests. Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
On Tue, Aug 27, 2002 at 04:46:39PM -0400, Mathews, Walden wrote: > As I see it, there are two problems with these arguments, and both > stem from their generality, and would be cleared up by a real life > story, if anyone can contribute one. > > The first problem is distinguishing this breakdown in "safety" from > the common business case in which a sales pitch lures you into making > a bad purchase. On whom does the responsibility for avoiding that > lie? That's protecting the client. I'm talking about protecting the server. > The second problem is distinguishing this breakdown in "safety" from > the case in which you use HTTP POST to send an arbitrary "block of data ... > to a handling process". Or should we say a "block of arguments to a > remote handling procedure"? Hmm. I'm not sure that there's any distinguishing to be done in that case. > [example elided for brevity] > > > > This example achieves the squaring of 2 in a way that is quite > > > different from the more obvious interpretations of "state > > > transfer". Can we please discuss whether the above is "RESTful" > > > and if not, what would it take to make it so? > > > > It's not RESTful, because 'square' is an instruction to be > > followed, not > > data to be submitted. In addition, this is a poor example because the > > client *expects* that squaring is done, which kind of begs > > the question > > as to why it can't do it itself and then PUT the result ... 8-O > > I'm glad to hear it's not RESTful. That's a start. (The reason > the client doesn't square is because it doesn't know how to, kind of > like why you don't do your own dental work, assuming you don't, but > none of that is relevant now.) > > Okay, can you make it restful by changing the way you think about > it? For instance, can we call it a *record* of an action, or perhaps > a short 'action document', or a 'delta representation' of future > resource state, or any other 'trick' that gets us beyond this > hitch? What if we argue that it came straight from an HTTP form > submission? > > Please anticipate where I'm going with the above and help me find > the boundary. I'm not sure where you're going with it, sorry. But with a clean slate, I'd implement this using GET to return the squared value to the client, i.e. GET http://me.example.org/first-number which returns something like; 5 <a rel="http://math.example.org/squared" href="http://me.example.org/first-number?square=yes>squared</a> such that following the link identifies that you're traversing from a number to its square. Then I'd do a GET on that other URI, and then PUT the value back to /first-number - I think that's what your example was doing, I'm too lazy to go back and check. 8-) > > I think that "Part->Composite" is a tad more specific than HTTP > > suggests, but I might be picking nits. It would seem to exclude the > > posting of data to a form processor, for example, since the > > composite relationship only exists for the duration of the processing. > > It doesn't persist like a StatePreservingContainer. Pretty close > > though, but I prefer "accept as a subordinate" for describing the most > > generic form of containment as present in my RestRDF "Container". > > Well, I went back and read that section yet again (whew!), and while it > does list as a goal the processing of form data, all the examples offered > to clarify 'subordinate' are clearly container (part/assembly) examples. > I'd say it looks inconsistent, with the 'forms' stuff the odd-man-out. Perhaps, but that "block of data" blurb is the most oft referenced part of the definition of POST that people use to defend tunneling, ala; http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt So I think it's useful that the examples are part/assembly, even if the IPP guys chose to ignore them. 8-) > I think views can only adjust so far. To me, POST is broken like > a too-small pelvis trying to give birth to a cranial giant. (Ouch. > I've got to stop ending these messages so vividly.) My eyes, me eyes! 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
So as the kids were running around on the playground this evening, a thought
occurred to me concerning the recent discussions on state management and
user authentication. To start, suppose the following URL:
example.com/doc.php/12345
This is a simple URL that returns a representation of a resource (in this
case a document with a public id of "12345"). Now, as I have mentioned,
this resource can be viewed either anonymously (by anyone) or after being
authenticated. When it becomes necessary to persist the authentication, we
all agreed (I think) that http authentication was the way to go. We also
agree (I think) that the following method was a "bad thing",
RESTfully-speaking:
example.com/doc.php/12345?sessionid=67890
However, it occurred to me that the problem with the above URL wasn't the
use of a query string, but what was *in* the query string. Suppose instead
that I used the following URL once someone has been authenticated:
example.com/doc.php/12345?userid=seairth
Now, the URL matches the representation of the resource being returned! To
me, this URL is cacheable. I can throw this thing in my favorites. I can
even pass it to a friend. Of course, when the server receives the request,
it is going to look for authentication information a challenge it, but that
is okay!
Now, how is this different from the "sessionid" query string? I can think
of a couple of things:
1) The returned representation is related to user, not the session. The
session will change, but the user will not. However, a different user will
get back a different representation.
2) With the second URL, there is now a direct corollary between the
authentication information and the identifier, which is not the case with a
sessionid. The sessionid is an added layer of indirection.
So, why use the "userid" concept? Why not just leave it off altogether
(i.e. just use the first URL above)? Because you end up with a URL that
returns different representations based on metadata in the http header (the
Authorization header). For instance, in my system, suppose you were to
compare an anonymous user, an authenticated user, and an authenticated user
that had "reviewer" status. Here are the different representations
(simplified) you would get back depending on who you were:
Anonymous:
* You can view document.
* You can see current vote results, but do not what
your current vote is.
* You can see the list of subdocuments that have passed
peer review.
Authenticated:
* You can view document.
* You can see current vote results, as well as what your
current vote is (if you have voted).
* You can see the list of subdocuments that have passed
peer review.
Authenticated with "reviewer" status:
* You can view document.
* You can see current vote results, as well as what your
current vote is (if you have voted).
* You can see the list of subdocuments that have passed
peer review, as well as all subdocuments that are
waiting to be peer reviewed.
Now, with the basic URL, you must rely on the authentication information to
determine which of the above representations to return. With the URL
containing the userid, the authentication information only verifies that the
request is allowed. The URL itself actually identifies the representation
to return.
Now, that sounds RESTful to me.
Thoughts?
---
Seairth Jacobs
seairth@...
I don't know if this is getting off-topic or not (I'm losing track of what the thread is about, sorry), but why not just do the following? Request: GET /squaring-resource?4 Response: 200 OK 16 The "squaring-resource" above is the (theoretically) open set of all possible squares. We are just querying a subset of the resource. Or is this about avoiding RPC? Or is this all about how to deal with containers and such? I'm just not sure any more.... :~\ --- Seairth Jacobs seairth@...
On Tue, Aug 27, 2002 at 10:15:01PM -0400, Seairth Jacobs wrote: > Thoughts? Pretty good, but consider the following response headers on a GET to http://example.com/doc.php/12345; Vary: Authorization Content-Location: http://example.org/doc.php/12345?userid=seairth In theory, this allows you to maintain the principle URI for the document, while not confusing caches about returning somebody else's authorized representation, and letting the client know where it can get that exact info later. In practice, I'm not sure how well it works, I've never tried it. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
It seems to me like there's already a 'standard' in place for searching
a URI. The index.htm and default.htm files are traditionally what are
returned to a browser when a requested URI is not 'fine-grained' enough:
www.somedomain.com/images
If there is no index.htm file there, I get a list of the files in that
directory. Problem is, if there's 100,000 files there, you're going to
have to wait a while to get a list of them all.
In a RESTful world, with a little more smarts going on behind the
scenes, we should be able to ask a URI what we're allowed to do:
GET / HTTP/1.0
might return
<resources>
<resource>/users</resource>
<resource>/groups</resource>
</resources>
Ah, there is a /users, and a /groups resource I am allowed to 'use'.
For more information, I can do
GET /users HTTP/1.0
My intention is to look up a user with a username of 'xxx', but I don't
yet know how to do this. GETting /users helpfully tells me this:
<allowed-operations>
<operation name="search">
<http-method>GET</http-method>
<required-subcontext>
<name>username</name>
<subcontext-value-pattern>[a-z][A-Z]</subcontext-value-pattern>
<subcontext-value-pattern>regexp</subcontext-value-pattern>
</required-subcontext>
<use-uri>www.somedomain.com/users/username</use-uri>
</operation>
<operation name="new">
<http-method>PUT</http-method>
<required-parameter>
<name>username</name>
<parameter-value-pattern>[a-z][A-Z]</parameter-value-pattern>
</required-parameter>
<required-parameter>
<name>password</name>
<parameter-value-pattern>[a-z][A-Z][0-9][!@%-_.]</parameter-value-patter
n>
</required-parameter>
</operation>
</allowed-operations>
Now, both machines and people (with help from an XSLT stylesheet, if
needs be) can see that I can search /users by providing a 'username'
parameter (subcontext), or create a new user by providing a username and
password. My RESTful application defines the resource associated with
the user in question as /users/username. I can use a regular expression
for the /username bit to smarten up my queries. One may envisage even
providing a fill-in-the-blanks SQL string in a
'subcontext-value-pattern' element (all security issues aside).
Essentially, a search is a GET, so we should use it. However, without
knowing how to perform the right kind of GET on a resource, we're stuck
(how does the client know to use the 'username' parameter in a query
string?). This, I think, is the difference between a 'document'
resource (ie a user's details), and a 'processor' resource that performs
operations - you don't need to know anything more about a document
except where to get it. With a processor, you need to know what it
does, so it should tell you when you invoke its base URI. This
description of a processor's operations is essentially RDF (though I
haven't used the syntax) as I understand it.
- Michael
----- Original Message -----
From: inthedarkplace
To: rest-discuss@yahoogroups.com
Sent: Friday, August 23, 2002 10:39 AM
Subject: [rest-discuss] Searching Containers
Guys,
I'm curious; has anybody established any best practices for
performing arbitrary searching of collection resources? Eg, say I
have the collection /users and I want to find a user with the
username 'kd'. What's the most RESTful and elegant way to do this?
It seems like there's basically three options.
1) Have the user POST an XML-document describing the query to the
collection
Pros: Logically intuitive. If I have a collection, I should ask it to
execute queries.
Cons: Because searching is not a mutator-method (ie it doesn't change
the state of the users collection) it doesn't seem like POST is the
best method. But neither do GET, PUT, or DELETE make much sense
unless I do a GET with a body which I've been told is in poor taste.
This also makes it very difficult to write the collection code
because now the collection must parse the XML document, figure out
which operation is happening (either user creation or searching) and
then essentially reparse the algorithm.
2) Have the user do a GET on the users collection, passing the search
query in through the query string. eg /users?username='xxx'
Pros: Intuitive. This is what for the query string is for, I think.
It also allows the user to bookmark searches which might be
potentially very useful for working with sets of users.
Cons: Severely limits the expressiveness of queries. Also puts more
code in the users code, but this isn't a huge issue.
3) Create a special query resource located at /users/query. This
query resource can have simply queries passed in through the query
string or more complex queries passed in through a POST.
Pros: This seems to the most elegant. It also makes sense because
POSTing to a query resource can be seen as creating a query.
Potentially, this query could even be assigned a URI. Because queries
can be passed in through GET or POST it allows for arbitrarily
expressive queries.
Cons: Potentially, this could lead to resource explosion because
every container resource now needs an additional 'query' resource.
This might not be such a good thing.
Right now I'm leaning more towards number 3. But I'm curious, what
other solutions have people come up with?
- inthedarkplace
On Tue, Aug 27, 2002 at 10:25:45PM -0400, Seairth Jacobs wrote: > I don't know if this is getting off-topic or not (I'm losing track of what > the thread is about, sorry), but why not just do the following? > > Request: > GET /squaring-resource?4 > > Response: > 200 OK > > 16 > > The "squaring-resource" above is the (theoretically) open set of all > possible squares. We are just querying a subset of the resource. If you squint a little, you'll see that what I just suggested was almost exactly what you're doing here, only that mine treated the URIs as opaque by virtue of including the relationship between the two number resources in the response. > Or is this about avoiding RPC? Or is this all about how to deal with > containers and such? I'm just not sure any more.... :~\ Yes and yes; generic interfaces, and hypermedia as the engine of application state. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Hmm... I think I understand. I certainly understand the use of the "Vary: Authorization" bit. This would keep someone from sitting down at a browser that had cached a restricted document and bringing it back up from cache (assuming that the http authentication cache had been cleared). And I see the value of using "Content-Location" under certain circumstances. If I understand RFC2616 correctly, this header allows the caching mechanism to use this URI instead of the request URI. However, I am thinking that this would not work for my case. In my case, a person could point a browser to example.com/doc.php/12345 and get back one representation. However, this person could also view a different representation for the same resource that is tailored for him personally. In order to provide that second representation, the user must be authenticated. Using the same URL for both representations, I have not figured out a clean way to let the server know that the person wants to see the second representation instead of the first one. And the server must be told this somehow so that it can issue the 401 challenge response. By using the query string, I can allow a very simple process on the page. When the person receives the anonymous representation, there is a textbox in the upper right-hand corner to receive the person's userid. When any action is taken (including "reloading" the page by clicking on the "login" button/link), this value is used to augment the request-URI (either with javascript or using a form where method=GET). In turn, the server understands the submitted URI as a restricted resource and checks for an Authorization header (again, to verify the URI only). Not finding one, it issues a 401 response. Once the user has entered the authentication information and successfuly resubmits the request, the server returns the new representation. Now, instead of a textbox in the corner, there would be a "logout" button/link. Truthfully though, this button is a fake since all it really does is takes the user back to the anonymous representation (I wish there was some way to quietly stop the Authorization header from being sent as well, but I haven't figured that one out yet). I hope this all makes sense. It does in my head, but I don't know if I am conveying it very well... Now, the issue of caching is a "whole other ball of wax", as they say. Ideally, I would like to turn caching off altogether, but I realize that this puts additional strain on the server. I think I will start be turning it off until I understand the usage patterns better and there is enough traffic to affect bandwidth/performance (oh, and once I actually understand how to precisely control caching; any suggested tutorials focusing on dynamic content?). Regardless, I think I will include the Vary header "just in case". And later, if/when I do allow caching, at least that mechanism will already be in place. --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Seairth Jacobs" <seairth@...> Cc: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Tuesday, August 27, 2002 10:30 PM Subject: Re: [rest-discuss] more on authentication > On Tue, Aug 27, 2002 at 10:15:01PM -0400, Seairth Jacobs wrote: > > Thoughts? > > Pretty good, but consider the following response headers on a GET to > http://example.com/doc.php/12345; > > Vary: Authorization > Content-Location: http://example.org/doc.php/12345?userid=seairth > > In theory, this allows you to maintain the principle URI for the > document, while not confusing caches about returning somebody else's > authorized representation, and letting the client know where it can get > that exact info later. In practice, I'm not sure how well it works, > I've never tried it. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
The only difference between the two solutions is that mine doesn't provide for starting with some arbitrary number and squaring it; you bootstrap into it via a hypertext link, not a number. If that were a requirement, then I would provide a form on a GET to /square that would construct the URI given an integer. That gives you the best of both worlds; after you've entered "3" and got back "9", you have the choice of going to the form to enter "9" again, or just clicking on the link to "81" - or on the "rev" link (or on Google's "backward links" button) to get back to 3; yes, mine does square roots too. 8-) Seairth, see; http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3.1 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Tuesday, August 27, 2002 10:26 PM > To: rest-discuss > Subject: [rest-discuss] squaring (was Re:HTTP and safety) > > > I don't know if this is getting off-topic or not (I'm losing > track of what > the thread is about, sorry), but why not just do the following? It's off topic from my perspective, but if it's useful for you, then go for it. I have no primary interest in "stupid math hypertext tricks", only in constructing minimal models to discriminate the properties of REST. My answer to "why not just do the following?" is because it sheds no light on RESTful use of POST. > > Request: > GET /squaring-resource?4 > > Response: > 200 OK > > 16 > > The "squaring-resource" above is the (theoretically) open set of all > possible squares. We are just querying a subset of the resource. Yes, this is an interesting view of resources that renders them looking more like state space than processes. To be more precise, the resource you have above is the 'square' relation with no constraint on its domain, and the parameter in the request is the domain constraint for the duration of the query. This raises an interesting question for me: Are parameters to be considered part of the URI proper in all contexts? Certainly for caching, the "?4" is an important part of the URI. But is the requirement of URI opaqueness to clients, extending even to parameter lists, perhaps too strong? On the one hand, 'no' because only resources are authoritative as to what are meaningful parameters. On the other hand, 'yes' because in the case where a resource is in effect a relation (like your example above), it's not unthinkable that the null set (No Content) be returned when the relation is a partial function and there is no mapping for the given parameter. > Or is this about avoiding RPC? Or is this all about how to deal with > containers and such? I'm just not sure any more.... :~\ Again, in case it's not clear above, it's about *discriminating* RPC from REST, if indeed they are partitioned (I don't think they are). If literal container semantics and only container semantics were allowed for POST, then I believe I would have no issues. I also believe, however, that a bunch of 'RESTful' implementations would go down in flames, so to speak. But not to any sort of final RESTing place, alas. Walden
On Wed, Aug 28, 2002 at 09:20:56AM -0500, Jeff Bone wrote: > But is this as useful as simply providing a resource interface and some > instructions about how to process it? I think my revised solution does that ... > How does a program (rather than > a human) use the form? I started working on integrating this with RestRDF, but never got it done. In the meantime, use WSDL or WRDL. > Does the form POST, or...? GET > Can the squares > themselves --- resources, certainly --- be obtained by a GET? Yep. Let me outline a scenario that starts me wanting to find out the square of 4. I'll use new URIs for clarity, plus generalize it a little to show how it's not specific to squaring; GET on http://example.org/integers returns a GET form with a single parameter "number" I enter "4", hit submit, and get some information on the number four from the URI http://example.org/integers?number=4, perhaps something like; "Four" (4). See it; <a rel="http://math.example.org/square" href="/integers?number=16">squared</a>, and <a rel="http://math.example.org/square-root" href="/integers?number=2">square rooted</a> This is getting away from Walden's original example, since the URIs identify the numbers, not some other thing that happens to have the value. But I wanted to focus on explaining how links could be used, and this was the easiest way. BTW, ignore the square root bit before. "rev" doesn't work like that. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > > You base > your purchasing decision on the *data* not the URI. So you > should keep hold of that. Mark, Is that the same as saying you base your purchasing decision on the representation, not the URI? regards, Bill de hra .. Propylon www.propylon.com
On Wed, Aug 28, 2002 at 06:15:50PM +0100, Bill de h�ra wrote: > Mark, > > Is that the same as saying you base your purchasing decision on the > representation, not the URI? Right. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> Again, in case it's not clear above, it's about > *discriminating* RPC from REST, if indeed they > are partitioned (I don't think they are). It seems to me that the difference breaks down along the lines of how POST can be used: 1. To request the creation of a subordinate resource. 2. As a logical PUT (or DELETE). There was a thread earlier this month about whether or not it is okay to use POST to perform partial resource updates. I recall that it was suggested that it is purer (and sometimes necessary) to update the entire resource using a PUT, but performance requirements, etc., may preclude doing so. In this case, using POST is okay. 3. To request a resource to perform some action upon some logically subordinate data. 4. To tunnel RPC over HTTP to make arbitrary calls. So, the question is: is there a meaningful difference between 3 and 4? I think there is. RPC generally POSTs to some generic URL; essentially, the id of the resource being acted upon becomes the first parameter in the procedure call. With REST you have at least moved the first parameter out to a real URL. Beyond that though, when confronted with an problem where some RPC-ish approach may be considered, the recourse model can be refactored to make it more RESTful. For a simplified example such as squaring numbers, using the GET/PUT semantics is the way to go, but for a more general case were some arbitrary level of backend processing needs to occur, a POST operation would often need to be employed. This would seem to hold especially when multiple resources need to be updated in an atomic way. For example, how do you handle transferring money from a savings account to a checking account? Sam Ruby has an article (that I believe someone here had referenced before) where he makes the statement: "It is the expression of higher level operations (particularly ones that perform non-atomic updates) that SOAP's value proposition becomes apparent. Sometimes, one truly wants to have an atomic "transfer funds from savings to checking" transaction instead of simply a series of discrete GET and PUT's." [http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html] Surely you can't just GET the account representations, update the balance in each and then PUT them back one at a time. I understand the sentiment behind Ruby's statement, but I don't agree that REST precludes doing atomic operations, so long as POST semantics are employed. For example, you could request the creation of a "transfer" resource POST /user/joe/accounts/transfers <transfer from-account="savings/1234" to-account="checking/2345">50</transfer> on successful transfer: 201 Created Location: /user/joe/accounts/transfers/00001 if insufficient funds: 400 Bad Request A GET against /transfers could return a transfer history, etc. If you did something like POST the to-account number and amount to the from-acount resource: POST /user/joe/savings/transfer <transfer to-account="2345">50</transfer> one could argue that this is RESTful since you are asking the account resource to work with logically subordinate data, but using POST in this way does start to "smell" like RPC. Thanks, - Jeff
>> The first problem is distinguishing this breakdown in "safety" from >> the common business case in which a sales pitch lures you into making >> a bad purchase. On whom does the responsibility for avoiding that >> lie? >That's protecting the client. I'm talking about protecting the >server. I was too. So how do you distinguish? >> The second problem is distinguishing this breakdown in "safety" from >> the case in which you use HTTP POST to send an arbitrary "block of data ... >> to a handling process". Or should we say a "block of arguments to a >> remote handling procedure"? >Hmm. I'm not sure that there's any distinguishing to be done in that >case. Well, I guess I'm arguing that POST is a contract that will have to be extended in a lot of cases in order to get the job done, and that if contract extension is regarded as risky, well then the camel's nose is under the tent. I noticed in a previous mail you asserted that POST cannot be extended in a way that compromises intermediary security policy. I don't know much about that, and an example of a contract extension would be great. For that matter, any example of compromised security due to tunneling would be great, but I notice my invitations for stories going unanswered. Probably too much effort... Anyway, one thing I think I've figured out is that while I'm visualizing a security setup in which the server has a lot of control (arguably enough, if it chooses to exploit it), you are probably looking at security as a (textbook) layered concept, and your concern is that an outer layer not be dismantled. Correct me if I'm wrong on that. >I'm not sure where you're going with it, sorry. No doubt my fault. [We were talking about my 'square' example, in which I send 'square' as a command in a POST body, and you find to be UnRestful. I was then proposing a number of different strategies for 'nounifying' the command, in order to try to discover a boundary, if there exists one, between commands and command surrogates in the body, such that a Restless example becomes a Restful one.] In a recent message, Jeff Winters gives an example in which a <transfer .../> is posted. The transfer is a document that contains the parameters for the transfer, but it's also due to become the record of the action. How does that rate on your scale? >Perhaps, but that "block of data" blurb is the most oft referenced >part of the definition of POST that people use to defend tunneling, >ala; >http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt >So I think it's useful that the examples are part/assembly, even if >the IPP guys chose to ignore them. 8-) I wonder what the harm would be from removing that bullet from 2616, and I've often pondered its strange relation to the other bullets, because it appears to be about a half a layer away in its semantics. You can achieve all the other goals by posting form data to a data-consuming process, can't you. But as far as tunneling goes, now I'm not so sure that clause is the tunnel I thought it was before. As long as what's being posted is 'data' to the application and not 'control', then visibility is left intact, isn't it? If visibility of actions is important, then why is it bad to put an action in the body of the HTTP message but okay to hide them behind 'processor' URIs? Especially when the URIs are going to be opaque in meaning to all but the server (i.e., intermediaries won't know what they mean either). Is this okay simply because you can annotate a resource with RDF, and thereby make the resource's behavior open to inquiring minds? >My eyes, me eyes! 8-) Yes, what about URIs? (-8 Walden
On Thu, Aug 29, 2002 at 12:04:41AM -0400, Walden Mathews wrote: > >That's protecting the client. I'm talking about protecting the > >server. > > I was too. So how do you distinguish? Both sides can log all messages that were part of that transaction and if needed, use them to defend their position in a court of law. So there's existing protection from the sort of stuff you're asking about (fraud, etc..). The application protocol contract provides a framework to enable the exchange of those messages to occur in the first place, without a pre-existing trust relationship. That didn't exactly answer your question above, but hopefully answers the previous one. > >Hmm. I'm not sure that there's any distinguishing to be done in that > >case. > > Well, I guess I'm arguing that POST is a contract that will have to be > extended in a lot of cases in order to get the job done, and that if > contract > extension is regarded as risky, well then the camel's nose is under the > tent. I noticed in a previous mail you asserted that POST cannot be > extended in a way that compromises intermediary security policy. I don't > know much about that, and an example of a contract extension would > be great. For that matter, any example of compromised security due > to tunneling would be great, but I notice my invitations for stories > going unanswered. Probably too much effort... Well, a good example of tunneling would be IPP-over-HTTP. The application contract in effect there is IPP, not HTTP, but a firewall not able to detect tunneling will think that it is HTTP. IPP is standardized, which is good - so people have looked at it and thought hard about ways in which it can be used to break itself. But the vast majority of tunnelling has not benefitted from such study. And indeed, the use of RPC whose existence is to promote billions of application protocols, rather than the 10 or so we use now, is just dangerous. > Anyway, one thing I think I've figured out is that while I'm visualizing > a security setup in which the server has a lot of control (arguably enough, > if it chooses to exploit it), you are probably looking at security > as a (textbook) layered concept, and your concern is that an outer layer not > be > dismantled. Correct me if I'm wrong on that. The characterization of my position sounds about right (assuming "outer" is where I think it is 8-). But I'm not sure about your position. > >I'm not sure where you're going with it, sorry. > > No doubt my fault. [We were talking about my 'square' example, > in which I send 'square' as a command in a POST body, and you find > to be UnRestful. I was then proposing a number of different strategies > for 'nounifying' the command, in order to try to discover a boundary, > if there exists one, between commands and command surrogates > in the body, such that a Restless example becomes a Restful one.] > > In a recent message, Jeff Winters gives an example in which a > <transfer .../> is posted. The transfer is a document that contains > the parameters for the transfer, but it's also due to become the > record of the action. How does that rate on your scale? I don't recall the example, but if its intent is to request specific behaviour from the server, then it's low on my scale. > >Perhaps, but that "block of data" blurb is the most oft referenced > >part of the definition of POST that people use to defend tunneling, > >ala; > > >http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt > > >So I think it's useful that the examples are part/assembly, even if > >the IPP guys chose to ignore them. 8-) > > I wonder what the harm would be from removing that bullet from 2616, > and I've often pondered its strange relation to the other bullets, because > it appears to be about a half a layer away in its semantics. You can I suggested a replacement to the HTTP WG, but Roy likes it so it stays. > achieve all the other goals by posting form data to a data-consuming > process, can't you. Roy has a slightly more specific definition of "posting form data" than I do. But yes, I see that as the most general description with the others being special cases. > But as far as tunneling goes, now I'm not so sure that clause is the > tunnel I thought it was before. As long as what's being posted is 'data' > to the application and not 'control', then visibility is left intact, isn't > it? Yes. > If visibility of actions is important, then why is it bad to put an action > in the body of the HTTP message but okay to hide them behind 'processor' > URIs? Especially when the URIs are going to be opaque in meaning to > all but the server (i.e., intermediaries won't know what they mean either). Right, that's the point. Any action that might be taken is only understood to be an action by the server. To the client, it's just an identifier like any other. > Is this okay simply because you can annotate a resource with RDF, > and thereby make the resource's behavior open to inquiring minds? Hmm, no, I don't think so, if I understand what you mean. It's just because the URI is opaque, and therefore invoking GET on it means GET to the client. Invoking "buyShoes" over POST means "buyShoes" to the invoker. > > >My eyes, me eyes! 8-) > > Yes, what about URIs? (-8 <groan/> MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > Both sides can log all messages that were part of that transaction and > if needed, use them to defend their position in a court of law. So > there's existing protection from the sort of stuff you're asking about > (fraud, etc..). This is an important point for business. But are you taking full advantage of REST when you think about it? Business exchanges are conversations. If you think of each message as a speech act, probably related to other speech acts in the same conversation, then each speech act is an important resource deserving a URI. If you combine: * state-alignment transactions so that each party agrees on each important business milestone, e.g. commitment and fulfillment of commitment * business rules that are also published with URIs * digital signatures * canonical representations of the whole ball of wax - then you got something that you could take into court, but you probably won't need to. -Bob Haugen P.S. I think a lot of the current discussion focuses on "how to do RPC in REST" rather than "use cases for which REST is a clear advantage".
Jeff - I'm forwarding this to rest-discuss. My message to you last night was composed in the yahoo form, and I didn't know if it would automatically cc: it to the group. It didn't. 8-( -- Walden > -----Original Message----- > From: Jeffrey Winter [mailto:j.winter@...] > Sent: Thursday, August 29, 2002 11:29 AM > To: Mathews, Walden > Subject: Re: squaring (was Re:HTTP and safety) > > > > I thought the RPC "smell" came from embedding actions in > the request > > body. Do your examples do that? I guess the answer depends on > > whether <transfer> is an action or an artifact, but if the latter > > then it's pretty clearly an artifact of an action. > > Because of the context of the issue - that two different resources > need to be updated in an atomic operation - the operation > itself is "meaningful", i.e., has internal structure and possible > state, and *could* be given a URL. If there was no need for the > operation to be atomic, you could just do two GETs followed by two > PUTs. So I think this elevates it to being more than just some > action or tricky way of dressing up an artifact of the action to > hide its otherwise purely operational nature. > > If there is a better way of handling this I'd also be very interested > in seeing how to do it as it would provide more insight into REST. > > > What if my application really does not care about keeping > records of > > transfers, so there's no requirement to store transfer records and > > therefore no concept of subordinate resource? In other words, > > there's just the act of transferring in real time. Does > that change > > the "smell" of the examples above? Would you change your design of > > the application interface in light of that requirement > clarification? > > I wouldn't. Again, given the context, I still think my example would > make sense, but you don't necessarily need to create an actual > resource and give it a URI. > > At the risk of again losing sight of the root issue though the > introduction of yet another example, I can see this as analogous > to a /bulliten-board resource where you don't necessarily need to > provide URLs for each posted document. In that case a posted document > is very clearly a subordinate resource, but in this specific > context, I see the transaction as being a real resource too. > > > I'm looking for boundary examples for RESTfulness, i.e. > hard cases to > > judge, if there is such a thing. > > Me too. > > - Jeff > > > >
Terrence, First off, I agree with you. I should say that I was most definitely *not* trying to offer a new definition of POST; I was basically trying to catalogue the uses of POST that have been brought up in order to try to bring into relief the precise issue that Walden was trying to raise. Which I think boils down to: if RPC is bad because it's misusing POST to send, in essence, arbitrary data to some URL, in what way is that different from using it as what you call a Document Processor - if I understand what you mean by that term. :) I tried to spell out what I see as a real and meaningful difference. I agree with Walden that there are situations that seem very gray. One that I can think of right away is performing atomic updates across multiple resources. The canonical, "transfer funds between accounts" example seems like a good use case to examine. I would be very interested in hearing other's thoughts on how to do that in a way that doesn't smack of RPC. Thanks, - Jeff
Jeff, Well, after reading and rereading the standard and Fielding's thesis and some other texts on document-centric modelling (which HTTP is heavi;ly based on though Fielding nor TBL ever admit it, GET, PUT, DELETE, POST are directly analagous to READ, WRITE, DELETE, XX) I think the only valid uses of POST are as follows: 1) Resource Creation. 2) Append-To-Document 3) Document Processor Note that 1,2,3 are all very much alike. For example, if you consider /purchase-orders the collection of purchase orders in the system then POST'ing a new purchase-order to that collection can be seen as using 1 or 2. There are subtle and important differences between them. Still, RPC never enters the picture. You are always passing fully formed documents that could possibly stand alone. - itdp Jeffrey Winter wrote:> Again, in case it's not clear above, it's about > *discriminating* RPC from REST, if indeed they > are partitioned (I don't think they are). It seems to me that the difference breaks down along the lines of how POST can be used: 1. To request the creation of a subordinate resource. 2. As a logical PUT (or DELETE). There was a thread earlier this month about whether or not it is okay to use POST to perform partial resource updates. I recall that it was suggested that it is purer (and sometimes necessary) to update the entire resource using a PUT, but performance requirements, etc., may preclude doing so. In this case, using POST is okay. 3. To request a resource to perform some action upon some logically subordinate data. 4. To tunnel RPC over HTTP to make arbitrary calls. So, the question is: is there a meaningful difference between 3 and 4? I think there is. RPC generally POSTs to some generic URL; essentially, the id of the resource being acted upon becomes the first parameter in the procedure call. With REST you have at least moved the first parameter out to a real URL. Beyond that though, when confronted with an problem where some RPC-ish approach may be considered, the recourse model can be refactored to make it more RESTful. For a simplified example such as squaring numbers, using the GET/PUT semantics is the way to go, but for a more general case were some arbitrary level of backend processing needs to occur, a POST operation would often need to be employed. This would seem to hold especially when multiple resources need to be updated in an atomic way. For example, how do you handle transferring money from a savings account to a checking account? Sam Ruby has an article (that I believe someone here had referenced before) where he makes the statement: "It is the expression of higher level operations (particularly ones that perform non-atomic updates) that SOAP's value proposition becomes apparent. Sometimes, one truly wants to have an atomic "transfer funds from savings to checking" transaction instead of simply a series of discrete GET and PUT's." [http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html] Surely you can't just GET the account representations, update the balance in each and then PUT them back one at a time. I understand the sentiment behind Ruby's statement, but I don't agree that REST precludes doing atomic operations, so long as POST semantics are employed. For example, you could request the creation of a "transfer" resource POST /user/joe/accounts/transfers <transfer from-account="savings/1234" to-account="checking/2345">50</transfer> on successful transfer: 201 Created Location: /user/joe/accounts/transfers/00001 if insufficient funds: 400 Bad Request A GET against /transfers could return a transfer history, etc. If you did something like POST the to-account number and amount to the from-acount resource: POST /user/joe/savings/transfer <transfer to-account="2345">50</transfer> one could argue that this is RESTful since you are asking the account resource to work with logically subordinate data, but using POST in this way does start to "smell" like RPC. Thanks, - Jeff Yahoo! Groups SponsorADVERTISEMENT To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes
On Thu, Aug 29, 2002 at 03:38:54PM -0000, bhaugen32 wrote: > Mark Baker wrote: > > Both sides can log all messages that were part of that transaction > and > > if needed, use them to defend their position in a court of law. So > > there's existing protection from the sort of stuff you're asking > about > > (fraud, etc..). > > This is an important point for business. > But are you taking full advantage of REST when you think about it? I think so. > Business exchanges are conversations. Right, but REST based business interactions are stateless. Those two things are not at odds, if that's what you're suggesting. > If you think of each message as a speech act, > probably related to other speech acts in the same conversation, > then each speech act is an important resource deserving a URI. Hmm, I'm not so sure. Consider this "conversation"; "Hi Bob" - "Hi Mark" "How's the wife?" - "Good" That conversation is stateful. The last "Good" message doesn't say what is good. You need the context of at least part of the conversation in order to understand what it means. A stateless version of that conversation would be; "Hi Bob" - "Hi Mark" "How is Bob's wife?" - "Bob's wife is good" It sounds a bit odd, but that's how I'd do RESTful conversations. > If you combine: > * state-alignment transactions so that each party agrees on each > important business milestone, e.g. commitment and fulfillment of > commitment > * business rules that are also published with URIs > * digital signatures > * canonical representations of the whole ball of wax > - then you got something that you could take into court, > but you probably won't need to. In the stateless case, you could just take the offending message to court and leave everything else behind, because its meaning is independant of any conversation it may have been sent in. > -Bob Haugen > > P.S. I think a lot of the current discussion focuses on "how to do > RPC in REST" rather than "use cases for which REST is a clear > advantage". Yep. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> > P.S. I think a lot of the current discussion focuses on "how to do > > RPC in REST" rather than "use cases for which REST is a clear > > advantage". > > Yep. I agree, and as an enthusiastic REST newbie, it's the cases where REST has a clear advantage that I would like to hear about. Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
See http://mail.python.org/pipermail/xml-sig/2002-February/007160.html: The point is to think of documents. This is a subtle but crucial distinction. Don't think of a document processor as a procedure that takes parameters; think of it as a folder into which you insert documents. Eventually something happens to those documents but the truth is, you don't really care. If you're asking about the advantages over using the POST/Document Processor approach versus RPC then from experience I can tell you: 1) EXTENSIBILITY & MAINTAINABILITY - I can't stress this enough. The fundamental problem with all RPC-mechanisms is that they are inherently not loosely coupled. Think of a method in Java. This method defines a contract and semantics. If you change this method -- by removing or adding a parameter or changing parameters etc -- then you break all clients which depend on that method. Now think of an html document. It's a document whose meaning and semantics are fully self-contained in the document. A browser, which processes html documents, isn't broken when you add elements or even when you remove elements. Think about event based processing. The fundamental idea is that in a highly distributed system two parties should know as little about each other as possible. In REST/document/event-based systems, all the parties have to know is essentially a URL to which they send documents/events. In an RPC/SOAP world, they have to know a lot more. This is one of the primary reasons my group began reworking all webservices to be REST based. I saw the time and effor that went into managing RPC services and coordinating interfaces and decided it was unacceptable. 2) SCALABILITY - See mprescod and fielding for how a document- centric, highly asynchronous approach will always scale better than the basic rpc approach. 3) FLEXIBILITY - I don't really have time to explain it in full detail, but there are many, many bad things that can happen when you use POST as an RPC-mechanism or use RPC in general. You can end up in situations where a competitor has 'locked' you in because he controls the api on his side and if you want access to his info well you get the idea. (This is why I call the WS-* standards one api to rule them all). But there are many good things that happen when you think in terms of business documents particularly in terms of reuse. It's been my experience that integerating REST systems is trivial and building web-frontends is even easier. Not many people see it, but there's a huge difference between exposing business logic -- which consists of documents like purchase orders -- and exposing application logic -- which consists of methods and behavior and state and all that good stuff. As for your transfer funds use case, I've designed something pretty similar. The way I did it, I created a document which described the transaction itself and POSTED that to a transaction processor resource. I then repeatedly performed GETs on a transaction monitor resource to know what was up. This trick of turning methods into documents/events works well. - itdp --- In rest-discuss@y..., "Niteo" <j.winter@n...> wrote: > Terrence, > > First off, I agree with you. I should say that I was > most definitely *not* trying to offer a new definition > of POST; I was basically trying to catalogue the > uses of POST that have been brought up in order to try > to bring into relief the precise issue that Walden was > trying to raise. Which I think boils down to: if RPC > is bad because it's misusing POST to send, in essence, > arbitrary data to some URL, in what way is that different > from using it as what you call a Document Processor - if > I understand what you mean by that term. :) > > I tried to spell out what I see as a real and meaningful > difference. > > I agree with Walden that there are situations that seem > very gray. One that I can think of right away is performing > atomic updates across multiple resources. The canonical, > "transfer funds between accounts" example seems like a > good use case to examine. > > I would be very interested in hearing other's thoughts on > how to do that in a way that doesn't smack of RPC. > > Thanks, > > - Jeff
> > In the stateless case, you could just take the offending message to > court and leave everything else behind, because its meaning is > independant of any conversation it may have been sent in. Including any previous commitments to buy at a certain price (like a catalog)?
Mark Baker wrote, > A stateless version of that conversation would be; > > "Hi Bob" > - "Hi Mark" > "How is Bob's wife?" > - "Bob's wife is good" > > It sounds a bit odd, but that's how I'd do RESTful conversations. Is it always possible to eliminate context this way? How would you deal with, "Hi Bob" - "Hi Mark" "Nice weather today" - "Sorry, missed that. What did you say?" "Nice weather today" The relationship with reliable messaging protocols should be obvious. Cheers, Miles
> From: Miles Sabin [mailto:miles@...] > > "Hi Bob" > - "Hi Mark" > "Nice weather today" > - "Sorry, missed that. What did you say?" > "Nice weather today" > > The relationship with reliable messaging protocols should be obvious. or: "Hi Bob" - "Hi Mark" "two guinness please" "two guinness please" The relationship with the browser's back button should also be obvious. regards, Bill de hra .. Propylon www.propylon.com
Mark Baker wrote: > > Business exchanges are conversations. > > Right, but REST based business interactions are stateless. Those two > things are not at odds, if that's what you're suggesting. No, I wasn't suggesting it, but your response suggests that there may be conflicts depending on how it's done. More below... > > If you think of each message as a speech act, > > probably related to other speech acts in the same conversation, > > then each speech act is an important resource deserving a URI. > > Hmm, I'm not so sure. > > If you combine: > > * state-alignment transactions so that each party agrees on each > > important business milestone, e.g. commitment and fulfillment of > > commitment > > * business rules that are also published with URIs > > * digital signatures > > * canonical representations of the whole ball of wax > > - then you got something that you could take into court, > > but you probably won't need to. > > In the stateless case, you could just take the offending message to > court and leave everything else behind, because its meaning is > independant of any conversation it may have been sent in. Depending on what you mean, that gets tricky. Simple case: shipment notification is dependent on order line which it purports to fulfill. Claims of non-fulfillment would need both the shipment notification and the order line. More complex case: non-fulfillment is covered by a long term contract which provides penalties. So now the long-term contract clause must be stated as well. In a business conversation, each speech act will refer to any other statements required for its meaning. But it will usually not repeat all the relevant elements. In URI-land, the most natural representation would be for statement B to contain a hyperlink to statement A, but not to transclude a full representation of statement A. However, for evidence and for "what to digitally sign", one could create a combined canonical representation of the related statements and sign that. Then you do have one document to take to to court. Are these ideas relevant to the issue raise? -Bob Haugen
"Jeffrey Winter" wrote: > ... when multiple > resources need to be updated in an atomic way. > > For example, how do you handle transferring money from > a savings account to a checking account? [...] > For example, you could request the creation of a > "transfer" resource > > POST /user/joe/accounts/transfers > <transfer from-account="savings/1234" > to-account="checking/2345">50</transfer> > > on successful transfer: > > 201 Created > Location: /user/joe/accounts/transfers/00001 > > if insufficient funds: > > 400 Bad Request > > A GET against /transfers could return a transfer history, etc. In my opinion, you got it. Read also Jeff Bone's "Dining Philosophers in REST": http://www.xent.com/pipermail/fork/2001-August/002923.html <excerpt> Clay [Shirky] posed race conditions as a challenge that perhaps cannot be overcome with the REST design practice of using HTTP's generic interfaces and resource modeling, due to a perceived need to atomically perform a series of HTTP methods. The claim is that an RPC interface, by allowing the encapsulation of the desired operations into one specialized interface that can be tunneled through and atomically performed in the context of a single POST. The latter strategy --- take care of all the necessaries in a single POST --- is correct, but it doesn't require the introduction of specialized method interfaces, just the appropriate decomposition into resources. I'd already been working on a short but hopefully enlightening example --- the venerable Dining Philosophers, serendipity! --- to demonstrate how resource modeling can handle a similar problem. [...] Assume that the problem space --- tables, forks, what have you --- is implemented as a Web Service using the REST style. The philosophers themselves are the client applications which consume the Web Service. [...] Imagine that we have introduced to the problem space two waiters; they act on behalf of the philosophers, who have been instructed not to pick up or put down the forks directly themselves. (In fact they cannot because we don't model the forks directly.) The desired atomic behavior is encapsulated in and between the waiters. One waiter is tasked with observing the table and, at a philosopher's request and if possible, taking from the philosopher their ticket, removing the two adjacent forks from the table and handing them to the philosopher. The other waiter performs the reverse function, exchanging forks for the corresponding ticket and placing them on the table. [...] The critical sections which are usually protected by mutexes are implemented in the waiters, and each is engaged through a single HTTP transaction. [...] So: REST can do Dining Philosophers; the trick is just to encapsulate the critical sections into local objects and reify them as resources. The notion that you need some kind of transactional control at the protocol level is, in fact, a boondoggle; transactions are always a higher-level abstraction, and any lower-level but complete abstraction --- INVOKE, GET / PUT / POST, READ / WRITE / TAKE, etc. are all sufficient; transactions can be provided either locally or as higher-level semantics layered atop but conforming to the semantics of the substrate. More generally, this should at least suggest that the primary difference between REST and procedure calling is in modeling the problem domain as a set of resources --- nouns --- each of which can be potentially active but which responds to a generic interface. This as opposed to the RPC approach of specialized interfaces. [...] The problem is one of modeling, not one of the richness and expressivity of either approach. [...] it's always a bad idea to manage transactions (i.e., attempt to guarantee atomicity of a sequence of actions, *even if this is made possible by the underlying communication model*) non-locally. Whenever possible --- and it's always possible --- atomic sequences of interactions should be managed by intermediate objects local to the resources being locked and manipulated; it's trivial to encapsulate transactions into a single atomic exchange, and exposing those encapsulations as first class entities is generally a pretty good idea. And it certainly fits with the REST model of the world. </excerpt>
On Fri, Aug 30, 2002 at 08:25:12AM +0100, Miles Sabin wrote: > Is it always possible to eliminate context this way? I suspect and believe so, but I don't know for sure. > How would you deal > with, > > "Hi Bob" > - "Hi Mark" > "Nice weather today" > - "Sorry, missed that. What did you say?" Assuming that was necessary because of a corrupt message, it would be a 400 response message whose correlation to "nice weather today" is implicit in the connection (at least for HTTP). So more accurately, to list all the messages, including response messages, a stateless conversation over a connection oriented protocol would be; "Hi Bob" - "ok" - "Hi Mark" - "ok" "Nice weather today" - "sorry, missed that" "Nice weather today" - "ok" > The relationship with reliable messaging protocols should be obvious. Definitely. Roy touches on this when talking about statelessness; "This constraint induces the properties of visibility, reliability, and scalability. [...]Reliability is improved because it eases the task of recovering from partial failures[...]" -- http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3 MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I tried to post a slightly different version of this message earlier, but it looked like Yahoo Groups timed out. Sorry if two appear later. "S. Mike Dierken" wrote: > > > > In the stateless case, you could just take the offending message to > > court and leave everything else behind, because its meaning is > > independant of any conversation it may have been sent in. > Including any previous commitments to buy at a certain price (like a > catalog)? Exactimento! Business conversations consist of a buildup of conditions, commitments, fulfillments of commitments, claims for payment, claims that commitments were not fulfilled correctly, etc. etc. Almost every statement beyond "Hello" is dependent on some previous statements, and even "Hello" assumes authentication. There are very few, almost no independent statements. Two possible ways to deal: 1. Embed a representation of every possible dependency in a canonical representation of every dependent statement. 2. Follow hyperlinks to chains of dependencies. Each of those ways could be appropriate for some situation or other. I'm still trying to work out all the implications. If there are other ways to deal, I'm all ears. But it will not work to avoid the dependencies. In business, everything is dependencies. In software development, it's much the same. To me, hyperlinks *are* dependencies. -Bob Haugen P.S. I believe canonical representations of evidence of electronic business deals will be "standardized" probably by more than one "standards" org. That's where I think URIs for all evidence will be a clear advantage for REST vs burying the evidence in proprietary systems.
That's a good summarization, but I don't think we're disagreeing in any way. There is no inherent advantage to using RPC; it was more of a issue of trying to identify use cases where an RPC style approach might be appealed to and seeing if a RESTful approach could be identified that isn't itself just RPC in disguise. Thanks again, - Jeff
> > P.S. I think a lot of the current discussion focuses on "how to do > > RPC in REST" rather than "use cases for which REST is a clear > > advantage". > > Yep. I think this mischaracterisizes the original discussion a bit. The underlying issue was more along the lines of how to *avoid doing* RPC in REST. If there are "use cases for which REST is a clear advantage," this would imply that there are cases where it isn't. What are those cases? Understanding what those boundaries are (and I can't think of any) would be very illuminating.
Mark Baker wrote: > >... > > In the stateless case, you could just take the offending message to > court and leave everything else behind, because its meaning is > independant of any conversation it may have been sent in. You need the message plus all resources pointed to by the message. If the messages is "Yes I agree to the contract at http://..../" then you need http://.../ and you need it as it was at the time the message was sent (a good argument for signed, immutable resources in contractual contexts). -- Paul Prescod
Paul Prescod wrote: > Mark Baker wrote: > > > >... > > > > In the stateless case, you could just take the offending message to > > court and leave everything else behind, because its meaning is > > independant of any conversation it may have been sent in. > > You need the message plus all resources pointed to by the message. If > the messages is "Yes I agree to the contract at http://..../" then you > need http://.../ and you need it as it was at the time the message was > sent (a good argument for signed, immutable resources in contractual > contexts). Yes yes yes! Yes! and Yes again! Thank you! I've been thinking signed canonical representations, because I didn't know how to specify immutable resources. Do you? (Although wouldn't either work?)
Niteo wrote: > >... > > I agree with Walden that there are situations that seem > very gray. One that I can think of right away is performing > atomic updates across multiple resources. The canonical, > "transfer funds between accounts" example seems like a > good use case to examine. I don't know yet whether RPC and REST are on two sides of a fence or two ends of a spectrum. Is submitting a "transfer order" an RPC (because the meaning is embedded in the message)? Well let's just say we can move it pretty far to the REST side of the spectrum if we: * make the order addressable so that it can be referred to by anyone, anytime * describe the transfer order in an XML or RDF schema, in as rich a way as possible * make the URI for "submit transfer order for this account" a hyperlink from the account object * separate the URI for "submit transfer order" from the URIs for "pay bills from this account" and "get information about this account" and "withdraw money from this account" * if transfer orders can be removed, updated or read, use standard HTTP methods to do so * make a GET on the URI for "submit transfer order" return something that lists the current orders and perhaps describes what will happen when new orders are submitted (prose or machine readable?) Hopefully these will help someone. Here's a way of thinking about it: consider an intermediary or third party shown a single message. The more they know without understanding the domain, the better. With GET, PUT and DELETE you know a bunch without knowing much about either the resource types or the representations. With POST, you usually need to know more about resource types but if you don't need to know data format then you are still making progress. A POST to a transfer order submission URI is going to create a money transfer document -- the exact representation is only needed if you care who is receiving the money and how much money is being received. If you need to know both the resource type and the data format to know anything interesting about what's going on then you're doing RPC. e.g. if you have a "submit something" resource and what happens is entirely dependent on what you submit. Another random thought: Moving data between accounts is not in general an atomic operation. One bank has to debit the money and the other credit it. When they are the same bank they can present the illusion of atomicity but more generally the operation involves a perhaps unreliable third party. That suggests to me that using resources rather than stateful messages is a better way to keep everyone aligned and in agreement about what's going on. When we start to involve various independently controlled parties we have to relax our requirements of atomicity and figure out how to get work done without it. So basically I think that doing a POST of a "money transfer order" is a better model than doing an RPC and therefore I disagree with Sam Ruby that this example exposes a limitation of the REST model. -- Paul Prescod
On Fri, 30 Aug 2002, Jeffrey Winter wrote: > > > P.S. I think a lot of the current discussion focuses on "how to do > > > RPC in REST" rather than "use cases for which REST is a clear > > > advantage". > > > > Yep. > > I think this mischaracterisizes the original discussion a > bit. The underlying issue was more along the lines of how > to *avoid doing* RPC in REST. > > If there are "use cases for which REST is a clear advantage," this > would imply that there are cases where it isn't. What are those > cases? Well? What are some use cases where REST should not be used? Since I'm advocating a RESTful implementation of Linda tuple spaces, I'd like to know if my use cases falls into this category! > Understanding what those boundaries are (and I can't think of any) > would be very illuminating. Hmmm... No cases where REST should not be used? This sounds like religious enthusiasm to me.... Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
Sam Hunting wrote: > > > > P.S. I think a lot of the current discussion focuses on "how to do > > > RPC in REST" rather than "use cases for which REST is a clear > > > advantage". > > > > Yep. > > I agree, and as an enthusiastic REST newbie, it's the cases where REST has > a clear advantage that I would like to hear about. No matter what side of the debate they are on, almost everyone agrees that REST is better for read-only or read-mostly applications. RPC and "messaging" people sometime to argue that REST is *limited* to these applications but I think it is more accurate to say that it takes more imagination and skill to understand how REST is also better for read-write applications. ;) I've also never heard anyone dispute that REST is better for applications that depend upon address-keyed metadata like RSS, RDF or Topic Maps (to play to your biases). REST is pretty obviously better for content-management style applications. REST has clear advantages when the human implementors of systems are not coordinated. i.e. when you can't upgrade the participants all at the same time. -- Paul Prescod
I'll respond to all the other messages here ... On Fri, Aug 30, 2002 at 09:26:44AM -0700, Paul Prescod wrote: > > In the stateless case, you could just take the offending message to > > court and leave everything else behind, because its meaning is > > independant of any conversation it may have been sent in. > > You need the message plus all resources pointed to by the message. If > the messages is "Yes I agree to the contract at http://..../" then you > need http://.../ and you need it as it was at the time the message was > sent (a good argument for signed, immutable resources in contractual > contexts). No, I don't think you need representations of all the referenced resources, at least if you've done it right. Using that example, it would be a mistake to agree to a contract by reference, because the contract may change by the time the message is processed. The rule is, if the meaning of the message depends upon the result of dereferencing a URI, then this is stateful and a bad thing. So while it would be fine to, say, send a list of contracts by URI for the simple purpose of enumerating them, it would not for the purpose of agreeing to them. That's because in the former case, only their *identity* contributes to "meaning", whereas in the latter, their *state* contributes to it. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> > As an enthusiastic REST newbie, it's the cases where REST has > > a clear advantage that I would like to hear about. > > > REST has clear advantages when the human implementors of systems are not > coordinated. i.e. when you can't upgrade the participants all at the > same time. For any reasonably sized size of human communication (say, a topic-map-enabled conversational space) this would almost always be the case. Can you elaborate on the clear advantages in this context? (I'm joining the conversation late, I know) Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
This is addressed to all who have contributed to the thread, not just Mark. Are these ideas based on experience in some judicial system or another? Or are they systems analysts views of where the authoritative data in a transaction *ought to* be found? My own opinion, based on judges and arbitrators I have faced in contract matters, is that they want a context from which to judge what constitutes the contract in question, and they don't like other people constraining them in their judgment of how wide or narrow that context should be. I think that judges and juries for that matter are interested in conversational state, not just in discrete 'stable states' of a negotiation. But I've never been to court over an electronic transaction, so my view may be totally uninformed. Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Friday, August 30, 2002 1:07 PM > To: Paul Prescod > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Evidence > > > I'll respond to all the other messages here ... > > On Fri, Aug 30, 2002 at 09:26:44AM -0700, Paul Prescod wrote: > > > In the stateless case, you could just take the offending > message to > > > court and leave everything else behind, because its meaning is > > > independant of any conversation it may have been sent in. > > > > You need the message plus all resources pointed to by the > message. If > > the messages is "Yes I agree to the contract at > http://..../" then you > > need http://.../ and you need it as it was at the time the > message was > > sent (a good argument for signed, immutable resources in contractual > > contexts). > > No, I don't think you need representations of all the referenced > resources, at least if you've done it right. Using that example, it > would be a mistake to agree to a contract by reference, because the > contract may change by the time the message is processed. > > The rule is, if the meaning of the message depends upon the result of > dereferencing a URI, then this is stateful and a bad thing. > > So while it would be fine to, say, send a list of contracts by URI > for the simple purpose of enumerating them, it would not for the > purpose of agreeing to them. That's because in the former case, only > their *identity* contributes to "meaning", whereas in the > latter, their > *state* contributes to it. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote: > > I'll respond to all the other messages here ... > >... > > No, I don't think you need representations of all the referenced > resources, at least if you've done it right. Using that example, it > would be a mistake to agree to a contract by reference, because the > contract may change by the time the message is processed. I'm not convinced that it is always practical to "inline" all relevant state. But I'll let Bob "I know contracts" Haugen come up with a counter example. Real-world contracts (and laws) do sometimes refer to each other and we handle that by keeping historical copies of them around. > The rule is, if the meaning of the message depends upon the result of > dereferencing a URI, then this is stateful and a bad thing. Okay, you have a stronger definition of stateful than I do. I agree that where your model is practical it is better because it is easier to log, more visible for intermediaries etc. But it feels like there are cases where you would end up inlining a huge web of historical documents. Nevertheless, your distinction of referencing identity versus referencing state points out that EVERY link does not have to be inlined. I'll have to think about some examples more. -- Paul Prescod
Sam Hunting wrote: > >... > > Well? What are some use cases where REST should not be used? Since I'm > advocating a RESTful implementation of Linda tuple spaces, I'd like to > know if my use cases falls into this category! To be honest, probably not. ;) ;( Here's why I say that: REST has its own kind of interaction model, just as tuple spaces do. I think that putting one on top of the other will degrade the benefits of both. It is a little like putting objects in a relational databases or relations in an object database etc. > > Understanding what those boundaries are (and I can't think of any) > > would be very illuminating. > > Hmmm... No cases where REST should not be used? This sounds like religious > enthusiasm to me.... I believe that REST is not appropriate for first person shooters (as an example). Performance would be a huge problem in trying to maintain REST's statelessness. Realtime 3D video games cannot even afford to be "stateless enough" to meet their own security requirements (that's why the send extra information before it is needed and that informatio is used by cheater software). -- Paul Prescod
Sam, What is the difference between REST and tuple spaces? The APIs look suspiciously alike. - itdp --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > Sam Hunting wrote: > > > >... > > > > Well? What are some use cases where REST should not be used? Since I'm > > advocating a RESTful implementation of Linda tuple spaces, I'd like to > > know if my use cases falls into this category! > > To be honest, probably not. ;) ;( > > Here's why I say that: REST has its own kind of interaction model, just > as tuple spaces do. I think that putting one on top of the other will > degrade the benefits of both. It is a little like putting objects in a > relational databases or relations in an object database etc. > > > > Understanding what those boundaries are (and I can't think of any) > > > would be very illuminating. > > > > Hmmm... No cases where REST should not be used? This sounds like religious > > enthusiasm to me.... > > I believe that REST is not appropriate for first person shooters (as an > example). Performance would be a huge problem in trying to maintain > REST's statelessness. Realtime 3D video games cannot even afford to be > "stateless enough" to meet their own security requirements (that's why > the send extra information before it is needed and that informatio is > used by cheater software). > -- > Paul Prescod
"Mathews, Walden" wrote: > This is addressed to all who have contributed to the thread, not > just Mark. Are these ideas based on experience in some judicial > system or another? Or are they systems analysts views of where the > authoritative data in a transaction *ought to* be found? > > My own opinion, based on judges and arbitrators I have faced in > contract matters, is that they want a context from which to judge > what constitutes the contract in question, and they don't like > other people constraining them in their judgment of how wide or > narrow that context should be. > > I think that judges and juries for that matter are interested in > conversational state, not just in discrete 'stable states' of a > negotiation. > > But I've never been to court over an electronic transaction, so my > view may be totally uninformed. I posted some references to legal standards on http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi rements Everything I know about this stuff came from working on ebXML, where we had several experts in legal aspects of electronic transations, including the chair of the ABA eCommerce committee. One of the principles that I quoted on the Rest Wiki page advocated: 'Replicable and computable transaction state closure. In the foregoing context, "suitable proof" of the offer and acceptance events, means that determinable computation of the transaction's "success" or "failure" state must be replicable by both trading partners at run time, as well as third parties (such as a court) after the fact, using only artifacts transmitted within messages associated with the transaction.' That's still a little ambiguous re the current discussion, and IANAL, and so will refrain from interpreting it further. -Bob Haugen
REST was designated as an architecture, but there's an implied development method akin to object design methods that we seem to be applying in the name of REST. Resource orientation might be the name of that method. Jackson problem frames are useful for selecting a method based on the type of problem. For those not familiar, the Information Frame is about content-management, the Static Information Frame is about read-only resources. REST and resource orientation seem well fitted to both. The Control Frame is about making something meet its specification, and I interpret Roy to say in the dissertation that REST is less applicable to control problems than information problems. I think REST is also quite applicable to Workpieces Frame problems, in which we are attempting to build an electronic artifact such as a specification or a contract or an order or a piece of electronic art. Walden > -----Original Message----- > From: Sam Hunting [mailto:shunting@...] > Sent: Friday, August 30, 2002 12:57 PM > To: Jeffrey Winter > Cc: Mark Baker; bhaugen32; rest-discuss@yahoogroups.com > Subject: [rest-discuss] When REST should and should not be used Was: > Evidence > > > On Fri, 30 Aug 2002, Jeffrey Winter wrote: > > > > > P.S. I think a lot of the current discussion focuses on > "how to do > > > > RPC in REST" rather than "use cases for which REST is a clear > > > > advantage". > > > > > > Yep. > > > > I think this mischaracterisizes the original discussion a > > bit. The underlying issue was more along the lines of how > > to *avoid doing* RPC in REST. > > > > If there are "use cases for which REST is a clear advantage," this > > would imply that there are cases where it isn't. What are those > > cases? > > Well? What are some use cases where REST should not be used? Since I'm > advocating a RESTful implementation of Linda tuple spaces, I'd like to > know if my use cases falls into this category! > > > Understanding what those boundaries are (and I can't think of any) > > would be very illuminating. > > Hmmm... No cases where REST should not be used? This sounds > like religious > enthusiasm to me.... > > Sam Hunting > eTopicality, Inc. > > -------------------------------------------------------------- > ------------- > "Turn your searching experience into a finding experience."(tm) > > Topic map consulting and training: www.etopicality.com > Free open source topic map tools: www.goose-works.org > > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley, ISBN 0-201-74960-2. > -------------------------------------------------------------- > ------------- > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> Sam, > > What is the difference between REST and tuple spaces? The APIs look > suspiciously alike. I would say the semantics of the tuples, I would say. I am not sure where along the "stateful" "not stateful" constinuum tuples fall, though. Could one make sense of a tuple, all on its own? I don't think that's necessarily the case. Could one design a tuple format that was self-describing (ie, not stateful)? I think so. S. > - itdp > > --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > > Sam Hunting wrote: > > > > > >... > > > > > > Well? What are some use cases where REST should not be used? > Since I'm > > > advocating a RESTful implementation of Linda tuple spaces, I'd > like to > > > know if my use cases falls into this category! > > > > To be honest, probably not. ;) ;( > > > > Here's why I say that: REST has its own kind of interaction model, > just > > as tuple spaces do. I think that putting one on top of the other > will > > degrade the benefits of both. It is a little like putting objects > in a > > relational databases or relations in an object database etc. > > > > > > Understanding what those boundaries are (and I can't think of > any) > > > > would be very illuminating. > > > > > > Hmmm... No cases where REST should not be used? This sounds like > religious > > > enthusiasm to me.... > > > > I believe that REST is not appropriate for first person shooters > (as an > > example). Performance would be a huge problem in trying to maintain > > REST's statelessness. Realtime 3D video games cannot even afford to > be > > "stateless enough" to meet their own security requirements (that's > why > > the send extra information before it is needed and that informatio > is > > used by cheater software). > > -- > > Paul Prescod > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
"Mathews, Walden" wrote: > > This is addressed to all who have contributed to the thread, not > just Mark. Are these ideas based on experience in some judicial > system or another? Or are they systems analysts views of where the > authoritative data in a transaction *ought to* be found? No, I have no experience with electronic legal contracts other than simple B2C credit card transactions. > My own opinion, based on judges and arbitrators I have faced in > contract matters, is that they want a context from which to judge > what constitutes the contract in question, and they don't like > other people constraining them in their judgment of how wide or > narrow that context should be. The question is whether the system is designed so that their job is a) doable b) relatively easy Statelessness helps with both of these. If I can print out a single, URI-addressble signed XML resource that describes a contract versus a hundred RPC messages from a log, then I think they will prefer that. If they also want to look at my HTTP logs and other probably irrelevant resources then that's up to them. > I think that judges and juries for that matter are interested in > conversational state, not just in discrete 'stable states' of a > negotiation. In general I would expect them to focus on the final contract rather than (for example) the hundreds of iterations that pass around during negotiation. This will be even more the case when the "negotiators" are computers and where the negotiations cannot be used as hints towards human intent. Computers will also tend to use predefined contracts because they aren't smart enough to write their own. Therefore the most relevant question will often be: "Did you really agree to this predefined contract or not?" -- Paul Prescod
Paul Prescod wrote: > I'll let Bob "I know contracts" Haugen come up with a counter > example. Oh no, I hope I'm not pretending to knowledge I don't have. I am very interested in electronic contracts. I worked with a couple of masters of the subject in ebXML. I tried to learn everything I could, but am still a grasshopper. I'm working on a project proposal which will try to use RESTified contracts if it goes through. > Real-world contracts (and laws) do sometimes refer to each > other and we handle that by keeping historical copies of them around. > > > The rule is, if the meaning of the message depends upon the result of > > dereferencing a URI, then this is stateful and a bad thing. > > Okay, you have a stronger definition of stateful than I do. I agree that > where your model is practical it is better because it is easier to log, > more visible for intermediaries etc. But it feels like there are cases > where you would end up inlining a huge web of historical documents. > Nevertheless, your distinction of referencing identity versus > referencing state points out that EVERY link does not have to be > inlined. I'll have to think about some examples more. I am still thinking about the alternatives, too. But I think there is a distinction between "the meaning of the message" in the sense of its value as a speech act, that is, the values of its elements, and the "residual effect" of the message on the whole business conversation. In other words, if I offer to buy your Porsche for $100, the meaning of my message is clear, but in context, it's absurd. Likewise if the contract says "you will deliver 100 pairs of shoes at noon next Monday", and you send a Shipment Notification saying you're sending 50 pair on Tuesday, the meaning of the notification is clear, but it does not fulfill the contractual commitment. So should the Shipment Notification contain the signed representation of the commitment? Or just refer to it? If it refers to it, if the buyer changed it unilaterally from Tuesday to Monday and from 50 to 100, how does the seller prove it? -Bob Haugen
> > Well? What are some use cases where REST should not be used? Since I'm > > advocating a RESTful implementation of Linda tuple spaces, I'd like to > > know if my use cases falls into this category! > > To be honest, probably not. ;) ;( > > Here's why I say that: REST has its own kind of interaction model, just > as tuple spaces do. I think that putting one on top of the other will > degrade the benefits of both. It is a little like putting objects in a > relational databases or relations in an object database etc. Hmmm... It may be that I am confusing a networked implementation using typical networking protocols with a REST architecture (and its interaction model). On the other hand, http GET looks a lot like Linda OUT. Couldn't the Linda space be just another client? What benefits do you think will be lost (to Linda and to REST) with this approach? (I am after massive scaleability, I don't care about network latency) within reason.)) > > > Understanding what those boundaries are (and I can't think of any) > > > would be very illuminating. > > > > Hmmm... No cases where REST should not be used? This sounds like religious > > enthusiasm to me.... > > I believe that REST is not appropriate for first person shooters (as an > example). Performance would be a huge problem in trying to maintain > REST's statelessness. Realtime 3D video games cannot even afford to be > "stateless enough" to meet their own security requirements (that's why > the send extra information before it is needed and that informatio is > used by cheater software). So it isn't network latency but the cost of expressing stateless messages (if that is the right word) that is at issue. (Sounds like one wouldn't write an authoring system with versioing RESTfully either, since it would be simpler to send the diffs around rather than a complete document? If that example isn't too crude....) Not sure about this notion of "messages" (?) being stateless (ie, being context free? Or having their entire context with them??) It sounds a lot like the old SGML issue of self-describing tag names ... Well, yes, they were self-describing ... Up to a point determined by context (operational definition: "that which I have to talk to a lot of people about but can never pin down.") Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
bhaugen32 wrote: > >... > > Oh no, I hope I'm not pretending to knowledge I don't have. > I am very interested in electronic contracts. > I worked with a couple of masters of the subject in ebXML. > I tried to learn everything I could, but am still a grasshopper. > I'm working on a project proposal which will try to use RESTified > contracts if it goes through. There are very few people who have spent much time with electronic contracts in open systems so you are still way ahead of most of us. >... > Likewise if the contract says "you will deliver 100 pairs of shoes at > noon next Monday", and you send a Shipment Notification saying you're > sending 50 pair on Tuesday, the meaning of the notification is clear, > but it does not fulfill the contractual commitment. > > So should the Shipment Notification contain the signed representation > of the commitment? Or just refer to it? If it refers to it, if the > buyer changed it unilaterally from Tuesday to Monday and from 50 to > 100, how does the seller prove it? Here's how I would do it: <ShipmentNotification> <Commitment uri="http://..../" signature="digital_hash"/> <dsig>...</dsig> </ShipmentNotification> If the hash doesn't match the resource then the resource has a different state than when I agreed to it. It is not mathematically feasible to change the state without breaking the hash. -- Paul Prescod
Paul Prescod wrote: > > I think that judges and juries for that matter are interested in > > conversational state, not just in discrete 'stable states' of a > > negotiation. > > In general I would expect them to focus on the final contract rather > than (for example) the hundreds of iterations that pass around during > negotiation. I agree with you about the final contract. But the interesting issues in this present thread are not about the final contract, but the fulfillment of contractual commitments. In other words, in the contract you committed to some future behavior. When you send a message concerning that future behavior, it will be governed by the contractual commitment. So the message that is governed by the contractual commitment may be clear in its own contents, but it is not independent of the commitment in its business effect. Therefore should it reference the commitment, or include it inline? (Or something else?) -Bob Haugen
Paul Prescod wrote: > > So should the Shipment Notification contain the signed representation > > of the commitment? Or just refer to it? If it refers to it, if the > > buyer changed it unilaterally from Tuesday to Monday and from 50 to > > 100, how does the seller prove it? > > Here's how I would do it: > > <ShipmentNotification> > <Commitment uri="http://..../" signature="digital_hash"/> > > <dsig>...</dsig> > </ShipmentNotification> > > If the hash doesn't match the resource then the resource has a different > state than when I agreed to it. It is not mathematically feasible to > change the state without breaking the hash. Thanks! Why didn't I think of that? But just to be picky, you can only hash a representation, right? So you still have the requirement for a canonical representation to which to match the hash?
I think you hit upon a key point here. "Resource Orientation" is a great phrase for what you need to do to work with Rest. I think that's one of the key reasons many developers (myself included) have such a hard time getting their heads wrapped around REST. We're used to Object-Oriented Development, so SOAP/RPC is just a natural extension of that. We try to use REST and suddenly we are faced with a completely different paradigm, Resource-Oriented Development. Like it or not, I think that's one advantage SOAP/RPC will have over REST. Forcing Java/C++/C# developers to use one paradigm for their regular development, and switch to another for their network-based development is not very appealing. So, one "When REST should not be used" guideline could be: When you don't want to force your developers to learn a new paradigm. Toivo Lainevool -----Original Message----- From: Mathews, Walden [mailto:waldenm@...] Sent: Friday, August 30, 2002 10:50 AM To: 'Sam Hunting'; Jeffrey Winter Cc: Mark Baker; bhaugen32; rest-discuss@yahoogroups.com Subject: RE: [rest-discuss] When REST should and should not be used Was: Evidence REST was designated as an architecture, but there's an implied development method akin to object design methods that we seem to be applying in the name of REST. Resource orientation might be the name of that method.
> > I think that judges and juries for that matter are interested in > > conversational state, not just in discrete 'stable states' of a > > negotiation. > > In general I would expect them to focus on the final contract rather > than (for example) the hundreds of iterations that pass around during > negotiation. This will be even more the case when the > "negotiators" are > computers and where the negotiations cannot be used as hints towards > human intent. Computers will also tend to use predefined contracts > because they aren't smart enough to write their own. > Therefore the most > relevant question will often be: "Did you really agree to this > predefined contract or not?" We're not disagreeing here. What I meant is that the harder part of their job is deciding what constitutes the contract, and determining that requires context outside the contract document itself, including a certain amount of conversation. But I agree that the focus is on the final contract, i.e. what in their judgment constitutes that. That "did you really agree?" stuff may depend on what was said before the signing. Walden
> I don't know yet whether RPC and REST are on two sides of a > fence or two > ends of a spectrum. Is submitting a "transfer order" an RPC > (because the > meaning is embedded in the message)? Well let's just say we > can move it > pretty far to the REST side of the spectrum if we: > > * make the order addressable so that it can be referred to by anyone, > anytime > * describe the transfer order in an XML or RDF schema, in as > rich a way > as possible > * make the URI for "submit transfer order for this account" > a hyperlink > from the account object > * separate the URI for "submit transfer order" from the URIs for "pay > bills from this account" and "get information about this account" and > "withdraw money from this account" > * if transfer orders can be removed, updated or read, use > standard HTTP > methods to do so > * make a GET on the URI for "submit transfer order" return something > that lists the current orders and perhaps describes what will happen > when new orders are submitted (prose or machine readable?) > > Hopefully these will help someone. One of the (beneficial?) side effects of approaching a Control Frame problem from the perspective of an Information Frame is that the control process inherits the property of self-annotation. I think of it this way. If you use Quicken to record your bank transactions after they've gone through, you are just building an information system. If you use Quicken to record your bank transactions *before* they go through instead of after, you're still dealing with the same information, but you're using it both to effect the work and to record it. An augmented information system serves as a control system. The examples that look the most unabashedly like RPC are the ones in which we don't care if records are kept of the actions or not. Walden
Toivo \"Deutsch\" Lainevool wrote: > > I think you hit upon a key point here. "Resource Orientation" is a great > phrase for what you need to do to work with Rest. I think that's one of > the key reasons many developers (myself included) have such a hard time > getting their heads wrapped around REST. We're used to Object-Oriented > Development, so SOAP/RPC is just a natural extension of that. We try to > use REST and suddenly we are faced with a completely different paradigm, > Resource-Oriented Development. Jeff Bone: "It's a *really attractive* proposition to the OOP / IT guys to think of taking an existing object model and, with no or minimal Web-specific "glue", simply exporting those interfaces to the Web." http://www.xent.com/pipermail/fork/2001-August/002801.html (it's been an interesting year for REST) Anyhow, if people can succeed at doing standard OO over the network, more power to them. Why learn REST if you don't have to. But most of us believe that just exporting the OO local style to the Web will not work. * http://www.javatech.dk/javatech2/slides/Jini/img8.html * http://research.sun.com/techrep/1994/abstract-29.html Interestingly, there are roughly three main camps in the web services world, RPC, "messaging" (I use scare quotes because the term doesn't seem to be very well defined) and REST. Standard OO (with addressable object interfaces and type-specific interfaces) isn't really represented at all. Procedural, single-endpoint RPC may "seem like" the closest pattern but its limitations are also the most obvious and severe. -- Paul Prescod
This seems like the wrong tack to take. On close analaysis, Resource Oriented Programming is far more object oriented than SOAP/RPC. In fact there's a strong case to be made that ROP is a degenerate case of OOP, simplified and constrained in order to meet the scalability requirements of internet class applications. -itdp --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > Toivo \"Deutsch\" Lainevool wrote: > > > > I think you hit upon a key point here. "Resource Orientation" is a great > > phrase for what you need to do to work with Rest. I think that's one of > > the key reasons many developers (myself included) have such a hard time > > getting their heads wrapped around REST. We're used to Object- Oriented > > Development, so SOAP/RPC is just a natural extension of that. We try to > > use REST and suddenly we are faced with a completely different paradigm, > > Resource-Oriented Development. > > Jeff Bone: "It's a *really attractive* > proposition to the OOP / IT guys to think of taking an existing object > model and, with no or minimal Web-specific "glue", simply exporting > those interfaces to the Web." > > http://www.xent.com/pipermail/fork/2001-August/002801.html > > (it's been an interesting year for REST) > > Anyhow, if people can succeed at doing standard OO over the network, > more power to them. Why learn REST if you don't have to. But most of us > believe that just exporting the OO local style to the Web will not work. > > * http://www.javatech.dk/javatech2/slides/Jini/img8.html > > * http://research.sun.com/techrep/1994/abstract-29.html > > Interestingly, there are roughly three main camps in the web services > world, RPC, "messaging" (I use scare quotes because the term doesn't > seem to be very well defined) and REST. Standard OO (with addressable > object interfaces and type-specific interfaces) isn't really represented > at all. Procedural, single-endpoint RPC may "seem like" the closest > pattern but its limitations are also the most obvious and severe. > -- > Paul Prescod
Like most issues in software development this isn't a black or white issue. I don't think its right to say that "REST is better than RPC" or "RPC is better than REST". It really depends on context. Sometimes one makes sense, sometimes the other does. If you're integrating a bunch of legacy apps, SOAP/RPC probably makes more sense than REST. If you're publishing a widely available, general interest service on the Web, REST probably makes sense. I don't consider myself a strong advocate of either view. Being in one "camp" seems like a religious war that can never be won. I think the proper way to proceed is to clearly enumerate the strengths and weaknesses of all approaches and then provide guidelines on when to use which architectural style. Sounds like it might be a good article :) Toivo Lainevool > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Interestingly, there are roughly three main camps in the web services > world, RPC, "messaging" (I use scare quotes because the term doesn't > seem to be very well defined) and REST. Standard OO (with addressable > object interfaces and type-specific interfaces) isn't really represented > at all. Procedural, single-endpoint RPC may "seem like" the closest > pattern but its limitations are also the most obvious and severe. > -- > Paul Prescod
I would disagree. ROP degenerates OOP so much that it ceases to be OOP. The whole idea behind OOP is that you have objects, and you create methods(verbs) on the objects. In ROP, you have only four verbs (methods). You lose the whole intent of OOP when you do this. If you tell a developer "OK, use Java but every object is only allowed to have four methods: Get, Put, Post and Delete" what you would end up with isn't anything like a good OO design. SOAP/RPC is much more closely aligned with OO. It comes out of "Component Based" architectures like CORBA and DCOM. It's easy for developers to make the jump from objects/methods to Web services/operations. There are lots of tools that automatically do the mapping between OOPLs and SOAP/RPC. I have yet to see a tool that does this for REST. With REST you can't just take any Java/C++/C# Object and turn it into an easily used network accessible "thing". An analogy might help here. Saying ROP is like a degenerate case of OOP is like saying Structured Programming is a degenerate case of OOP. Sure you can use C++ or Java and do structured programming, but then you're not doing OOP. Structured Programming and OOP are different paradigms. I maintain that OO and RO are different development paradigms. I would love to be wrong though, it would make things a whole lot easier. Toivo > -----Original Message----- > From: inthedarkplace > > > This seems like the wrong tack to take. On close analaysis, Resource > Oriented Programming is far more object oriented than SOAP/RPC. In > fact there's a strong case to be made that ROP is a degenerate case > of OOP, simplified and constrained in order to meet the scalability > requirements of internet class applications. > > > -itdp > >
----- Original Message ----- > > With REST you can't just take any Java/C++/C# Object and turn it into an > easily used network accessible "thing". With RPC, you can't just take any file system/database/directory service and turn it into an easily used, interoperable network accessible 'thing'.
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > > ----- Original Message ----- > > > > With REST you can't just take any Java/C++/C# Object and turn it into an > > easily used network accessible "thing". Actually you can and I do it all the time. I have automated tools which can automagically generate the REST code given an object's class. Also note that SOAP services are stateless. By definition they are not objects. Resources have states and they expose methods (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which constitute behavior. After having done a lot of SOAP and REST hacking it's evident to me and my team that REST is far more object oriented than SOAP. In REST you work with real objects, in SOAP you're essentially working with a class that defines arbitrary static methods. > With RPC, you can't just take any file system/database/directory service and > turn it into an easily used, interoperable network accessible 'thing'.
"S. Mike Dierken" wrote: > > ----- Original Message ----- > > > > With REST you can't just take any Java/C++/C# Object and turn it into an > > easily used network accessible "thing". > > With RPC, you can't just take any file system/database/directory service and > turn it into an easily used, interoperable network accessible 'thing'. These terms are pretty vaguely defined so let's be concrete: using Visual Studio.NET and most other RPC-oriented Web services toolkits, you can take an object and turn it into a service automatically ONLY IF the object has only static methods -- in other words if it uses a procedural, not object oriented, model. -- Paul Prescod
On Fri, Aug 30, 2002 at 06:17:59PM -0000, bhaugen32 wrote: > But the interesting issues in this present thread are not about the > final contract, but the fulfillment of contractual commitments. > > In other words, in the contract you committed to some future > behavior. When you send a message concerning that future behavior, it > will be governed by the contractual commitment. > > So the message that is governed by the contractual commitment may be > clear in its own contents, but it is not independent of the > commitment in its business effect. > > Therefore should it reference the commitment, or include it inline? I'd say the reference. I just talked to my wife (a lawyer) about this, and what we discussed pretty much jives with what I've said in this thread. Basically, if one contract depends on some detail of another, then either a) reference it if the referencing system can guarantee that dereferencing it will always produce the identical contract, or b) include the other contract as an attachment. She said it's easier to include as an attachment than to try to cut and paste chunks out of it, because some context may get lost in doing so. The difference there from my previous statements, is that it's safe to use a reference in the case where the details of the other contract matter, iff it can be guaranteed to always refer to exactly that contract. Maybe some examples would help ... MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Still in my enthusiastic newbie mode:
IO note that W3C's Technical Architecture group seems to have blessed RST
big-time in "Architectural Principles of the World Wide Web" at:
http://www.w3.org/TR/2002/WD-webarch-20020830/
<quote>
As mentioned in the introduction, the Web is designed to create the
large-scale effect of a shared information space that scales well and
behaves predictably. The architectural style known as Representational
State Transfer [REST] encapsulates this notion of a shared information
space.
</quote>
But I keep searching for implementations of RESTful web service --
preferably in Python. Could someone elaborate on REST's relation to the
"Simple Web Services API" at:
http://aspn.activestate.com/ASPN/WebServices/SWSAPI/spec
And point some other examples than (SOAPy) Amazon and Google? I'm my own
boss, so I won't fire me if I don't use SOAP.
Sam Hunting
eTopicality, Inc.
---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)
Topic map consulting and training: www.etopicality.com
Free open source topic map tools: www.goose-works.org
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------
Oops, missed this. On to the examples ... > > In the stateless case, you could just take the offending message to > > court and leave everything else behind, because its meaning is > > independant of any conversation it may have been sent in. > > Depending on what you mean, that gets tricky. > Simple case: shipment notification is dependent on order line which > it purports to fulfill. Claims of non-fulfillment would need both > the shipment notification and the order line. Ok, I see what you're getting it. It's not any profound issue, it's just a misinterpretation of what I was saying about only needing to take one message to court. In fact, you always need to take two things to court; the contract, and proof of breach. My point, which was obviously poorly stated, is that proof of breach can be demonstrated with a single message (the shipment notification, as I understand what one is). Of course, proof of a entering into a contract should also be able to be demonstrated with a single message too. > More complex case: non-fulfillment is covered by a long term > contract which provides penalties. So now the long-term contract > clause must be stated as well. Ok, but the messages that establish expectation of fulfillment, and notify about fulfillment both mean the same thing independant of the details of any contract that exists. But its meaning *does* depend upon the existence of such a contract, so you'd want to reference it. Presumably any standard format for this info would have a way to reference one or more non-fullfillment contracts - is that the case? > Are these ideas relevant to the issue raise? Yep. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker > I just talked to my wife (a lawyer) about this, and what we discussed > pretty much jives with what I've said in this thread. Please pass on thanks to your wife. > Basically, if one > contract depends on some detail of another, then either a) reference it > if the referencing system can guarantee that dereferencing it will > always produce the identical contract, or b) include the other contract > as an attachment. She said it's easier to include as an attachment than > to try to cut and paste chunks out of it, because some context may get > lost in doing so. That's different from the situation I thought we were discussing. (Although some of the same principles would apply.) The two situations: 1. One contract refers to another contract (as above). 2. Messages about contract fulfillment events (e.g. deliveries of goods and services or payments) refer to governing contract clauses (as I thought we were discussing). The usual practice with deliveries is to refer to the governing contract (e.g. purchase order) by order ID (maybe + line number), not to attach the whole PO. I expect the same would work for REST. > The difference there from my previous statements, is that it's safe to > use a reference in the case where the details of the other contract > matter, iff it can be guaranteed to always refer to exactly that > contract. Yes, and don't you think something like Paul's reference format (URI + hash) is the way to do it? > Maybe some examples would help ... Coming up... -Bob Haugen
Mark Baker wrote: > In fact, you always need to take two things to court; the contract, > and proof of breach. My point, which was obviously poorly stated, is > that proof of breach can be demonstrated with a single message (the > shipment notification, as I understand what one is). Of course, proof > of a entering into a contract should also be able to be demonstrated > with a single message too. A. "Proof" is too strong a word; "evidence" is as good as you get. B. A contract is an agreement between at least two parties. Evidence of binding a contract using an electronic offer-acceptance protocol might require at least two messages: one with the offer, signed by the offerer; another with the acceptance, referring to the offer (with URI + hash), signed by the acceptor. If the acceptance message contained the whole canonical representation of the offer plus the hash plus the acceptance element plus the acceptor's digital signature, then maybe one message would do. But there are reasons not to do that: for example, the timing of messages, rules for contract formation, receipt acknowledgments, etc. may also be important depending on how formal it's worth being. Likewise the evidence of performance of committed events is also stronger if both parties agree that the event was performed as notified. (Which again requires at least two messages.) For example, it's much easier to send a shipment notification than to actually deliver the goods in good shape and time. The business protocol needs to allow for receiving discrepancies. All of the above are reasons why business deals are conversations where almost every statement refers to previous statements. And requires the previous statements for complete interpretation of its meaning-in-context. It's like there's at least two levels of meaning: 1. the content of the message - the values of its elements, and 2. its residual effect on the business deal in which it is embedded. I have always taken the REST "stateless" rule in sense #1. In other words, put all the element values plainly inline the message. -Bob Haugen
Sam Hunting wrote: > > ... > > But I keep searching for implementations of RESTful web service -- > preferably in Python. Could someone elaborate on REST's relation to the > "Simple Web Services API" at: > > http://aspn.activestate.com/ASPN/WebServices/SWSAPI/spec No relationship. That was a project I did for a customer unrelated to REST and before I understood much REST. > And point some other examples than (SOAPy) Amazon and Google? I'm my own > boss, so I won't fire me if I don't use SOAP. Roughly speaking, systems which make good use of HTTP and URIs are REST systems. So for instance your favorite travel site probably uses REST to an extent. Or your favorite discussion group. For various practical reasons many sites fall short of REST perfection but that's true with any paradigm. Reality does intervene so sometimes otherwise REST-ful services will abuse URIs or cookies etc. In terms of combinations of REST and XML, most of them are read-only. Public examples include: * the Xoomle variant of the Google API (which is basically a realization of [1]). * the entire RSS subset of the Web (which constitutes a sophisticated information system in its own right) * the Amazon REST (not SOAP) API * the SOAPBuilders test reporting API [1] http://www.xml.com/pub/a/2002/04/24/google.html -- Paul Prescod
Paul Prescod wrote: >>And point some other examples than (SOAPy) Amazon and Google? I'm my own >>boss, so I won't fire me if I don't use SOAP. well, i think groups.yahoo.com is quite RESTful, in a read-only way. as was egroups before it. an example of the 'reality' paul mentioned would be the way it sticks ads in when you're viewing posts. also look at http://nntp.x.perl.org/ . that's a nice interface to an archive of all perl mailing lists. i think it's RESTful as well, in a read-only way.
hie all,
I know that this subject has already been discussed, but to summarize:
How to represent hierarchical resources restfully?
Here is the structure:
/root
+-- group 1
| +-- attribute 1.a
| |
| +-- element 1.1
| | +-- attribute 1.1.a
| | |
| | +-- attribute 1.1.b
| |
| +-- element 1.2
| | +-- ....
| +-- ...
|
+-- group 2
| |
| + element 2.1
| |
| +-- ...
|
+-- ...
This could be an ldap directory (e.g address book) for example, or an 'ls
-R' of an FTP server. The root url will be : http://my.server.com/root
I think there is some points to consider:
* What this url should return: some information about the resource, or a
listing of its contents (groups). If a listing is allowed, this raise the
recursive issue. Is recursively restful. I thought about these solutions:
1. <root>
some information
<group1 xlink:href="url/to/group.1" />
<group2 xlink:href="url/to/group.2" />
...
</root>
2.a <root>
<group1>
<attribute1a>value</attribute1a>
<element11 xlink:href="url/to/element.1.1"/>
...
<group2>...</group2>
...
</root>
2.b <root>
<group1 attribute1a="value">
<element11 xlink:href="url/to/element.1.1"/>
...
<group2>...</group2>
...
</root>
3 <root>
<group1>
<attribute1a>value</attribute1a>
<element11>
<attribute11a>value</attribute11a>
</element11>
...
<group2>...</group2>
...
</root>
Note that they could be 3.b with attribute values as ``real" xml
attributes, but this difference (between 2.a and 2.b is an other debate). I
think the first solution is the more restful one. But I'd like to be able to
save the resources for a local access, and to avoid to have to save
multiples files, making links relatives, etc. This explain the 3rd solution
(the 2nd one is just un hybrid, which is not very useful :) The question is:
is it correct to make the 3rd solution available at
http://my.server.com/root?recursive=true or
http://my.server.com/root?recursive=2 where recursive=0 is the 1rst solution
and recursive=1 the second one.
* The other issue is: what should be the url to groups and elements (and
possibly attributes).
1. http://my.server.com/root/group1/element11
2. http://my.server.com/root?group=1&element=11
3. without the hierarchy http://my.server.com/root?attribute=11a
directly
and is an hybrid solution possible (e.g
http://my.server.com/root/group1?element=11, or
http://my.server.com/root/group1/element11?attribute=11a)
I think that the path form (1) is better for access, since the query one
(3) is better for search queries.
To be more concrete, suppose that groups are contacts 'groups (which
attribute is a description), elements are contacts and attributes are mail
address, phone number, name and description. The goal is to allow the access
to coordinates, groups or contacts (e.g a ldap gateway) and to save them to
a single file (see first point) to local access.
Separate the addressing from the XML representation. The difference between <group1 attribute1a="value"> and <group1><attribute1a>value</attribute1a></group1> is a personal preference - unless you are conforming to someone else's schema/structure. If the goal is 'to allow the access to coordinates, groups or contacts (e.g a ldap gateway) and to save them to a single file (see first point) to local access' then your addressing doesn't have to directly mimic the storage structure - the addressing will reflect the needs of getting a lot or small amount of information and preserving links to other information. That is where your recursive=2 comes from (I'd use 'depth=2' as a name by the way, just for fun and DAV mimicry). > * The other issue is: what should be the url to groups and elements (and possibly attributes). You might try using local references (uri references, or 'fragments') via the '#' url character. If generating a representation of an attribute is moderately expensive, it may be better to return the whole element and allow addressing into this representation. http://my.server.com/root?group=1&element=11#attribute11a This returns a represenation of http://my.server.com/root?group=1&element=11 and the local application needs to find the #attribute11a. ----- Original Message ----- From: "Yannick Loiseau" <yloiseau@...> To: <rest-discuss@yahoogroups.com> Sent: Sunday, September 01, 2002 3:49 PM Subject: [rest-discuss] Hierarchical resources > hie all, > I know that this subject has already been discussed, but to summarize: > How to represent hierarchical resources restfully? > Here is the structure: > > /root > +-- group 1 > | +-- attribute 1.a > | | > | +-- element 1.1 > | | +-- attribute 1.1.a > | | | > | | +-- attribute 1.1.b > | | > | +-- element 1.2 > | | +-- .... > | +-- ... > | > +-- group 2 > | | > | + element 2.1 > | | > | +-- ... > | > +-- ... > > This could be an ldap directory (e.g address book) for example, or an 'ls > -R' of an FTP server. The root url will be : http://my.server.com/root > I think there is some points to consider: > * What this url should return: some information about the resource, or a > listing of its contents (groups). If a listing is allowed, this raise the > recursive issue. Is recursively restful. I thought about these solutions: > 1. <root> > some information > <group1 xlink:href="url/to/group.1" /> > <group2 xlink:href="url/to/group.2" /> > ... > </root> > > 2.a <root> > <group1> > <attribute1a>value</attribute1a> > <element11 xlink:href="url/to/element.1.1"/> > ... > <group2>...</group2> > ... > </root> > 2.b <root> > <group1 attribute1a="value"> > <element11 xlink:href="url/to/element.1.1"/> > ... > <group2>...</group2> > ... > </root> > > 3 <root> > <group1> > <attribute1a>value</attribute1a> > <element11> > <attribute11a>value</attribute11a> > </element11> > ... > <group2>...</group2> > ... > </root> > > Note that they could be 3.b with attribute values as ``real" xml > attributes, but this difference (between 2.a and 2.b is an other debate). I > think the first solution is the more restful one. But I'd like to be able to > save the resources for a local access, and to avoid to have to save > multiples files, making links relatives, etc. This explain the 3rd solution > (the 2nd one is just un hybrid, which is not very useful :) The question is: > is it correct to make the 3rd solution available at > http://my.server.com/root?recursive=true or > http://my.server.com/root?recursive=2 where recursive=0 is the 1rst solution > and recursive=1 the second one. > > * The other issue is: what should be the url to groups and elements (and > possibly attributes). > 1. http://my.server.com/root/group1/element11 > 2. http://my.server.com/root?group=1&element=11 > 3. without the hierarchy http://my.server.com/root?attribute=11a > directly > > and is an hybrid solution possible (e.g > http://my.server.com/root/group1?element=11, or > http://my.server.com/root/group1/element11?attribute=11a) > > I think that the path form (1) is better for access, since the query one > (3) is better for search queries. > > To be more concrete, suppose that groups are contacts 'groups (which > attribute is a description), elements are contacts and attributes are mail > address, phone number, name and description. The goal is to allow the access > to coordinates, groups or contacts (e.g a ldap gateway) and to save them to > a single file (see first point) to local access. > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
Has anybody played with and/or analyzed Moveable Type's TrackBack feature? http://www.movabletype.org/docs/mtmanual_trackback.html It appears to support URI-based conversations. It claims to use REST: "TrackBack uses a REST model for its pings in order to ensure that each TrackBack item has a unique URL (by the numeric ID of the TrackBack item)." "Sending a ping A request is made through HTTP GET to the ping URL..." But then appears to use GET for a side effect: "When a ping is sent to a TrackBack item on your site, in addition to saving the ping in the Movable Type database, the system updates an RSS feed for the TrackBack item." Did I misunderstand?
I don't believe that the REST style makes any recommendation regarding how resources should be represented as URIs. There is no "correct" answer, or even a "best" answer. It all depends on your application. Doctrine says: URIs should be considered as opaque. A URI like http://my.server.com/x742q/32ij5 might refer to "sub-element foo of sub-element bar of element xyzzy". Or not. Certainly I don't recommend explicit opaqueness as the Right approach in all cases. Embedding meaning in URIs can often be helpful, and improve application performance by avoiding the need for extra lookups in your code. But this is outside of the scope of REST. Appropriate punctuation (/ and ? and &) may be driven by your application as well. Is the structure pre-defined, or does it grow and change over time? Is the concept of searching even relevant, and can searches be made over sub-trees as well as the whole hierarchy? Are attributes defined from a fixed set, or are these variable as well? There's no right answer here. -Jason --- In rest-discuss@y..., "Yannick Loiseau" <yloiseau@f...> wrote: > How to represent hierarchical resources restfully? > [lengthy post snipped]
Hello, I would like to know if anyone has considered how multiple web services could be composed and coordinated together under the REST architecture. Specifically: 1. What form would the representation of service composition take? 2. How to handle dynamic binding of multiple services within a session, given that REST is a stateless and asynchronous model? 3. How to automate service discovery, invocation (possibly using ontology-aware agents?), and execution completion notification, with provision for graceful recovery from a failed composite service execution? In a simple composition model, a client (or possibly a coordinator service) would be responsible for obtaining URLs of the service providers, invoking them in some order, and converting responses from one provider into a parameter that would go into the request message to the other providers. Some way of specifiying how to tranform between representations would be necessary. Also, this means that the client (or coordinator) would be responsible for monitoring the state of the service composition process. What are the kinds of compositions that would work best under REST?
On Monday, September 2, 2002, at 06:34 PM, jmay wrote: > Certainly I don't recommend explicit opaqueness as the Right approach > in all cases. Embedding meaning in URIs can often be helpful, and > improve application performance by avoiding the need for extra lookups > in your code. But this is outside of the scope of REST. By definition. But definitions are created by people, and people are fallible. Opaqueness is dogma, but it's not necessarily good engineering. I don't want to start another philosophical debate, but suffice to say that there are times when embedding information in URI is the path of least resistance (at worst) or perhaps even the best solution to the problem. Dogma evolves, and is (hopefully) eventually replaced by engineering and best practices. jb
Where do you get the idea that SOAP services are stateless? I don't think there is any mention of state or statelessness in the SOAP spec. I think a SOAP service can be just as statefull as a REST resource. Am I missing something here? I'm also not sure what you mean by "By definition [SOAP Services] are no objects". I don't want to get argument about what an object is or isn't, but SOAP services are something you can use for doing object oriented decomposition of a problem, whether or not its stateless. Toivo > -----Original Message----- > From: inthedarkplace [mailto:inthedarkplace@...] > > > > > > With REST you can't just take any Java/C++/C# Object and turn it > into an > > > easily used network accessible "thing". > > Actually you can and I do it all the time. I have automated tools > which can automagically generate the REST code given an object's > class. Also note that SOAP services are stateless. By definition they > are not objects. Resources have states and they expose methods > (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which constitute > behavior. After having done a lot of SOAP and REST hacking it's > evident to me and my team that REST is far more object oriented than > SOAP. In REST you work with real objects, in SOAP you're essentially > working with a class that defines arbitrary static methods.
Toivo \"Deutsch\" Lainevool wrote: > > Where do you get the idea that SOAP services are stateless? I don't > think there is any mention of state or statelessness in the SOAP spec. The SOAP specification is almost completely descriptive, not prescriptive. In other words, it doesn't provide enough guidance to actually build applications that interoperate. Therefore we have to look into the tools for the true definition of "what is SOAP". * http://www.prescod.net/rest/rest_vs_soap_overview/#section_4.4 > I'm also not sure what you mean by "By definition [SOAP Services] are no > objects". I don't want to get argument about what an object is or > isn't, but SOAP services are something you can use for doing object > oriented decomposition of a problem, whether or not its stateless. But are there SOAP clients and server toolkits that make it practical to do object oriented decomposition, including the creation and destruction of objects and the referencing of one object from another? -- Paul Prescod
On Sunday, September 1, 2002, at 05:17 PM, qchong wrote: > In a simple composition model, a client (or possibly a coordinator > service) would be responsible for obtaining URLs of the service > providers, invoking them in some order, There's the rub --- appropriate order to method invocation implies a stateful model. My suspicion --- though I haven't been able to prove it in a generic and formal way --- is that every stateful composition can be remodeled as a series of generic operations on a larger number of resources, mostly eliminating the compositional complexity. Think UNIX pipes / dataflow composition instead of OOP... jb
Toivo,
I'm sorry Toivo, I understand your confusion I think. It stems from
the way the words 'state' and 'stateful' have been so hopelessly
overloaded.
In REST it is very clear what state means. You have resources located
at URIs and performing a GET on these resources retrieves a
representation of their state. There is no analogy to SOAP.
As Paul hinted earlier, a SOAP service is nothing but a bunch of
static methods being called through XML over HTTP. There is no
fundamental notion of state. SOAP can maintain state through cookies
and similar mechanisms but this is a poor substitute.
Why is this important?
This debate was originally about which methodology was more object
oriented. I was trying to demonstrate that REST is far more object
oriented than SOAP ever will be.
Here are my thoughts on REST and Resource Oriented Programming. This
email is very long so don't read it if you're in a hurry :)
1) Resources are objects. They expose methods (DoGet, DoPut,
DoDelete, DoPost, DoOptions, and DoTrace) which define a behavior and
they possess a well-defined and meaningful state.
2) Because all resources expose the same five methods polymorphism is
implicit. If you define a type of user and I want to retrieve
information about your type of user I call GET url($User). If I want
to update the representation of that user I call PUT url($User). If
later, Idecide to take your user resource type and extend it by
adding fields then the API does not change. To read the new user
subclass you call GET. To update it, you call PUT.
3) The five methods (discounting HEAD) exposed by HTTP can
collectively describe any given set of traditional OO methods. The
transformation from OO methods to HTTP methods can be automated to a
large extent. Here is the general algorithm I use:
3.1) Retrieve all accessor methods from the object which are of
the form 'getXXX()'. The set of all accessor methods can be described
by the single HTTP GET method.
3.2) Retrieve all mutator methods from the object which are of
the form 'setXXX()'. The set of all mutator methods can be described
by the single HTTP PUT method.
3.3) If the object is a collection, search for all methods of the
form 'Add(Object o)'. Based on the result of 3.1 wrt to 'o' for each
add method, then each method of the form Add(Object) can be described
by the single HTTP POST method.
3.4) Repeat step 3.3, but instead searching for Remove(Object)
methods which will be mapped to corresponding HTTP DELETE methods.
3.5) All methods which ask a question about the state of the
object can be safely ignored. Eg methods of the form IsXXX. Instead,
clients can simply retrieve the state of the object and perform
queries directly. Similarly, all methods which perform calculations
based on the state of the object (eg Circle.CalculateArea()) can be
safely ignored. Let the client perform calculations directly against
the state representation.
3.6) Examine all remaining methods. Any method which expresses
behavior must be decomposed into a resource transfer problem. The
classic example (that I continually encounter in my adventures in
REST) is the ShoppingCart. In OOP-land, it is common to have a
ShoppingCart class which exposes a CheckOut method. In ROP-land, you
cannot expose such a method. (You could using HTTP POST but you
shouldn't). Instead, the behavior of the CheckOut method must be
expressed by creating a new Order resource and referring to the
existing ShoppingCart resource. Thus the ShoppingCart.CheckOut method
is replaced by POSTing an OrderCollection resource to create a new
OrderResource. This is just an example.
This last step, step 3.6, cannot be automated and it's what makes
designing RESTful services so difficult IMO. Many developers do not
wish to take the time to perform the decompisition of behavioral
methods so they simply expose them directly. This often leads to many
problems. But this is the crux of REST: decomposing an API into a
resource manipulation problem and while I can't prove it, it's my
belief that all APIs can be completely decomposed into a resource
manipulation problem.
(BTW, consider the SOAP equivalent to checking out a shopping cart.
Because there is no real object model, the client usually ends up
calling a method CheckOut and passing a UUID of some sort or a simple
struct. This is hardly OOP--at best it is akin to "object-based" C
programming).
You wrote: 'With REST you can't just take any Java/C++/C# Object and
turn it into an easily used network accessible "thing".'
In fact, this is exactly what I do. Given a User class I can generate
a UserResource class. Given a UserCollection class I can generate a
UserCollectionResource. Eg...
User extends BusinessObject ---> UserResource extends HttpResource
get/set Username void DoGet()
get/set Email void DoPut()
get/set Realname void DoDelete()
void DoOptions()
The tools exist if you're willing to write them.
4) When constructing a restful webservice it is necessary to clearly
define what types of resources will exist and what operations may be
performed upon these resources. This is done by examining the nouns
in your problem domain and constructing resources that correspond to
your nouns. This is the process of object discovery--it is the same
process performed when constructing traditional object oriented
solutions. This suggests there is indeed a strong relationship
between resource oriented programming and object oriented
programming.
5) Now this is just a theory of mine and I need to explore it more,
but I suspect that what you call Resource Oriented Programming is
akin to the logical completion of what has been traditionally called
Object Oriented Programming. The "goal" of OOP is to encapsulate data
and behavior into a single logical component. Components then
interact by passing messages back and forth. Encapsulation works
because it allows complexity to be hidden (encapsulation is also
known as information hiding) and so clients only need to know about
the messages that go into and come out of a component and the state
of that component. So this is the ***fundamental value proposition of
encapsulation and OOP**: the amount of information a component A
needs to know about a component B is reduced to the set of B's
operations (the verb's that can be carried out against B) and B's
state.
Now let's return to ROP.
The "essence" of Resource Oriented Programming is to reduce the
number of verbs in a system to a constant N (where N = 5 for HTTP) by
introducing many nouns. Agents in an ROP system interact by applying
these N verbs to this matrix of nouns. This is the **fundamental
value propisition of REST**: the amount of information a component A
needs to know about a component A has been reduced to B's state (and
the XML vocabulary used to describe that state).
It is a well known fact that loose coupling is the holy grail of
extremely complex (distributed) apps. The less two components know
about one another the better. Therefore I'd like to say that ROP
supercedes OOP because it has significantly reduced the amount of
information two components must know about one another by placing a
limit on the verbs a components can expose and requiring all
components to expose the same verbs. Therefore ROP-systems
**increase** loose-coupling and encapsulation. I'd even go so far as
to say that a well-defined ROP-system can be more "object-oriented"
than the analagous OOP-system.
Anybody who's ever built a large distributed app based on RPC and RMI
should be able to immediately appeaciate the super-encapsulation
achieved by ROP. Remember the three most common problems with RPC/RMI:
1) Interface Fragility. Component A needs to add or remove a
parameter to a method. When this happens, all components which depend
on Component A's interface must be updated to obtain its new
interface.
2) Inconsistency. (Unbounded Complexity). In RPC/RMI systems the
same logical operation can go by many different names. For example,
Component A might expose a Destroy() operation, Component B might
expose a Finalize() operation, and Component C might expose a Delete
() operation. This makes it very difficult for these components to be
tied together into a coherent solution by a virgin third party
because the virgin third party must take time to understand and
handle the slightly different interfaces of each. This should be
pretty clear: as the number of components grow the number of verbs in
the system approach infinity and so it becomes impossible for
newcomers to understand all the verbs exposed by the system and
therefore understand what the system can do. This completely destroys
what Sam Ruby calls "Manufactured Serendipity."
(I really can't stress the phenomenon of Manufactured Serendipity
enough. This is, I believe, the --point-- of the web. When you hide
information behind SOAP endpoints that information might as well not
be there. When you assign URLs to information it becomes possible for
virgin thirdparties to use the system in ways you never dreamed of
for example Google can now index that information (since it has URL)
and others can use tools like XInclude, XSLT, etc to manipulate that
information).
3) Dynamic discovery. No matter what Microsoft et. al. may tell
you, true dynamic discovery is impossible with RPC because every RPC
service exposes its own set of methods and it is impossible to know
what these methods mean. There's no way a machine can look
at 'RetrievePurchaseOrder(Long poID)' and havy any clue what that --
means--.
That's just off the top of my head but those are three main flaws
I can think of when it comes to RPC/RMI system. Now look at each one
and apply ROP. 1 and 2 disappears because you no longer have
specialized interfaces -- all components expose the same verbs. 3
kind of disappears because these universal verbs have a well-defined
meaning. If a machine knows that the resource located at
http://host/purchase-orders/3424242 is a type of purchase order then
it can infer that executing the GET method against that URL will
retrieve a representation of that purchase order. In this case it's
clear that the data backup problem becomes trivial to solve in
RESTful services.
Toivo, hopefully at this point I've convinced you somewhat why I
think ROP is far more object oriented than RPC and in fact may be
more object oriented than OOP (as if that makes any sense). Also I
can honestly say that it's been my experience that, given a well-
defined object model to a business app, it's easier for me to devise
a RESTful webservice than a SOAP webservice which exposes that object
model.
(continued in ROP vs RPC vs OOP pt 2)
- itdp
--- In rest-discuss@y..., "Toivo \"Deutsch\" Lainevool"
<tlainevool@n...> wrote:
> Where do you get the idea that SOAP services are stateless? I don't
> think there is any mention of state or statelessness in the SOAP
spec.
> I think a SOAP service can be just as statefull as a REST
resource. Am
> I missing something here?
>
> I'm also not sure what you mean by "By definition [SOAP Services]
are no
> objects". I don't want to get argument about what an object is or
> isn't, but SOAP services are something you can use for doing object
> oriented decomposition of a problem, whether or not its stateless.
>
> Toivo
>
> > -----Original Message-----
> > From: inthedarkplace [mailto:inthedarkplace@y...]
> > > >
> > > > With REST you can't just take any Java/C++/C# Object and turn
it
> > into an
> > > > easily used network accessible "thing".
> >
> > Actually you can and I do it all the time. I have automated tools
> > which can automagically generate the REST code given an object's
> > class. Also note that SOAP services are stateless. By definition
they
> > are not objects. Resources have states and they expose methods
> > (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which
constitute
> > behavior. After having done a lot of SOAP and REST hacking it's
> > evident to me and my team that REST is far more object oriented
than
> > SOAP. In REST you work with real objects, in SOAP you're
essentially
> > working with a class that defines arbitrary static methods.
Hi, all-- I'm wondering what people are thinking about the best ways to describe RESTful Web Services to clients and/or people, and how to access those descriptions. Shortly after I joined this list there was a good deal of discussion of Paul's WRDL effort ... and as I recall, there was some sense that perhaps we should be trying to improve WSDL instead of reinventing the wheel ... and then the whole topic seems to have been abandoned. Of course, I realize that there have been a variety of threads that touched on the description/documentation issue, but there has been no concerted effort to tackle it head-on for quite a while. I'm not sure whether that means everyone thinks it's too early to try to reach consensus, or people just aren't terribly concerned about it, or what. Yet it seems to me that being able to say "this is how you get information about resources" will help REST gain credibility (okay, the critics love it already, but will it play in Peoria?), while providing some valuable guidance for implementors. I'm not about to suggest that we immediately lurch into a WSDL-like standards-making effort. But might it not be a good idea to have a semi-coherent collection of best practices for service description? Or have I missed something? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Matt, I've developed to very simple XML applications I use to describe my RESTful webservices. RWS-RMS (Resource Model Space) describes what resources a webservice exposes and RWS-IL (Interface Language). You can have many webservices each with their own RWS-RMS document (explaining where their resources are located) but sharing the same RWS-IL document explaining what you can do to thos resources. I've spent the last 2 weeks tackling this problem of describing webservices and I don't think it's a problem that should be solved completely just yet. Reasons: 1) There's still no elegant way to describe an XML document's structure. I consider XML-Schema unusable and there's zero tool support for RELAX-NG. I've been investigating schematron which looks somewhat simpler but convoluted. 2) There are several issues with auto-proxy generation and REST, particularly: should it be done at all? I've been thinking a lot about it this. PaulPrescod has mentioned part of the value of REST is that it forces developers to acknowledge the network and deal with the kind-of-low-level-stuff like response codes. I think he may be right to an extent but I'm not sure. Between 1 and 2 it's hard to make much progress. For now, I'd agree with Roger: the best way to describe your webservice in a truly meaningful manner that will be accessible to the greatest number of people is to use HTML and document it. - itdp --- In rest-discuss@y..., Matt Gushee <mgushee@h...> wrote: > Hi, all-- > > I'm wondering what people are thinking about the best ways to describe > RESTful Web Services to clients and/or people, and how to access those > descriptions. Shortly after I joined this list there was a good deal of > discussion of Paul's WRDL effort ... and as I recall, there was some > sense that perhaps we should be trying to improve WSDL instead of > reinventing the wheel ... and then the whole topic seems to have been > abandoned. > > Of course, I realize that there have been a variety of threads that > touched on the description/documentation issue, but there has been no > concerted effort to tackle it head-on for quite a while. I'm not sure > whether that means everyone thinks it's too early to try to reach > consensus, or people just aren't terribly concerned about it, or what. > Yet it seems to me that being able to say "this is how you get > information about resources" will help REST gain credibility (okay, > the critics love it already, but will it play in Peoria?), while > providing some valuable guidance for implementors. > > I'm not about to suggest that we immediately lurch into a WSDL-like > standards-making effort. But might it not be a good idea to have a > semi-coherent collection of best practices for service description? > > Or have I missed something? > > -- > Matt Gushee > Englewood, Colorado, USA > mgushee@h... > http://www.havenrock.com/
> But then appears to use GET for a side effect: At first glance, I'd say this is probably okay, but I don't know all the circumstances. See below... Coincidentally enough, over the weekend Sam Ruby put up a rather contentious post on his weblog about that very subject here: http://www.intertwingly.net/blog/?entry=784 He says he phrased it that way to stir debate. :) Some cursory searching returns such remarks from Roy Fielding as: "Idempotence of methods is specifically not identical to idempotence of mathematical operations, as is explained in the spec. We did not attempt to make it more formal because the goal was to have the specification describe the interface as it was intended, not define it in such a way that only static resources could be implemented." [1] "The requirement is that "the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval." It does not require that no side-effects occur, nor even that the side-effects not be visible within the representation of the resource provided in the response." [2] This debate has come up numerous times, but I couldn't find a RESTWiki [3] entry that directly addresses this issue. Is there one? [1] http://www.xent.com/pipermail/fork/2001-July/001946.html [2] http://www.xent.com/pipermail/fork/2001-July/001974.html [3] http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage
Jeffrey Winter wrote, > Coincidentally enough, over the weekend Sam Ruby put up a > rather contentious post on his weblog about that very subject here: > > http://www.intertwingly.net/blog/?entry=784 > > He says he phrased it that way to stir debate. :) Interesting ... IMO RFC 2616 9.1 is very confusing. It talks about side-effects, but doesn't clearly indicate whether those effects are effects on the server or effects on the client. I'm reasonably sure that the primary intention was only to refer to side-effects on the server (if nothing else this would be consistent with the way "idempotent" is used in the context of ONC RPC), and that the client-visible results of a GET and any client-side side-effects are irrelevant. However, this is somewhat confused by the discussion of "idempotent sequences of methods", However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence. where "yields a result" seems to be refering to effects on the client. That can't be right tho', because if it were, DELETE wouldn't be idempotent: even tho' the effect of multiple DELETEs of the same resource is the same as just one on the server, it's likely that the client-visible result would differ: a 200 for the first invocation and 404s subsequently. On the server-side-relevant-only interpretation, a GET can return different results on every invocation so long as no server-side state is mutated by the GETs themselves. There are quite a few ways that could happen: if there are multiple clients, one might POST concurrently with another GETing; or there might be out of band content updates; or the result of the GETs might be generated by some process which is not itself affected by the GET, eg. a clock or a random number generator. Clearly in these kinds of case care has to be taken with Expires: and Cache-Control:, but that shouldn't be a problem. For all that this is reasonably coherent and consistent, I've never yet been able to square it with the elaboration in the last sentence quoted above, For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence. For example, here's a sequence of methods which are each individually idempotent, GET /foo PUT /foo Intuitively this is the kind of case that the clause is intended to exclude: a sequence which is non-idempotent even tho' it's constituents are. If we reexecute the sequence, the result of the second GET will have been affected by the first PUT ... ... but hang on a minute: that's _only_ true with respect to client- visible results. If we're only paying attention to the effects of the sequence on the server, then this sequence is perfectly idempotent, and any number of reexecutions will have exactly the same effect as the first. In truth, paying attention only to server-side effects of idempotent methods, I've not been able to come up with a single example of a non-idempotent sequence. I'd be interested to know if anyone else can. If not, does that mean that client-visible results _do_ play a role in idempotency? In which case, whither PUT, DELETE and GETs which return non-constant results? Cheers, Miles
On Tue, Sep 03, 2002 at 09:46:18AM -0000, inthedarkplace wrote:
>
> I've developed to very simple XML applications I use to describe my
> RESTful webservices. RWS-RMS (Resource Model Space) describes what
> resources a webservice exposes and RWS-IL (Interface Language). You
> can have many webservices each with their own RWS-RMS document
> (explaining where their resources are located) but sharing the same
> RWS-IL document explaining what you can do to thos resources.
Interesting. How do I find out more about this?
> I've spent the last 2 weeks tackling this problem of describing
> webservices and I don't think it's a problem that should be solved
> completely just yet. Reasons:
>
> 1) There's still no elegant way to describe an XML document's
> structure. I consider XML-Schema unusable and there's zero tool
> support for RELAX-NG. I've been investigating schematron which looks
> somewhat simpler but convoluted.
Zero tool support for RELAX-NG? I guess it depends on what you mean by a
tool.
> 2) There are several issues with auto-proxy generation and REST,
> particularly: should it be done at all? I've been thinking a lot
> about it this. PaulPrescod has mentioned part of the value of REST is
> that it forces developers to acknowledge the network and deal with
> the kind-of-low-level-stuff like response codes. I think he may be
> right to an extent but I'm not sure.
>
> Between 1 and 2 it's hard to make much progress. For now, I'd agree
> with Roger: the best way to describe your webservice in a truly
> meaningful manner that will be accessible to the greatest number of
> people is to use HTML and document it.
I agree with the bulk of your argument, but not entirely with the
conclusion. Certainly, human-readable documentation is currently the
only sound basis for client-side development--and I would go even
farther than you, to say that there will probably *always* be a need for
it: maybe it's just my liberal-arts background talking, but as far as
I'm concerned, the notion of 'intelligent agents' crawling the web, and
finding and processing the right resources without human intervention is
science fiction (which means it has a 27.3% chance of coming true :-).
Even setting that dubious vision aside, there are those who would argue
that resources can/should be self-describing. To which I would answer
that 'self-description' is always relative to some context, and the
meanings expressed in any given information resource are more
context-dependent than most people realize. And even though users are
welcome to use resources as they see fit (that's the nature of the web,
after all), many people will find a prose description of the author's
ideas about the data to be valuable.
So, yes, we need to document our services in human-readable form, now
and in the foreseeable future. But I think 'use HTML and document it'
glosses over some important questions that are, if not resolvable, at
least discussable here and now. One in particular that concerns me--
and I think would be of value to many prospective RESTful developers
--is how to access the documentation for a web service. Since REST is
not a programming language, maybe it's inappropriate to compare it to
one, but I can't help thinking about the documentation conventions used
in, say, Java and Python. Developers know how to extract documentation
from any library they want to use, and even if the developer of that
library has completely neglected to describe anything, they can still
obtain the bare essentials of the API.
So suppose we had conventions for structuring the documentation for web
resources, and a conventional way of querying resources to obtain their
documentation? Wouldn't that be a good thing?
[ I've actually made a stab in the direction of developing such
conventions: in a demo I put together for a presentation back
in February, I wrote resource descriptions using Dublin Core
with embedded XHTML elements (e.g. <xhtml:p> inside
<dc:Description>), and to obtain the description you would use
the resource URI with a trailing '?' ... yes, it was a nasty hack.
Oh well ... ]
What are the obstacles to developing such conventions?
--
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/
> -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Tuesday, September 03, 2002 12:20 PM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] GET: Shades of Grey (was: TrackBack) > > In truth, paying attention only to server-side effects of idempotent > methods, I've not been able to come up with a single example of a > non-idempotent sequence. I'd be interested to know if anyone > else can. > If not, does that mean that client-visible results _do_ play > a role in > idempotency? In which case, whither PUT, DELETE and GETs which return > non-constant results? I have half a notion of how this problem (composition of idempotent methods is/isnot idempotent?) can be modeled in Alloy, and if no one comes up with a counter-example from experience, then perhaps I'll tackle it formally. Walden
On Tue, Sep 03, 2002 at 05:20:27PM +0100, Miles Sabin wrote: > For all that this is reasonably coherent and consistent, I've never yet > been able to square it with the elaboration in the last sentence quoted > above, > > For example, a sequence is non-idempotent if its result depends on a > value that is later modified in the same sequence. > > For example, here's a sequence of methods which are each individually > idempotent, > > GET /foo > PUT /foo > > Intuitively this is the kind of case that the clause is intended to > exclude: a sequence which is non-idempotent even tho' it's constituents > are. If we reexecute the sequence, the result of the second GET will > have been affected by the first PUT ... > > ... but hang on a minute: that's _only_ true with respect to client- > visible results. If we're only paying attention to the effects of the > sequence on the server, then this sequence is perfectly idempotent, and > any number of reexecutions will have exactly the same effect as the > first. Well, an important difference between a sequence and an individual invocation that I don't think you're taking into account, is that application state is held by the client. So between "GET /foo" and "PUT /foo", the data being transferred may change. For example, the client may be incrementing a counter. Certainly, from both a client and server perspective, that's non-idempotent. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > > This debate has come up numerous times, but I couldn't find a > RESTWiki [3] entry that directly addresses this issue. Is there one? > > [1] http://www.xent.com/pipermail/fork/2001-July/001946.html > [2] http://www.xent.com/pipermail/fork/2001-July/001974.html > [3] http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage > > There is now. http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq#line171 What about those pesky hit counters? REST systems have a safe and idempotent 'get' operation. So does HTTP. 'Safe' generally means it isn't intended to modify the resource (the sender isn't responsible for any problems), and 'idempotent' means repeating the operation ends up with the resource in the same state (it doesn't mean all the responses are always identical). This is a confusing point because a 'hit counter' accumulates the number of time an idempotent operation has occured - and often is visible within the representation of that resource - things change just by doing a GET! Horrors! There is of course no way to prevent this from mere architectural descriptions of the system. It is up to the server author to understand what will happen and what this implies. The REST approach guides designers away from this approach as a foundation to build functionality. It is still doable - but it has costs and problems that it should be avoided as a general approach.
Mark Baker wrote, > Well, an important difference between a sequence and an individual > invocation that I don't think you're taking into account, is that > application state is held by the client. So between "GET /foo" and > "PUT /foo", the data being transferred may change. For example, the > client may be incrementing a counter. Certainly, from both a client > and server perspective, that's non-idempotent. I see that. But suppose there's no state update on the client. There's an initial resource /foo on the server, and a fixed resource which the client PUTs. In that case, is, GET /foo PUT /foo an idempotent sequence or not? Cheers, Miles
I'm not sure, but I think that if the entity of the PUT is allowed to change as you repeat the sequence, then you are not testing idempotence. Doesn't 'repeat the operation' imply using the same arguments? Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Tuesday, September 03, 2002 1:08 PM > To: Miles Sabin > Cc: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Idempotent sequences > > > On Tue, Sep 03, 2002 at 05:20:27PM +0100, Miles Sabin wrote: > > For all that this is reasonably coherent and consistent, > I've never yet > > been able to square it with the elaboration in the last > sentence quoted > > above, > > > > For example, a sequence is non-idempotent if its result > depends on a > > value that is later modified in the same sequence. > > > > For example, here's a sequence of methods which are each > individually > > idempotent, > > > > GET /foo > > PUT /foo > > > > Intuitively this is the kind of case that the clause is intended to > > exclude: a sequence which is non-idempotent even tho' it's > constituents > > are. If we reexecute the sequence, the result of the second > GET will > > have been affected by the first PUT ... > > > > ... but hang on a minute: that's _only_ true with respect > to client- > > visible results. If we're only paying attention to the > effects of the > > sequence on the server, then this sequence is perfectly > idempotent, and > > any number of reexecutions will have exactly the same effect as the > > first. > > Well, an important difference between a sequence and an individual > invocation that I don't think you're taking into account, is that > application state is held by the client. So between "GET > /foo" and "PUT > /foo", the data being transferred may change. For example, the client > may be incrementing a counter. Certainly, from both a client and > server perspective, that's non-idempotent. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mathews, Walden wrote, > I'm not sure, but I think that if the entity of the PUT is > allowed to change as you repeat the sequence, then you are not > testing idempotence. Doesn't 'repeat the operation' imply > using the same arguments? That would be the usual reading of "idempotent", certainly. Cheers, Miles
On Tue, Sep 03, 2002 at 06:19:27PM +0100, Miles Sabin wrote: > I see that. > > But suppose there's no state update on the client. There's an initial > resource /foo on the server, and a fixed resource which the client > PUTs. In that case, is, > > GET /foo > PUT /foo > > an idempotent sequence or not? Sure, you can always construct a GET-followed-by-PUT (of the same URI) example that is idempotent, but that's not the point. The point is, as 2616 says; "However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent." And I showed an example where that was the case. It is clearly *not* the case for all sequenced uses of GET and PUT on the same URI, but that's ok, it doesn't need to be to make that statement in 2616 correct. I agree that RFC 2616 could be clearer here, but to me it seems pretty clear what it's intent is in talking about this stuff. For example, instead of "sequence of methods" in 8.1.2.2 it should say "sequence of requests". MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Actually, let me take that back. 8-) Let's say the example was; "2" <= GET /foo PUT "1" /foo i.e. GET returns "2", PUT sets value to "1". Obviously in the steady state, this sequence is idempotent, but it isn't on the first go round. Please ignore my other rants. I'm sick and my head hurts. 8-( MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
According to mydictionary, idempotence is a property of homogeneous functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent. We have to be careful about extending that model to fit the request/ response paradigm of REST. If anything, D is the domain from which representations are drawn and (D -> D) represents the mapping of a pre-state for a given resource to its post-state, and in that sense, the 'return' value of the function we're interested in means that the function is defined as a pair (PUT | POST | DELETE) /foo <representation> GET /foo So that the final get represents the function's value (i.e., the second 'D' in the mapping from D -> D). Other definitions of 'idempotent' refer to things like recursive inclusion of C header files; not very enlightening. Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Tuesday, September 03, 2002 1:50 PM > To: Mark Baker > Cc: Miles Sabin; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Idempotent sequences > > > Actually, let me take that back. 8-) > > Let's say the example was; > > "2" <= GET /foo > PUT "1" /foo > > i.e. GET returns "2", PUT sets value to "1". Obviously in the steady > state, this sequence is idempotent, but it isn't on the first > go round. > > Please ignore my other rants. I'm sick and my head hurts. 8-( > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote, > On Tue, Sep 03, 2002 at 06:19:27PM +0100, Miles Sabin wrote: > > I see that. > > > > But suppose there's no state update on the client. There's an > > initial resource /foo on the server, and a fixed resource which the > > client PUTs. In that case, is, > > > > GET /foo > > PUT /foo > > > > an idempotent sequence or not? > > Sure, you can always construct a GET-followed-by-PUT (of the same > URI) example that is idempotent, but that's not the point. So that sequence is idempotent? Even tho' the client-visible result will differ on a reexecution? OK, that's how I understand idempotent as it applies to individual methods. It's what I called the server-side- relevant-only interpretation, and I think it's the only one which is consistent with PUT and DELETE being idempotent. > The point is, as 2616 says; > > "However, it is possible that a sequence of several requests is non- > idempotent, even if all of the methods executed in that sequence are > idempotent." > > And I showed an example where that was the case. It is clearly *not* > the case for all sequenced uses of GET and PUT on the same URI, but > that's ok, it doesn't need to be to make that statement in 2616 > correct. No, that wasn't an example. You allowed the PUT entity to change between executions of the sequence. That means that the PUT isn't being used in an idempotent way, so a fortiori the sequence isn't idempotent. For the clauses about idempotent sequences to make any sense we'd need an example of a non-idempotent sequence of idempotent requests where any PUT entities stay the same from execution to execution. Like I said, I haven't been able to think of a single example. Can anyone else come up with one? Cheers, Miles
Mark Baker wrote, > Actually, let me take that back. 8-) > > Let's say the example was; > > "2" <= GET /foo > PUT "1" /foo > > i.e. GET returns "2", PUT sets value to "1". Obviously in the steady > state, this sequence is idempotent, but it isn't on the first go > round. Err ... but if we're only paying attention to the state on the server-side, then this isn't a problem. The effect on the server of multiple executions of that sequence is exactly the same as the execution of just one. The effect on the client changes from execution to execution, sure, but that had better *not* make the sequence non-idempotent, otherwise, DELETE /foo (200 OK) DELETE /foo (404 Not Found) would imply that DELETE is non-idempotent. > Please ignore my other rants. I'm sick and my head hurts. 8-( Is that an effect of tying to make sense of 9.1 or something else? ;-) Cheers, Miles
Mathews, Walden wrote, > According to mydictionary, idempotence is a property of homogeneous > functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent. > We have to be careful about extending that model to fit the request/ > response paradigm of REST. If anything, D is the domain from which > representations are drawn and (D -> D) represents the mapping of a > pre-state for a given resource to its post-state, and in that sense, > the 'return' value of the function we're interested in means that > the function is defined as a pair > > (PUT | POST | DELETE) /foo <representation> > GET /foo > > So that the final get represents the function's value (i.e., the > second 'D' in the mapping from D -> D). > > Other definitions of 'idempotent' refer to things like recursive > inclusion of C header files; not very enlightening. I think the first definition is just fine. The function here is the request, and the domain and range are states of the server (feel free to replace "server" with "resource" throughout if you'd prefer, it shouldn't make any difference). Let's write s, s' for states of the server, g(s) and p(s) for, GET /foo and, PUT /foo (with a fixed PUT entity) respectiverly, applied to the server in state s. The 9.1 definitions imply that, g(s) = s hence, g(g(s)) = g(s) because GET is both safe and idempotent. OTOH, the imply that, p(s) = s' (where typically s' != s) because PUT isn't safe, but, p(s') = s' because PUT is idempotent, and hence, p(p(s)) = p(s) DELETE will be similar to PUT. One thing to note here is that what the client sees isn't mentioned at all: all the above is defined in terms of server states and functions mapping server states to server states. Hmm ... spelt out this way, there's a trivial proof that all sequences of idempotent requests are idempotent sequences. That means that either there's something wrong with spelling things out this way (in which case, what?), or there's something not quite right with 9.1 Thoughts? Cheers, Miles
We're on the same wavelength. The only thing I wasn't sure about was whether everyone agreed on what the 'function' relates. My explicit GET was intended to mean exactly what you have explained, namely that the function is from resource pre-state to post-state, and the latter always visible to client. In my two-method model of function, I should have included no-op in the list of alternates for mutators, so that *nothing* followed by a GET is also a 'function'. What's the trivial proof? I also sense that it's easy, but if it's that easy, then Alloy won't help. Walden > -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Tuesday, September 03, 2002 2:37 PM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Idempotent sequences > > > Mathews, Walden wrote, > > According to mydictionary, idempotence is a property of homogeneous > > functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent. > > We have to be careful about extending that model to fit the request/ > > response paradigm of REST. If anything, D is the domain from which > > representations are drawn and (D -> D) represents the mapping of a > > pre-state for a given resource to its post-state, and in that sense, > > the 'return' value of the function we're interested in means that > > the function is defined as a pair > > > > (PUT | POST | DELETE) /foo <representation> > > GET /foo > > > > So that the final get represents the function's value (i.e., the > > second 'D' in the mapping from D -> D). > > > > Other definitions of 'idempotent' refer to things like recursive > > inclusion of C header files; not very enlightening. > > I think the first definition is just fine. The function here is the > request, and the domain and range are states of the server (feel free > to replace "server" with "resource" throughout if you'd prefer, it > shouldn't make any difference). > > Let's write s, s' for states of the server, g(s) and p(s) for, > > GET /foo > > and, > > PUT /foo (with a fixed PUT entity) > > respectiverly, applied to the server in state s. The 9.1 definitions > imply that, > > g(s) = s > > hence, > > g(g(s)) = g(s) > > because GET is both safe and idempotent. OTOH, the imply that, > > p(s) = s' (where typically s' != s) > > because PUT isn't safe, but, > > p(s') = s' > > because PUT is idempotent, and hence, > > p(p(s)) = p(s) > > DELETE will be similar to PUT. > > One thing to note here is that what the client sees isn't > mentioned at > all: all the above is defined in terms of server states and functions > mapping server states to server states. > > Hmm ... spelt out this way, there's a trivial proof that all > sequences > of idempotent requests are idempotent sequences. That means > that either > there's something wrong with spelling things out this way (in which > case, what?), or there's something not quite right with 9.1 > > Thoughts? > > Cheers, > > > Miles > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
Mathews, Walden wrote, > What's the trivial proof? I also sense that it's easy, but if > it's that easy, then Alloy won't help. Hmm ... OK, this is a bit rough and ready, but let's see ... By definition GET, PUT and DELETE are idempotent, so, using the notation from my previous mail, g(g(s)) = g(s) ie. g.g = g p(p(s)) = p(s) p.p = p d(d(s)) = d(s) d.d = d where PUT entities are constant and the request URI is common to g, p and d (I'll remove this last assumption later). First off, g is the identity function. That might sound odd, but remember, we're only interested in the state of the server, so if follows from the safeness of GET. It follows that every sequence of g, p, d can be simplified to just g, or an alternation of p and d, because the g's can be eliminated and runs of p's and d's can be collapsed to a single p or d. That means that every sequence is equivalent to one of, 1. g 2. p.d ... p.d 3. p.d ... d.p 4. d.p ... p.d 5. d.p ... d.p Now, a PUT of /foo followed by a DELETE of /foo is equivalent to just a DELETE, so, d(p(s)) = d(s) ie. d.p = d and a DELETE of /foo followed by a PUT of /foo is equivalent to just a PUT, so, p(d(s)) = p(s) ie. p.d = p So we can now reduce the sequences above to, 1. g 2. p 3. p 4. d 5. d ie. any sequence of g, p, and d is equivalent to the most recent non-GET, or to just GET if there are no PUTs or DELETEs involved. But those three are all idempotent, so the original sequence must be idempotent too. OK, now all we have to do is generalize to the case where the sequence includes GETs, PUTs and DELETEs wrt different request URIs. On the assumption that a PUT or DELETE of /foo only affect /foo and not any other resource we can decompose a mixed URI sequence into distinct subsequences, one for each distinct URI. For example, GET /foo GET /foo PUT /bar PUT /bar DELETE /foo DELETE /foo GET /bar GET /bar PUT /foo PUT /foo DELETE /bar DELETE /bar Because these subsequences are relative to distinct URIs they can't have any interdependencies, hence the mixed URI sequence is idempotent if each of the homogenous URI sequences is. But we've already seen that the homogenous URI sequences are idempotent, so all sequences are. QED ;-) Cheers, Miles
Hi All, just thought you might be interested that a new version of XooMLe (XML interface to the Google API) has been uploaded to the live server now. You can get more information from http://www.dentedreality.com.au/xoomle/ or jump straight to the documentation at http://www.dentedreality.com.au/xoomle/docs/ Basically, the modifications are; - proper support for directories - added a "relatedInformation" element if there is any available - added an xlink attribute to relatedInformation and cachedVersion - bugfixes (especially on looping and maxResults > 10) - ability to specify an XSLT stylesheet using the "xsl" querystring variable, which allows you to do on-the-fly formatting Also, if you are interested, XooMLe will feature in an upcoming O'Reilly book which is still being written. At this stage, I think it is called "Google Hacks", it's about the things that people have done with the Google API since it was released, and should be a pretty good read :) Cheers, and thanks to everyone for their suggestions and feedback on XooMLe, please kep it coming if you have any more ideas for making it more RESTful (or just more useful!) Beau (from DentedReality)
Beau,
Dude, Xoomle is looking pretty sweet! I'd like to make the following
suggestions which will make Xoomle more RESTful and easier to use and
integrate with existing code.
1) Actually, I was going to say you might want to expose an RMS
document but nevermind. In the future though, you might want to
consider that there's a difference between the Google service (a
search mechanism using the PageRank algorithm) and a Google service
provider (a URL that exposes the Xoomle API). If people have a Google
appliance for their internal LAN or their desktop then you can have
many service providers providing the same service. You might also
have people exposing Google-like services on top custom data stores,
eg a database. For this reason, I would suggest modularizing your XML
format so Google-like services could add/remove search metadata and
semantics.
2) Please don't use XML-based errors. It's very annoying to go
through all the trouble of parsing an XML document just to discover
it contains no useful information. HTTP has a rich set of built in
response codes you should use. Particularly, I would suggest the
following:
2.1) If a search or spelling suggest does not return any results
then the Xoomle service should return the "HTTP 204 No Content"
status code. If you want to specify the type of error, include an URL
in the 'Location' header which the client can use to determine the
basic type
eg 'www.dentedreality.com.au/xoomle/types/errors/NoKeySpecified'.
Only if the error contains rich information do you need to provide an
XML document describing the error. (Most of errors I think, don't
contain rich information they're of the sort like 'Phrase not
specified' so this should save you and me both some work). Similarly,
HTTP defines error codes like 'HTTP 503 Service Unavailable' for
example to indicate that Xoomle can't contact Google. Really, 90% of
the time I don't care what type of error happened, I just need to
know that there was an error.
2.2) Similarly, the behavior you expose tends to be made
redundant by HTTP. For example, your method doGetCachedPage simply
returns the HTML of the cached page straight from google. Rather than
doing this, I'd suggest issuing an HTTP Redirect to the client so
they can retrieve the cached page themselves.
3) This is trivial but I don't really see the need for the top-level
XML element 'doGoogleSearchResponse' since that's a bit verb-like.
Having 'GoogleSearchResult' as the root seems cleaner to me. Also,
since XML is case-sensitive and since ppl will be writing xslts to
handle Xoomle responses I'd suggest being consistent with your naming
convention. Since you're using camel-casing it seems
like 'GoogleSearchResult' should be 'googleSearchResult'.
Also I have a few questions:
1) How do I pass the 'site:' restriction to Xoomle? Is this just
something the Google SOAP api forbids?
2) Is there any way to expose the directories offered by the Google
Directory?
3) Can you explain more about how max results work?
4) What do the plain-text spelling suggestions response look like?
Are you sure you don't want to return an XML document instead?
All in all, this is a great service and looks like it could be very
useful to develop apps on top of Google. Keep up the good work!
- itdp
--- In rest-discuss@y..., "borkazoid" <beau@d...> wrote:
> Hi All,
> just thought you might be interested that a new version of XooMLe
> (XML interface to the Google API) has been uploaded to the live
> server now. You can get more information from
> http://www.dentedreality.com.au/xoomle/ or jump straight to the
> documentation at http://www.dentedreality.com.au/xoomle/docs/
>
> Basically, the modifications are;
>
> - proper support for directories
> - added a "relatedInformation" element if there is any available
> - added an xlink attribute to relatedInformation and cachedVersion
> - bugfixes (especially on looping and maxResults > 10)
> - ability to specify an XSLT stylesheet using the "xsl"
querystring
> variable, which allows you to do on-the-fly formatting
>
> Also, if you are interested, XooMLe will feature in an upcoming
> O'Reilly book which is still being written. At this stage, I think
it
> is called "Google Hacks", it's about the things that people have
done
> with the Google API since it was released, and should be a pretty
> good read :)
>
> Cheers, and thanks to everyone for their suggestions and feedback
on
> XooMLe, please kep it coming if you have any more ideas for making
it
> more RESTful (or just more useful!)
>
> Beau
> (from DentedReality)
Mark I wanted to make some comments about your blog post replying to Sam Ruby's Google GET issue: http://markbaker.blogspot.com/2002_09_01_markbaker_archive.html#81091743 I would agree with this analysis, except to me the presence of the Developer's Key changes how this issue needs to be approached. IMO, the Developer's Key has an explicit impact on how the idea of a "safe method" should be interpreted. Interpreting safety this strictly, in this context, would seem to render an entire class of Web Services essentially un-GETable. It would seem to reinforce the perception that REST is only good for mostly public data. Given your comments, do you see Xoomle as broken? How is this really any different from any web site that does session time-outs? In that case, is the fact that the session time-out clock is reset when following a link considered an action of "unexpected significance?" This is almost a mirror image of the Google hit counter: in one case following a link has the implicit effect of keeping the session alive; in the other, it is slowly eating it away. But in both cases the user "did not request the side-effects" explicitly. It seems to me that Google is demonstrating the beginnings of a Pay-per-Use business model, that other public Web Services may need to adopt in order to generate income. I expect that in the future, Google will be selling Keys, say $100 per billion queries (or something like that) :)
On Wed, Sep 04, 2002 at 09:15:45AM -0400, Jeffrey Winter wrote: > Mark I wanted to make some comments about your blog post replying > to Sam Ruby's Google GET issue: > > http://markbaker.blogspot.com/2002_09_01_markbaker_archive.html#81091743 > > I would agree with this analysis, except to me the presence > of the Developer's Key changes how this issue needs to be > approached. IMO, the Developer's Key has an explicit impact > on how the idea of a "safe method" should be interpreted. I don't see it as any different than the authorization info as part of an HTTP authentication transaction - it authenticates the user. I don't see how it changes anything. > Interpreting safety this strictly, in this context, would seem to > render an entire class of Web Services essentially un-GETable. > It would seem to reinforce the perception that REST is only good > for mostly public data. I don't see it that way. Would you argue that a GET that bumped up a counter was safe? > Given your comments, do you see Xoomle as broken? "Broken" is too strong. "Sub-optimal", yes. > How is this really any different from any web site that > does session time-outs? In that case, is the fact that > the session time-out clock is reset when following a link > considered an action of "unexpected significance?" This > is almost a mirror image of the Google hit counter: in one > case following a link has the implicit effect of keeping > the session alive; in the other, it is slowly eating it away. > But in both cases the user "did not request the side-effects" > explicitly. > > It seems to me that Google is demonstrating the beginnings of > a Pay-per-Use business model, that other public Web Services > may need to adopt in order to generate income. I expect that > in the future, Google will be selling Keys, say $100 per billion > queries (or something like that) :) I think my statements may have been taken out of context. I was just answering Sam's question; I wouldn't use GET to perform a query that was unsafe. What I didn't say, but would still try to do, is to identify the results of each query by a URI, so that I could re-GET them over and over without those being counted as a hit against my 1000 (unless Google doesn't want to let you - a distinct possibility, sigh). Anyhow, this is a bizarre case, because Google's business model on this service is completely screwed. They'd be much better off opening up http://www.google.com/xml and saying "not for commercial use without agreement". So as an example to set precedence, you can pretty much completely ignore Google. Not that others won't try and copy them, but they won't last either. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
>> I would agree with this analysis, except to me the presence >> of the Developer's Key changes how this issue needs to be >> approached. IMO, the Developer's Key has an explicit impact >> on how the idea of a "safe method" should be interpreted. > I don't see it as any different than the authorization info as part of > an HTTP authentication transaction - it authenticates the user. I > don't see how it changes anything. This is exactly the way I see it also, which is why I drew the analogy to the session timeout issue. It seems to me that if you are calling this putative Google query unsafe, then you'd have to call anything that resets a session time-out clock unsafe too. Do you? From my perspective, while the user "did not request the side-effects" explicitly, in this context, the action isn't of "unexpected significance" either. >> Interpreting safety this strictly, in this context, would seem to >> render an entire class of Web Services essentially un-GETable. >> It would seem to reinforce the perception that REST is only good >> for mostly public data. > I don't see it that way. Would you argue that a GET that bumped up a > counter was safe? What I meant was, in the future, there may be subscription-based Web Services that employ counters in this way - perhaps it doesn't lock out the resource completely when the user goes past a their limit, but it does have some side-effect. If conforming to a strict RESTian approach means that I can't use XSLT to, say, extract a url out of a Google query: <xsl:variable name="url" select="document($google-search)//url"/> then something ain't right. You seem to be saying the entire business model itself ill-conceived, but I'm not so sure. > .... what I didn't say, but would still try to do, is to > identify the results of each query by a URI, so that I could re-GET > them over and over without those being counted as a hit against my 1000 > (unless Google doesn't want to let you - a distinct possibility, sigh). This is sort of a side-bar issue, but it would probably cost more for Google to keep that resource around than it would to simply re-execute the query. I doubt they'd go for it. Couldn't they simply make the results cacheable for 24 hours on an initial GET and be done with it? > Anyhow, this is a bizarre case, because Google's business model on this > service is completely screwed. They'd be much better off opening up > http://www.google.com/xml and saying "not for commercial use without > agreement". So as an example to set precedence, you can pretty much > completely ignore Google. Not that others won't try and copy them, but > they won't last either. I don't see this as particularly bizarre. Even today there are services that limit bandwidth etc. This just seems like a more explicit metering - but then again, I'm not a business modeler. :)
From: "Miles Sabin" <miles@...> > > where "yields a result" seems to be refering to effects on the client. > That can't be right tho', because if it were, DELETE wouldn't be > idempotent: even tho' the effect of multiple DELETEs of the same > resource is the same as just one on the server, it's likely that the > client-visible result would differ: a 200 for the first invocation and > 404s subsequently. A thought occured to me about DELETE. This is not specifically in response to Mile's post, but the above paragraph did prompt the thought. Bear with me on this one. It may take a while to get my "complete" thought out... We all know that a URI is not a resource. It is an identifier of a representation of a resource. The representation may or may not be identical to the resource itself. When we use PUT to create a resource, what we are really doing is creating a resource for which the returned representation of the same URI is the same as the data we uploaded. In reality, the server may use the request data to create additional resources or even augment the data itself when creating the requested resource. As long as a subsequent GET on the same URI returns a representation that is identical to the PUTted data, then everything is fine. Given this, it seems to me that it would be more correct to say that PUT creates a representation of a resource, not the resource itself. (frankly, I like this view more than where PUT creates the actual resource). But now this brings us to DELETE... If you take a similar view as I do for PUT, this means that DELETE only ever removes the representation, not the resource itself! Another way of looking at this is that DELETE invalidates an otherwise valid identifier (URI). The server itself may or may not do anything with the data that was in the representation of the related URI. This depends more on the application than on REST. For instance, suppose we have a purchase order resource on the server. It has a representation identified by URI1. At the same time, suppose we also have another representation of the PO identified by URI2. For clarity, URI1 returns a representation of the entire PO, while URI2 returns a representation of only the header (billing address, shipping address, etc.). Now, suppose we could DELETE URI2. Does this delete the PO header? Of course not. But it could very well cause URI2 to become invalidated (i.e. subsequent requests to the same URI fail). It also occurs to me that this could be an interesting way to implement mutexes for a resource. Successful creation of a URI that identifies a resource indicates a lock. Subsequent requests use the created URI to access the resource. When done, you DELETE the URI. This releases the lock but does not delete the underlying resource. Well, I think that's it for now. I hope it makes sense. :~) --- Seairth Jacobs seairth@...
I wrote, > Mathews, Walden wrote, > > > What's the trivial proof? I also sense that it's easy, but if > > it's that easy, then Alloy won't help. > > Hmm ... OK, this is a bit rough and ready, but let's see ... <snip/> No interest in this anyone? Or no opinions? As a reminder this was the puzzle I posed earlier, Hmm ... spelt out this way, there's a trivial proof that all sequences of idempotent requests are idempotent sequences. That means that either there's something wrong with spelling things out this way (in which case, what?), or there's something not quite right with 9.1 Thoughts? Cheers, Miles
On Wed, Sep 04, 2002 at 09:43:21AM -0400, Mark Baker wrote: > > I don't see it that way. Would you argue that a GET that bumped up a > counter was safe? For me, this is the key question (and perhaps a little too tempting not to address). A safe operation is one that's not intended to modify the resource. The resource in this Google example is the results of a search query. The GET does not modify those results. The 'counter' isn't related to the resource being requested. Nor is it (necessarily) exposed to the user. It's just a way for Google to work out whether to allow you to make the query; it doesn't affect the query itself, you can either make it or you can't. This is not significantly different from a restriction based upon time of day, IP address of the client, or somesuch. I think there's perhaps a temptation to treat this '1001st request' example differently, because there's a loose sense of 'state' brought about by association of state with previous calls. What if Google had performance problems (goodness forbid) and suddenly decided to restrict answering calls that day to clients that hadn't yet made any ... and returned 500 (or another non-200 status) to those that had - would the same 'unsafe' philosophy apply? To bring in a point I made in a comment to the question/discussion [1]: The Axioms document states "It is wrong to represent the user doing a GET as ... doing any operation which effects the state of the Web or the state of the users relationship with the information provider or the server." [2] Returning (e.g.) a 403 on the 1001st GET underlines, not undermines, the relationship with the information provider and server. In all, I'm having difficulty seeing this as an idempotency/side-effect issue. I'd be grateful for any comments on the above. Kind regards dj (still learning) http://www.pipetree.com/qmacro [1] http://www.intertwingly.net/blog/?entry=784 [2] http://www.w3.org/DesignIssues/Axioms#state
On Wed, Sep 04, 2002 at 11:11:24AM -0400, Jeffrey Winter wrote: > > I don't see it as any different than the authorization info as part of > > an HTTP authentication transaction - it authenticates the user. I > > don't see how it changes anything. > > This is exactly the way I see it also, which is why I drew the > analogy to the session timeout issue. It seems to me that if > you are calling this putative Google query unsafe, then you'd > have to call anything that resets a session time-out clock > unsafe too. Do you? You mean a cookie session? Those are stateful. > >From my perspective, while the user "did not request the side-effects" > explicitly, in this context, the action isn't of "unexpected significance" > either. Are you sure that the user didn't request the side-effect? I believe that they did, because the terms under which they're using the service presumably say this (quick search turns up nothing except a FAQ). They understand that they can invoke it 1000 times per day. What if you had a personal proxy which refreshed URIs for you, as personal proxies are allowed to do? If you've got a bunch of queries, each with their own URI, this proxy may use up a sizable amount of > > .... what I didn't say, but would still try to do, is to > > identify the results of each query by a URI, so that I could re-GET > > them over and over without those being counted as a hit against my 1000 > > (unless Google doesn't want to let you - a distinct possibility, sigh). > > This is sort of a side-bar issue, but it would probably cost more for > Google to keep that resource around than it would to simply re-execute > the query. I doubt they'd go for it. I'd guess it's at least an order of magnitude cheaper for them to hit a cache than it is for them to re-query. > Couldn't they simply make the results cacheable for 24 hours on an > initial GET and be done with it? No, because of the aforementioned "unsafe GET" issue. Well, they could just drop the limit. They say it's their for "lack of resources"[1], but I don't buy that. It's to test the market for queries. [1] http://www.google.com/apis/api_faq.html#gen12 To DJ, "GET should be safe" is not a comment on the resource being GETted, it's a general comment; no consequential state, as determined by the server owner, should change as a result of a GET. Otherwise people would be afraid to click on links. And BTW, I think this thread is well named. It is shades of grey. But to SOAP proponents who somehow think this validates their approach, it does not, because you're not even using POST. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
>> I don't see it that way. Would you argue that a GET that bumped up a >> counter was safe? > For me, this is the key question (and perhaps a little too tempting not > to address). Okay, there's a qualitative difference between a GET that simply bumps up a counter, which is *generally* safe, and one that triggers a more meaningful state change, which is *generally* not safe. > The resource in this Google example is the results of a search query. The > GET does not modify those results. Even if the GET does modify the results it's not necessarily unsafe (e.g., the resource may contain the counter of the number of times it's been accessed) Conversely even if the GET doesn't modify the results it's not necessarily safe (e.g., accessing the resources always returns the same result, but unbeknownst to the user, deducts five dollars from their checking account) > The 'counter' isn't related to the resource being requested. Nor is it > (necessarily) exposed to the user. I don't see how you can say that it isn't related to the resource being requested; its whole purpose is to count the number of times it's been accessed which seems like a pretty important relationship. I actually agree with Mark in the general case: a URL that suddenly starts to return 403 when dereferenced via GET some magic number of times is bad practice. A user should, in general, be able to blithely dereference URIs using GET without it having any impact on the web they are using. Where I see the line being drawn though is when this dereferencing is happening within the context of a known authorization relationship with that web. That authorization was given under the explicit terms that that specific resources will only be accessed a limited number of times. Given those terms, I no longer see the change as being of "unexpected significance"; in fact it has precisely the significance that the user expected it to have, which would make it safe.
>> This is exactly the way I see it also, which is why I drew the
>> analogy to the session timeout issue. It seems to me that if
>> you are calling this putative Google query unsafe, then you'd
>> have to call anything that resets a session time-out clock
>> unsafe too. Do you?
> You mean a cookie session? Those are stateful.
What I was really refering to was something along the lines of:
www.mysite.com/session/1234/some-resource
A session resource is established via some authorization mechanism
that will time-out if not accessed within some time period.
> What if you had a personal proxy which refreshed URIs for you, as
> personal proxies are allowed to do? If you've got a bunch of queries,
> each with their own URI, this proxy may use up a sizable amount of
Yikes. Well that certainly changes things... But, what if the resources
were marked "no-cache"?
Thanks for the feedback,
Jeff
On Wed, Sep 04, 2002 at 05:31:10PM -0400, Jeffrey Winter wrote: > > The 'counter' isn't related to the resource being requested. Nor is it > > (necessarily) exposed to the user. > > I don't see how you can say that it isn't related to the resource being > requested; > its whole purpose is to count the number of times it's been accessed which > seems like > a pretty important relationship. It's not related to the specific resource being requested at any point in time - it's a counter for queries in general. I could query for 'apple' then 'banana' and the same counter is incremented. > authorization was given under the explicit terms that that specific resources > will only be accessed a limited number of times. Given those terms, I no > longer > see the change as being of "unexpected significance"; in fact it has precisely > the > significance that the user expected it to have, which would make it safe. Indeed, one could (perversely) argue that not to give a 403 (or whatever) in the context of Google's current T&Cs would be of unexpected significance. I agree with (most people, I suppose) in that the key thing here is that there's no black and white. dj
On Wed, Sep 04, 2002 at 05:15:28PM -0400, Mark Baker wrote: > by the server owner, should change as a result of a GET. Otherwise > people would be afraid to click on links. <smile/> I think this last sentence is a clincher. Although this whole unsafeness of Google GETs just doesn't seem quite right (to me), I am struck by the whole (printed) weight of the works (on which REST err, rests) which those words carry. Thanks dj
On Wed, Sep 04, 2002 at 05:39:29PM -0400, Jeffrey Winter wrote: > > You mean a cookie session? Those are stateful. > > What I was really refering to was something along the lines of: > > www.mysite.com/session/1234/some-resource > > A session resource is established via some authorization mechanism > that will time-out if not accessed within some time period. Why is the timeout needed? You shouldn't need to timeout if you're doing things statelessly, because the server doesn't have to remember anything; all you need to know about authorization is in the request. > > What if you had a personal proxy which refreshed URIs for you, as > > personal proxies are allowed to do? If you've got a bunch of queries, > > each with their own URI, this proxy may use up a sizable amount of > > Yikes. Well that certainly changes things... But, what if the resources > were marked "no-cache"? That's worse! It will mean that more GETs will have to happen, because the responses from the old ones aren't any good any longer. 8-O > Thanks for the feedback, No problem. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "DJ Adams" <dj.adams@...> > The resource in this Google example is the results of a search query. Bingo. Emphasis on the 'results'. > The GET does not modify those results. > The 'counter' isn't related to the resource being requested.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > We all know that a URI is not a resource. It is an identifier of a > representation of a resource. The representation may or may not be > identical to the resource itself. I'm pretty sure the URI identifies the resource, not a representation. Representations are transient things - unless you explicitly make the representation a resource in its own right - but that gets fractally complex (representations of a representation of a resource, etc.). > > For instance, suppose we have a purchase order resource on the server. It > has a representation identified by URI1. At the same time, suppose we also > have another representation of the PO identified by URI2. There would then be two resources. 'The PO' would be URI1, and 'The PO headers' would be URI2. The data returned by URI2 also happens to be available within the data returned by URI1. This gets into what I call 'overlapping resources' (a possibly poor term, but it works for me..) I think of URI2 as a 'synthetic resource' or a 'derived resource'. Operations like DELETE might not actually do anything - either indicated by 'not implemented' or some other response - or they might, its up to the application to decide. Just my opinions though.
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
>
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@s...>
>
> >
> > We all know that a URI is not a resource. It is an identifier of
a
> > representation of a resource. The representation may or may not
be
> > identical to the resource itself.
> I'm pretty sure the URI identifies the resource, not a
representation.
> Representations are transient things - unless you explicitly make
the
> representation a resource in its own right - but that gets
fractally complex
> (representations of a representation of a resource, etc.).
>
From the w3c's introduction to HTML:
"Every resource available on the Web -- HTML document, image,
video clip, program, etc. -- has an address that may be encoded
by a Universal Resource Identifier, or "URI"...
Some URIs refer to a location within a resource. This kind of URI
ends with "#" followed by an anchor identifier (called the fragment
identifier). For instance, here is a URI pointing to an anchor
named section_2:
http://somesite.com/html/top.html#section_2"
So a URI can identify a resource, or it can identify a fragment of a
resource. Just because you can identify something as a fragment of
something else using URIs doesn't necessarily mean that what you're
identifying is a resource.
>
> >
> > For instance, suppose we have a purchase order resource on the
server. It
> > has a representation identified by URI1. At the same time,
suppose we
> also
> > have another representation of the PO identified by URI2.
> There would then be two resources. 'The PO' would be URI1, and 'The
PO
> headers' would be URI2. The data returned by URI2 also happens to be
> available within the data returned by URI1.
>
> This gets into what I call 'overlapping resources' (a possibly poor
term,
> but it works for me..) I think of URI2 as a 'synthetic resource' or
a
> 'derived resource'. Operations like DELETE might not actually do
anything -
> either indicated by 'not implemented' or some other response - or
they
> might, its up to the application to decide.
>
> Just my opinions though.
I wouldn't consider URI2 a resource at all. Why not define it as
a 'fragment'. We're used to seeing browsers retrieving a resource
and then scrolling to the fragment we require - this doesn't
necessarily have to be the case. If the fragment is truly such, and
we have specified only requiring the fragment using '#fragment' why
do we need the whole reource? Why can't we just retrieve the
fragment, keeping in mind that it is only that?
It's a matter of granularity, and I agree with S. Mike here, in so
far as it becomes 'fractally complex' to start defining fragments of
resources as resources in themselves - this behaviour begs the
question of 'where does it end?' Individual paragraphs? Words?
It's not as facetious as it would seem - the words in a resource are
significant to a client such as Google who wants to index your
resource and they become processable 'fragments' in that context.
I've never seen it done before, but imagine POSTing, PUTting or
DELETE-ing to a fragment URI... If the resource in question is
represented as XML, each node (or perhaps child or sibling element)
would by definition be an 'addressable' fragment that removes the
need to pass around whole resources - especially significant when a
resource contains a long history of modifications/operations/etc.
I'm recalling the legal issues raised here a few days ago, and the
need to share documents such as contracts whole - defining part of a
contract as a separate resource removes the context, but defining
that same part as a fragment seems to me to naturally imply that the
context exists without needing to pass around the whole thing every
time someone wants to reference/alter a clause ("You requested part
of the resource, let it be on your head if you misunderstand the
context").
I suppose it all boils down to a resource being defined as something
that can be conceived of as being 'discrete' or 'atomic'. (IMHO)
> -----Original Message----- > From: firepipe_au [mailto:michael@...] > Sent: Thursday, September 05, 2002 7:17 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Other view of DELETE? (was Re: GET: Shades of > Grey) >... > > So a URI can identify a resource, or it can identify a fragment of a ...in which case it's not a URI but a URI reference.... > resource. Just because you can identify something as a fragment of > something else using URIs doesn't necessarily mean that what you're > identifying is a resource. Yes, that's what it means. Anything that has identity is a resource, and if you have a name for it (the URI reference), how can you say it hasn't identity? > I've never seen it done before, but imagine POSTing, PUTting or > DELETE-ing to a fragment URI... If the resource in question is You don't. HTTP methods operate on HTTP URLs (URIs), not HTTP URLs + fragment identifierts (URI references). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Miles, I think that for my part I am convinced that by using a rigorous interpretation of 'idempotent' that your proof is valid, which leaves me also wondering what Roy meant. Possibly he was merely trying to avoid the assertion that a series of idempotent functions is idempotent, as opposed to asserting that there are actual counter-examples to that, as we seem to interpret him. I dunno. Your proof reminded me of an analysis I did a couple of years ago for processing SQL trigger results represented as lists of deletes and inserts for an entire transaction, especially the technique of looking only at the beginning and the end of each sequence. I suspect that any disagreement about the idempotence of a string of idempotent HTTP operations has more to do with the way you might map HTTP operations onto the meaning of 'idempotent' than with the particular proof you offered. We touched on this before. What is the 'function' of an HTTP PUT? I.e., which mapping are we interested in? Clearly, sometimes it's resource before-and-after state. At other times it may be more like request-to-response mapping? I'm still open to trying an Alloy model, but I have a hunch that it won't provide any more insight into the problem than your proof has already given. Walden > -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Wednesday, September 04, 2002 3:19 PM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Idempotent sequences > > > I wrote, > > Mathews, Walden wrote, > > > > > What's the trivial proof? I also sense that it's easy, but if > > > it's that easy, then Alloy won't help. > > > > Hmm ... OK, this is a bit rough and ready, but let's see ... > <snip/> > > No interest in this anyone? Or no opinions? > > As a reminder this was the puzzle I posed earlier, > > Hmm ... spelt out this way, there's a trivial proof that > all sequences > of idempotent requests are idempotent sequences. That means that > either there's something wrong with spelling things out this way (in > which case, what?), or there's something not quite right with 9.1 > > Thoughts? > > Cheers, > > > Miles > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>> What I was really referring to was something along the lines of: >> >> www.mysite.com/session/1234/some-resource >> >> A session resource is established via some authorization mechanism >> that will time-out if not accessed within some time period. > > Why is the timeout needed? I've seen this done to provide an extra modicum of security or privacy protection at sites that might be used in public places. The concern is that someone might go to a library and check their bank balance and forget to shutdown the browser, allowing another person to come along and continue to use the credentials provided by the first user. A time-out at least limits their exposure. Allowing for this sort of time-out with a GET-able interface would require a similar kind of mechanism that the Google interface would have if it used GET. So, my only point was that if one is willing to grant that this is "safe" then a case could be made that it would be okay for Google. >> But, what if the resources were marked "no-cache"? > That's worse! It will mean that more GETs will have to happen, because > the responses from the old ones aren't any good any longer. 8-O Right. It was really a poorly phrased question to understand what the rules are for proxy cache refreshing. - Jeff
> From: Jeffrey Winter [mailto:j.winter@...] > > > Mark Baker: > > Why is the timeout needed? > > I've seen this done to provide an extra modicum of security > or privacy protection at sites that might be used in public > places. The concern is that someone might go to a library and > check their bank balance and forget to shutdown the browser, > allowing another person to come along and continue to use the > credentials provided by the first user. A time-out at least > limits their exposure. Timeouts are also used to mange server load; which wouldn't be a problem with systems that didn't use server sided sessions - then again there's a lot of sites on the web that use sessions. And timeouts aren't even sufficient in some cases. In a non-GET scenario, it's possible to have a browser resubmit a login page simply by refreshing what looks like a different page or hitting the back button *after* you logout (and your session is closed on the server). This can happen easily enough with controller type architectures (considered best practice in servlets/jsp land), where you GET a login page, POST the login and are redirected behind the scenes to an inbox page; if you POST logout and refresh (POST) the inbox page, chances are be logged back in (or maybe someone else will log you back). I like the idea of stateless servers and client sided session management, but you'd need to throw out a lot of sites and browsers to see that realized. Bill de hra -- Propylon www.propylon.com
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> > > I'm pretty sure the URI identifies the resource, not a representation. > Representations are transient things - unless you explicitly make the > representation a resource in its own right - but that gets fractally complex > (representations of a representation of a resource, etc.). But this doesn't jive with my understanding of REST. You can never retrieve a resource. You can only ever retrieve a representation of a resource. If you want, you could call the representation a "virtual" resource, meaning that it can logically be treated as a resource, but does not necessarily have a direct correlation with an actual resource on the server. I don't see where anything gets complex here. All that one can ever retrieve is a representation of a resource. If you have two (or two hundred) URIs, each returns a representation of a resource. If you take my PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a representation of the resource pointed to by URI1. URI2 returns a representation of a resource. URI1 returns a representation of a resource. Sure, they may both be pointing to the same resource, but that doesn't mean that URI2 is subordinate to URI1. If that *were* the case, it would mean to me that URI1 is now synonymous for the resource itself. This would mean that a request to get the resource must return the resource itself, which we know is not possible. Therefore, URI1 can only even be synonymous with a representation of a resource, which also means that URI2 cannot be subordinate to URI1. > This gets into what I call 'overlapping resources' (a possibly poor term, > but it works for me..) I think of URI2 as a 'synthetic resource' or a > 'derived resource'. Operations like DELETE might not actually do anything - > either indicated by 'not implemented' or some other response - or they > might, its up to the application to decide. So, based on what you are saying, if I were to add a querystring to the URI such that the returned data was potentially different, each valid variation of the querystring points to separate resource? Using the URI->Representation POV, the querystring would returns different representations of the same resource. I wonder if "view" would be a better word than "representation"? Using the "view" imagery (warning: some may consider this very unRESTful): 1) A "view" is the data returned by a server. Each view has its own URI. More than one URI may return identical views, but they are not the same view. In other words, there is a one-to-one relationship between views and URIs. 2) A view is not the same as a resource. A view may be identical to a resource, but it is not the resource itself. 3) PUT only creates association between a URI and a view with the added restriction that a subsequent GET of the URI returns the same view. The PUT may cause the server to create a new resource or update an existing resource. The actual resource may be different than the view created by the PUT as long as the view does not change. 4) GET only returns views of a resource. Idempotency of a GET means that the "intent" of the GET is to return a view only. A GET may be considered idempotent even though resources are altered on the server as long as the GET wasn't being used to cause the alteration. 5) POST sends data to a URI. It is not sending the data to a view (views are what's returned). In this case, URIs are "black boxes", into which anything may be sent (though not necessarily accepted). The function of a POST is not strictly defined, except that it does imply an intent to alter a resource (and is therefore not idempotent). A view of the target resource may be returned by the server. The contents of the view are entirely subject to the purpose of the POST. 6) DELETE only destroys or invalidates a view (and therefore the URI that identified the view). DELETE does not necessarily cause the deletion of the underlying resource. For instance, a single resource may have multiple views (accessible by multiple URIs). The server may only delete the resource after all of the views have been DELETEd. DELETEing just one view would not, in this case, cause the underlying resource to be deleted (or even necessarily altered). What this means is a clear picture of where the coupling is: between the view and the resource. This means that the server has full control over how tightly or loosely coupled the resource is to the view that the clients receive. What I mean by coupling here is the internal relationship of the expressed view to the actual resource. Loose coupling means that while the view is related to the resource, it is not a direct corollary for the resource. Tight coupling, on the other hand, means that the view is more of (or a direct) corollary for it's related resource. To illustrate, the two servers in the following example both provide identical views and therefore identical functionality from the client's POV, while internally handling the resources differently. Server 1 (tight coupling): PUT <data> /path/file.html : creates a file and puts <data> inside that file. GET /path/file.html : opens the file and returns <data> inside that file. DELETE /path/file.html : deletes the file. POST <data> /path/file.html : invalid request. Server 2 (loose coupling): PUT <data> /path/file.html : takes data, chops it up in several fragments (for internal reasons) and places those fragments into a table on an SQL server. At the same time, it also processes and adds keywords to an index table. Further, it creates additional internal resources to provide links between <data> and the user that uploaded. GET /path/file.html : queries the SQL server and reconstructs <data> from its individual fragments. DELETE /path/file.html : only deletes access to the resource via this URI. However, since no other URIs are pointing to the same resource in this particular case, the server proceeds to delete the records in the SQL server and all related resources. POST <data> /path/file.html : invalid request. I'm going to stop here for now. I have had to step away from this message about 15 times so now I have somewhat lost my train of thought. What I have above appears to be coherent to me, so I will start with this. Now for the fun part... in what way(s) is this view wrong? :) --- Seairth Jacobs seairth@...
Seairth, Your post is rather long and I only skimmed it, so apologies if I missed important material. I think the REST model says that there are resources, representations and identifiers. A resource may have more than one identifier, but an identifier identifies only a single resource. A resource may have many representations, but a given representation is a representation of only one resource (although it may look an awful lot like some representation of some other resource). When you request the state of a resource (GET), you will be given the representation that the server feels is most appropriate for you in the circumstances. Content negotiation headers aside, you cannot directly request a particular representation of a resource. You cannot directly address a representation. If you could, then the representation would, by definition, be a resource, which implies that it also has representations, and hence the fractalness of resource that Mike D pointed out. The indirection of representations you are required to wade through on your way to accessing resources is what accounts for the 'conceptual' nature of those resources, more or less. This model seems self-consistent. Or does it? Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Thursday, September 05, 2002 1:40 PM > To: rest-discuss; S. Mike Dierken > Subject: [rest-discuss] Resources vs. Representations (was Re: Other > view of DELETE?) > > > > ----- Original Message ----- > From: "S. Mike Dierken" <mdierken@...> > > > > I'm pretty sure the URI identifies the resource, not a > representation. > > Representations are transient things - unless you > explicitly make the > > representation a resource in its own right - but that gets fractally > complex > > (representations of a representation of a resource, etc.). > > But this doesn't jive with my understanding of REST. You can > never retrieve > a resource. You can only ever retrieve a representation of a > resource. If > you want, you could call the representation a "virtual" > resource, meaning > that it can logically be treated as a resource, but does not > necessarily > have a direct correlation with an actual resource on the server. > > I don't see where anything gets complex here. All that one can ever > retrieve is a representation of a resource. If you have two (or two > hundred) URIs, each returns a representation of a resource. > If you take my > PurchaseOrder URI1 and URI2 examples, URI2 is not a > representation of a > representation of the resource pointed to by URI1. URI2 returns a > representation of a resource. URI1 returns a representation > of a resource. > Sure, they may both be pointing to the same resource, but > that doesn't mean > that URI2 is subordinate to URI1. If that *were* the case, > it would mean to > me that URI1 is now synonymous for the resource itself. This > would mean > that a request to get the resource must return the resource > itself, which we > know is not possible. Therefore, URI1 can only even be > synonymous with a > representation of a resource, which also means that URI2 cannot be > subordinate to URI1. > > > This gets into what I call 'overlapping resources' (a > possibly poor term, > > but it works for me..) I think of URI2 as a 'synthetic > resource' or a > > 'derived resource'. Operations like DELETE might not actually do > anything - > > either indicated by 'not implemented' or some other > response - or they > > might, its up to the application to decide. > > So, based on what you are saying, if I were to add a > querystring to the URI > such that the returned data was potentially different, each > valid variation > of the querystring points to separate resource? Using the > URI->Representation POV, the querystring would returns different > representations of the same resource. > > I wonder if "view" would be a better word than > "representation"? Using the > "view" imagery (warning: some may consider this very unRESTful): > > 1) A "view" is the data returned by a server. Each view has > its own URI. > More than one URI may return identical views, but they are > not the same > view. In other words, there is a one-to-one relationship > between views and > URIs. > > 2) A view is not the same as a resource. A view may be identical to a > resource, but it is not the resource itself. > > 3) PUT only creates association between a URI and a view with > the added > restriction that a subsequent GET of the URI returns the same > view. The PUT > may cause the server to create a new resource or update an existing > resource. The actual resource may be different than the view > created by the > PUT as long as the view does not change. > > 4) GET only returns views of a resource. Idempotency of a > GET means that > the "intent" of the GET is to return a view only. A GET may > be considered > idempotent even though resources are altered on the server as > long as the > GET wasn't being used to cause the alteration. > > 5) POST sends data to a URI. It is not sending the data to a > view (views > are what's returned). In this case, URIs are "black boxes", > into which > anything may be sent (though not necessarily accepted). The > function of a > POST is not strictly defined, except that it does imply an > intent to alter a > resource (and is therefore not idempotent). A view of the > target resource > may be returned by the server. The contents of the view are entirely > subject to the purpose of the POST. > > 6) DELETE only destroys or invalidates a view (and therefore > the URI that > identified the view). DELETE does not necessarily cause the > deletion of the > underlying resource. For instance, a single resource may > have multiple > views (accessible by multiple URIs). The server may only delete the > resource after all of the views have been DELETEd. DELETEing > just one view > would not, in this case, cause the underlying resource to be > deleted (or > even necessarily altered). > > > What this means is a clear picture of where the coupling is: > between the > view and the resource. This means that the server has full > control over how > tightly or loosely coupled the resource is to the view that > the clients > receive. What I mean by coupling here is the internal > relationship of the > expressed view to the actual resource. Loose coupling means > that while the > view is related to the resource, it is not a direct corollary for the > resource. Tight coupling, on the other hand, means that the > view is more of > (or a direct) corollary for it's related resource. To > illustrate, the two > servers in the following example both provide identical views > and therefore > identical functionality from the client's POV, while > internally handling the > resources differently. > > Server 1 (tight coupling): > > PUT <data> /path/file.html : creates a file and puts <data> > inside that > file. > GET /path/file.html : opens the file and returns <data> > inside that file. > DELETE /path/file.html : deletes the file. > POST <data> /path/file.html : invalid request. > > Server 2 (loose coupling): > > PUT <data> /path/file.html : takes data, chops it up in > several fragments > (for internal reasons) and places those fragments into a > table on an SQL > server. At the same time, it also processes and adds > keywords to an index > table. Further, it creates additional internal resources to > provide links > between <data> and the user that uploaded. > GET /path/file.html : queries the SQL server and reconstructs > <data> from > its individual fragments. > DELETE /path/file.html : only deletes access to the resource > via this URI. > However, since no other URIs are pointing to the same resource in this > particular case, the server proceeds to delete the records in > the SQL server > and all related resources. > POST <data> /path/file.html : invalid request. > > > > I'm going to stop here for now. I have had to step away from > this message > about 15 times so now I have somewhat lost my train of > thought. What I have > above appears to be coherent to me, so I will start with > this. Now for the > fun part... in what way(s) is this view wrong? :) > > --- > Seairth Jacobs > seairth@... > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Oh, I wanted to say one other thing on this subject. There is this idea that if we PUT a resource through its URI, then we GET that resource back, we should get back the same value as we PUT. That statement implies that we have representation-level control, which we do not. It would make more sense to think of it this way. If we PUT a representation to a URI, then GET back a representation, the latter representation *means the same thing* as the former, though it may differ in format or even typographically. THoughts? Walden > -----Original Message----- > From: Mathews, Walden > Sent: Thursday, September 05, 2002 1:52 PM > To: 'Seairth Jacobs'; rest-discuss; S. Mike Dierken > Subject: RE: [rest-discuss] Resources vs. Representations > (was Re: Other > v iew of DELETE?) > > > Seairth, > > Your post is rather long and I only skimmed it, so apologies if > I missed important material. I think the REST model says that there > are resources, representations and identifiers. A resource may have > more than one identifier, but an identifier identifies only a single > resource. A resource may have many representations, but a given > representation is a representation of only one resource (although > it may look an awful lot like some representation of some other > resource). When you request the state of a resource (GET), you will > be given the representation that the server feels is most appropriate > for you in the circumstances. Content negotiation headers aside, > you cannot directly request a particular representation of a resource. > > You cannot directly address a representation. If you could, then the > representation would, by definition, be a resource, which implies > that it also has representations, and hence the fractalness > of resource > that Mike D pointed out. > > The indirection of representations you are required to wade through > on your way to accessing resources is what accounts for the > 'conceptual' > nature of those resources, more or less. > > This model seems self-consistent. Or does it? > > Walden > > > -----Original Message----- > > From: Seairth Jacobs [mailto:seairth@...] > > Sent: Thursday, September 05, 2002 1:40 PM > > To: rest-discuss; S. Mike Dierken > > Subject: [rest-discuss] Resources vs. Representations (was Re: Other > > view of DELETE?) > > > > > > > > ----- Original Message ----- > > From: "S. Mike Dierken" <mdierken@...> > > > > > > I'm pretty sure the URI identifies the resource, not a > > representation. > > > Representations are transient things - unless you > > explicitly make the > > > representation a resource in its own right - but that > gets fractally > > complex > > > (representations of a representation of a resource, etc.). > > > > But this doesn't jive with my understanding of REST. You can > > never retrieve > > a resource. You can only ever retrieve a representation of a > > resource. If > > you want, you could call the representation a "virtual" > > resource, meaning > > that it can logically be treated as a resource, but does not > > necessarily > > have a direct correlation with an actual resource on the server. > > > > I don't see where anything gets complex here. All that one can ever > > retrieve is a representation of a resource. If you have two (or two > > hundred) URIs, each returns a representation of a resource. > > If you take my > > PurchaseOrder URI1 and URI2 examples, URI2 is not a > > representation of a > > representation of the resource pointed to by URI1. URI2 returns a > > representation of a resource. URI1 returns a representation > > of a resource. > > Sure, they may both be pointing to the same resource, but > > that doesn't mean > > that URI2 is subordinate to URI1. If that *were* the case, > > it would mean to > > me that URI1 is now synonymous for the resource itself. This > > would mean > > that a request to get the resource must return the resource > > itself, which we > > know is not possible. Therefore, URI1 can only even be > > synonymous with a > > representation of a resource, which also means that URI2 cannot be > > subordinate to URI1. > > > > > This gets into what I call 'overlapping resources' (a > > possibly poor term, > > > but it works for me..) I think of URI2 as a 'synthetic > > resource' or a > > > 'derived resource'. Operations like DELETE might not actually do > > anything - > > > either indicated by 'not implemented' or some other > > response - or they > > > might, its up to the application to decide. > > > > So, based on what you are saying, if I were to add a > > querystring to the URI > > such that the returned data was potentially different, each > > valid variation > > of the querystring points to separate resource? Using the > > URI->Representation POV, the querystring would returns different > > representations of the same resource. > > > > I wonder if "view" would be a better word than > > "representation"? Using the > > "view" imagery (warning: some may consider this very unRESTful): > > > > 1) A "view" is the data returned by a server. Each view has > > its own URI. > > More than one URI may return identical views, but they are > > not the same > > view. In other words, there is a one-to-one relationship > > between views and > > URIs. > > > > 2) A view is not the same as a resource. A view may be > identical to a > > resource, but it is not the resource itself. > > > > 3) PUT only creates association between a URI and a view with > > the added > > restriction that a subsequent GET of the URI returns the same > > view. The PUT > > may cause the server to create a new resource or update an existing > > resource. The actual resource may be different than the view > > created by the > > PUT as long as the view does not change. > > > > 4) GET only returns views of a resource. Idempotency of a > > GET means that > > the "intent" of the GET is to return a view only. A GET may > > be considered > > idempotent even though resources are altered on the server as > > long as the > > GET wasn't being used to cause the alteration. > > > > 5) POST sends data to a URI. It is not sending the data to a > > view (views > > are what's returned). In this case, URIs are "black boxes", > > into which > > anything may be sent (though not necessarily accepted). The > > function of a > > POST is not strictly defined, except that it does imply an > > intent to alter a > > resource (and is therefore not idempotent). A view of the > > target resource > > may be returned by the server. The contents of the view > are entirely > > subject to the purpose of the POST. > > > > 6) DELETE only destroys or invalidates a view (and therefore > > the URI that > > identified the view). DELETE does not necessarily cause the > > deletion of the > > underlying resource. For instance, a single resource may > > have multiple > > views (accessible by multiple URIs). The server may only delete the > > resource after all of the views have been DELETEd. DELETEing > > just one view > > would not, in this case, cause the underlying resource to be > > deleted (or > > even necessarily altered). > > > > > > What this means is a clear picture of where the coupling is: > > between the > > view and the resource. This means that the server has full > > control over how > > tightly or loosely coupled the resource is to the view that > > the clients > > receive. What I mean by coupling here is the internal > > relationship of the > > expressed view to the actual resource. Loose coupling means > > that while the > > view is related to the resource, it is not a direct > corollary for the > > resource. Tight coupling, on the other hand, means that the > > view is more of > > (or a direct) corollary for it's related resource. To > > illustrate, the two > > servers in the following example both provide identical views > > and therefore > > identical functionality from the client's POV, while > > internally handling the > > resources differently. > > > > Server 1 (tight coupling): > > > > PUT <data> /path/file.html : creates a file and puts <data> > > inside that > > file. > > GET /path/file.html : opens the file and returns <data> > > inside that file. > > DELETE /path/file.html : deletes the file. > > POST <data> /path/file.html : invalid request. > > > > Server 2 (loose coupling): > > > > PUT <data> /path/file.html : takes data, chops it up in > > several fragments > > (for internal reasons) and places those fragments into a > > table on an SQL > > server. At the same time, it also processes and adds > > keywords to an index > > table. Further, it creates additional internal resources to > > provide links > > between <data> and the user that uploaded. > > GET /path/file.html : queries the SQL server and reconstructs > > <data> from > > its individual fragments. > > DELETE /path/file.html : only deletes access to the resource > > via this URI. > > However, since no other URIs are pointing to the same > resource in this > > particular case, the server proceeds to delete the records in > > the SQL server > > and all related resources. > > POST <data> /path/file.html : invalid request. > > > > > > > > I'm going to stop here for now. I have had to step away from > > this message > > about 15 times so now I have somewhat lost my train of > > thought. What I have > > above appears to be coherent to me, so I will start with > > this. Now for the > > fun part... in what way(s) is this view wrong? :) > > > > --- > > Seairth Jacobs > > seairth@... > > > > > > ------------------------ Yahoo! Groups Sponsor > > ---------------------~--> > > 4 DVDs Free +s&p Join Now > > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > > -------------------------------------------------------------- > > -------~-> > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Looking for a more powerful website? Try GeoCities for $8.95 > per month. > Register your domain name (http://your-name.com). More > storage! No ads! > http://geocities.yahoo.com/ps/info > http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thu, Sep 05, 2002 at 01:59:40PM -0400, Mathews, Walden wrote: > Oh, I wanted to say one other thing on this subject. There is > this idea that if we PUT a resource through its URI, then we GET > that resource back, we should get back the same value as we PUT. > That statement implies that we have representation-level control, > which we do not. It would make more sense to think of it this > way. If we PUT a representation to a URI, then GET back a representation, > the latter representation *means the same thing* as the former, > though it may differ in format or even typographically. THoughts? Actually, PUT's a bit funny that way. It's definined to really mean "store" more than "set the state", so it is expected that bits are preserved. For this reason, SOAP can't use PUT (at least how you'd expect it to be used). At some point, I'm going to propose a "SET" method that can be used in this way. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
From: "Mark Baker" <distobj@...> > > Actually, PUT's a bit funny that way. It's definined to really mean > "store" more than "set the state", so it is expected that bits are > preserved. For this reason, SOAP can't use PUT (at least how you'd > expect it to be used). > > At some point, I'm going to propose a "SET" method that can be used > in this way. POST could be used for such a thing, but it requires the pre-existance of a request URI. Instead of suggesting a SET method, how about either: 1) Relaxing POST to allow the creation of resources, or 2) Issue an "empty" PUT to create the resource, then follow with a non-empty POST to set the resource. --- Seairth Jacobs seairth@...
Or, how about fixing RFC 2616 so that PUT makes sense for resources that are powerfully conceptual, as opposed to resources that are 'just documents'? But I like "SET" just fine, too. Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Thursday, September 05, 2002 3:42 PM > To: rest-discuss > Subject: Re: [rest-discuss] Resources vs. Representations > > > From: "Mark Baker" <distobj@...> > > > > Actually, PUT's a bit funny that way. It's definined to really mean > > "store" more than "set the state", so it is expected that bits are > > preserved. For this reason, SOAP can't use PUT (at least how you'd > > expect it to be used). > > > > At some point, I'm going to propose a "SET" method that can be used > > in this way. > > POST could be used for such a thing, but it requires the > pre-existance of a > request URI. Instead of suggesting a SET method, how about either: > > 1) Relaxing POST to allow the creation of resources, or > 2) Issue an "empty" PUT to create the resource, then follow > with a non-empty > POST to set the resource. > > --- > Seairth Jacobs > seairth@... > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
How can the RFC dictate this in the first place? Isn't the way that the server chooses to handle/store the actual resource entirely transparent to the protocol as long as subsequent retrieval is identical to what's posted? Also, if you were to "relax" the rules of PUT, it seems to me that the only difference at that point between PUT and POST is that one allows the client to give the URI of a created resource while the other does not. Or am I misundersanding how you want PUT to be fixed? --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Mathews, Walden" <waldenm@...> To: "'Seairth Jacobs'" <seairth@...>; "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Thursday, September 05, 2002 3:52 PM Subject: RE: [rest-discuss] Resources vs. Representations > Or, how about fixing RFC 2616 so that PUT makes sense for resources > that are powerfully conceptual, as opposed to resources that are 'just > documents'? > > But I like "SET" just fine, too. > > Walden > > > -----Original Message----- > > From: Seairth Jacobs [mailto:seairth@...] > > Sent: Thursday, September 05, 2002 3:42 PM > > To: rest-discuss > > Subject: Re: [rest-discuss] Resources vs. Representations > > > > > > From: "Mark Baker" <distobj@...> > > > > > > Actually, PUT's a bit funny that way. It's definined to really mean > > > "store" more than "set the state", so it is expected that bits are > > > preserved. For this reason, SOAP can't use PUT (at least how you'd > > > expect it to be used). > > > > > > At some point, I'm going to propose a "SET" method that can be used > > > in this way. > > > > POST could be used for such a thing, but it requires the > > pre-existance of a > > request URI. Instead of suggesting a SET method, how about either: > > > > 1) Relaxing POST to allow the creation of resources, or > > 2) Issue an "empty" PUT to create the resource, then follow > > with a non-empty > > POST to set the resource. > > > > --- > > Seairth Jacobs > > seairth@... > > > > > > ------------------------ Yahoo! Groups Sponsor > > ---------------------~--> > > 4 DVDs Free +s&p Join Now > > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > > -------------------------------------------------------------- > > -------~-> > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
My understanding of PUT and POST (gleaned from interactions on this mail list, by the way) is that PUT - is for overwriting an entire resource, for some value of 'overwrite' POST - is for appending to a resource, for some value of 'append' Append means the representation you are forwarding represents something subordinate to the named resource, as if the resource is a container, but you can mess with that meaning a bit when resources are pure processors with uninteresting state of their own. Overwrite means a complete replacement of state, except in the case where identity was missing in the first place, in which case it is just a placement of state, not a replacement. The RFC 'dictates' the semantics of the protocol and thereby defines the protocol, but it doesn't force developers to follow the protocol. You could say that to the extent that you use GET to induce side effects as the main dish, to the extent that you use PUT to accomplish non-idempotent work, etc., etc., you are not doing HTTP. Sometimes the work 'tunneling' is used as a synonym for 'not doing', while being a bit more expressive of what's going on. Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Thursday, September 05, 2002 4:09 PM > To: rest-discuss > Subject: Re: [rest-discuss] Resources vs. Representations > > > How can the RFC dictate this in the first place? Isn't the > way that the > server chooses to handle/store the actual resource entirely > transparent to > the protocol as long as subsequent retrieval is identical to > what's posted? > > Also, if you were to "relax" the rules of PUT, it seems to me > that the only > difference at that point between PUT and POST is that one > allows the client > to give the URI of a created resource while the other does > not. Or am I > misundersanding how you want PUT to be fixed? > > --- > Seairth Jacobs > seairth@... > > > ----- Original Message ----- > From: "Mathews, Walden" <waldenm@...> > To: "'Seairth Jacobs'" <seairth@...>; "rest-discuss" > <rest-discuss@yahoogroups.com> > Sent: Thursday, September 05, 2002 3:52 PM > Subject: RE: [rest-discuss] Resources vs. Representations > > > > Or, how about fixing RFC 2616 so that PUT makes sense for resources > > that are powerfully conceptual, as opposed to resources > that are 'just > > documents'? > > > > But I like "SET" just fine, too. > > > > Walden > > > > > -----Original Message----- > > > From: Seairth Jacobs [mailto:seairth@...] > > > Sent: Thursday, September 05, 2002 3:42 PM > > > To: rest-discuss > > > Subject: Re: [rest-discuss] Resources vs. Representations > > > > > > > > > From: "Mark Baker" <distobj@...> > > > > > > > > Actually, PUT's a bit funny that way. It's definined > to really mean > > > > "store" more than "set the state", so it is expected > that bits are > > > > preserved. For this reason, SOAP can't use PUT (at > least how you'd > > > > expect it to be used). > > > > > > > > At some point, I'm going to propose a "SET" method that > can be used > > > > in this way. > > > > > > POST could be used for such a thing, but it requires the > > > pre-existance of a > > > request URI. Instead of suggesting a SET method, how > about either: > > > > > > 1) Relaxing POST to allow the creation of resources, or > > > 2) Issue an "empty" PUT to create the resource, then follow > > > with a non-empty > > > POST to set the resource. > > > > > > --- > > > Seairth Jacobs > > > seairth@... > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > ---------------------~--> > > > 4 DVDs Free +s&p Join Now > > > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > > > -------------------------------------------------------------- > > > -------~-> > > > > > > To unsubscribe from this group, send an email to: > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > > > > > Your use of Yahoo! Groups is subject to > > http://docs.yahoo.com/info/terms/ > > > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > So, based on what you are saying, if I were to add a querystring to the URI > such that the returned data was potentially different, each valid variation > of the querystring points to separate resource? Yes. Resources are /very/ flexible (possibly not innumerable, but infinite enough for me). > Using the URI->Representation POV, the querystring would returns different > representations of the same resource. The response header of Content-Type (and other headers maybe...) indicates that it is a different representation.
----- Original Message ----- From: "firepipe_au" <michael@...> > > I've never seen it done before, but imagine POSTing, PUTting or > DELETE-ing to a fragment URI... You can't. The definition of URI with fragment identifiers is such that interactions with the resource do not include the fragment portion (the stuff after '#'). So you can only interact with the 'base resource' via HTTP - a client can do anything with portions of the representation retrieved, but can only talk back to the full resource. Since the fragment identifier is used by the client, it is dependent on the particular representation returned by the server.
----- Original Message ----- From: "Bill de h�ra" <dehora@...> > I like the idea of stateless servers and client sided session management, > but you'd need to throw out a lot of sites and browsers to see that realized. Throwing out the browser as a foundation (or even a good example) for the 'automatable Web' isn't such a bad thing...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > I don't see where anything gets complex here. All that one can ever > retrieve is a representation of a resource. If you have two (or two > hundred) URIs, each returns a representation of a resource. If you take my > PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a > representation of the resource pointed to by URI1. URI2 returns a > representation of a resource. URI1 returns a representation of a resource. > Sure, they may both be pointing to the same resource, but that doesn't mean > that URI2 is subordinate to URI1. They cannot be pointing to the same resource, they have different URIs. They might be pointing to the same data behind the scenes, but externally, that is not visible. A resource is what is visible externally. The same PO data (the bits) might have multiple resources exposed. Personally, I wouldn't expose multiple resources in order to provide different content types - I'd use Accept: and Content-Type: for that. I might use different resources to expose different portions of a purchase order - or perhaps different portions of the history of actions related to a 'purchase'.
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > Oh, I wanted to say one other thing on this subject. There is > this idea that if we PUT a resource through its URI, then we GET > that resource back, we should get back the same value as we PUT. > That statement implies that we have representation-level control, > which we do not. It would make more sense to think of it this > way. If we PUT a representation to a URI, then GET back a representation, > the latter representation *means the same thing* as the former, > though it may differ in format or even typographically. THoughts? > I think this is the only way to think about it when considering content negotiation (or at least potentially different content-types for a representation).
so it's just a matter of replacing resources by data and representations by resources in Seairth mail to agree ? ----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Thursday, September 05, 2002 10:39 PM Subject: Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?) > > ----- Original Message ----- > From: "Seairth Jacobs" <seairth@...> > > > I don't see where anything gets complex here. All that one can ever > > retrieve is a representation of a resource. If you have two (or two > > hundred) URIs, each returns a representation of a resource. If you take > my > > PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a > > representation of the resource pointed to by URI1. URI2 returns a > > representation of a resource. URI1 returns a representation of a > resource. > > Sure, they may both be pointing to the same resource, but that doesn't > mean > > that URI2 is subordinate to URI1. > They cannot be pointing to the same resource, they have different URIs. They > might be pointing to the same data behind the scenes, but externally, that > is not visible. A resource is what is visible externally. The same PO data > (the bits) might have multiple resources exposed. > Personally, I wouldn't expose multiple resources in order to provide > different content types - I'd use Accept: and Content-Type: for that. I > might use different resources to expose different portions of a purchase > order - or perhaps different portions of the history of actions related to a > 'purchase'. > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> They cannot be pointing to the same resource, they have > different URIs. Are you implying that a single resource can't have two or more identifiers? I would think it can, and that should be no problem. What do I miss? Walden
> From: S. Mike Dierken [mailto:mdierken@...] > > They cannot be pointing to the same resource, they have > different URIs. Where is it specified that a resource can only ever have one URI? Bill de hra -- Propylon www.propylon.com
On Thursday, Sep 5, 2002, at 22:04 Europe/Dublin, Bill de hra wrote: >> From: S. Mike Dierken [mailto:mdierken@...] >> >> They cannot be pointing to the same resource, they have >> different URIs. > > Where is it specified that a resource can only ever have one URI? i haven't seen that specified anywhere. however, i also haven't seen it specified anywhere in the semantic web propoganda (in the positive sense of the word) that i've seen, how you assert that two URI are equivalent, or identify the same resource. so if you and i use distinct URIs (sp?) to refer to "the Ford Escort Mark II" (with apologies to non-europeans), nobody can assert that they in fact identify the same thing. this troubles me. sometimes i struggle to see how the semantic web can work without it. to drag this back on topic, i see REST as a necessary prerequisite for a successful semantic web.
I would think that the naming authority could assert that two URIs reference the same resource, and might do that with a third resource which is an equivalence relation. Walden > -----Original Message----- > From: Vincent D Murphy [mailto:vdm@...] > Sent: Thursday, September 05, 2002 5:19 PM > To: Bill de hra > Cc: 'S. Mike Dierken'; 'rest-discuss' > Subject: Re: [rest-discuss] Resources vs. Representations > (was Re: Other > view of DELETE?) > > > On Thursday, Sep 5, 2002, at 22:04 Europe/Dublin, Bill de hra wrote: > >> From: S. Mike Dierken [mailto:mdierken@...] > >> > >> They cannot be pointing to the same resource, they have > >> different URIs. > > > > Where is it specified that a resource can only ever have one URI? > > i haven't seen that specified anywhere. > > however, i also haven't seen it specified anywhere in the > semantic web > propoganda (in the positive sense of the word) that i've > seen, how you > assert that two URI are equivalent, or identify the same resource. > > so if you and i use distinct URIs (sp?) to refer to "the Ford Escort > Mark II" (with apologies to non-europeans), nobody can assert > that they > in fact identify the same thing. > > this troubles me. sometimes i struggle to see how the > semantic web can > work without it. > > to drag this back on topic, i see REST as a necessary > prerequisite for > a successful semantic web. > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Hello RESTlers--
I am a REST newbie but coming from the topic map world I think
I can contribute something here:
Vincent D Murphy wrote:
> however, i also haven't seen it specified anywhere in the semantic web
> propoganda (in the positive sense of the word) that i've seen, how you
> assert that two URI are equivalent, or identify the same resource.
I think that there are two issues here:
1. How do you specify that two URIs identify the same resource (=are addressing
the same resource)
I think that NewsML provides a way with the <Resource> element:
<Resource>
<Urn>urn:newsml:iptc.org:20001006:topicset.iptc-howpresent:1</Urn>
<Url>file://./topicsets/iptc-howpresent.xml</Url>
</Resource>
2. How do you specify that two URIs indicate the same subject ?
> so if you and i use distinct URIs (sp?) to refer to "the Ford Escort
> Mark II" (with apologies to non-europeans), nobody can assert that they
> in fact identify the same thing.
Besides the actual purpose of URIs (addressing and identifying resources) they
can be used to identify abstract things simply because they are unique
identifiers. In topic maps land such URIs are called 'subject indicators'.
(For example see http://www.topicmaps.org/xtm/1.0/language.xtm for a topic map that
defines subject indicators for ISO language codes)
One of the primary goals of topic maps is to solve the problem you mention
above: how can one assert that two subject indicators (URIs) identify the
same thing (=subject).
This can be done by the follwing markup for example:
<topicMap>
<topic id="foo">
<subjectIdentity>
<subjectIndicatorRef
xlink:href="http://www.foo.bar/ford-escort-mark-2" />
<subjectIndicatorRef
xlink:href="http://www.ford.com/models/escort/mark-2" />
<subjectIdentity>
</topic>
</topicMap>
An topic map application will 'know' from this markup that the two URIs refer to
the same subject and will recognize both of them equally well as an identifier
for that subject.
> this troubles me. sometimes i struggle to see how the semantic web can
> work without it.
So, no trouble here (if I understood you correctly).
> to drag this back on topic, i see REST as a necessary prerequisite for
> a successful semantic web.
Yes, and I am currently learning a lot from this list. Thanks.
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
On Thursday, Sep 5, 2002, at 22:30 Europe/Dublin, Mathews, Walden wrote: > I would think that the naming authority could assert that two > URIs reference the same resource, and might do that with a third > resource which is an equivalence relation. granted.. but shouldn't the equivalence relation be standard, and endorsed by the W3C or whoever, rather than something each naming authority must (re)invent? (that was sort of the whole point, though i doubt i made that clear enough.)
> From: Vincent D Murphy [mailto:vdm@...] > > however, i also haven't seen it specified anywhere in the > semantic web > propoganda (in the positive sense of the word) that i've > seen, how you > assert that two URI are equivalent, or identify the same resource. But you will see it specified that a URI can only ever denote one resource. There isn't a way in RDF to say two resources denote the same thing (DAML maybe). It's been a while since I looked at the Model Theory, so I could be wrong there... What you could do with it is merge graphs and from there determine if two URIs are likely as not pointing at the same thing, possibly by swapping one URI for another in a graph and seeing if the entailments remain the same or just counting up how many property values the things have in common. > this troubles me. sometimes i struggle to see how the > semantic web can work without it. Think of how tricky the semantics of object equality can get in Java. I'd be disinclined to bake in resource equality at the RDF level. Bill de hra -- Propylon www.propylon.com
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > They cannot be pointing to the same resource, they have > > different URIs. > > Are you implying that a single resource can't have two or more > identifiers? I would think it can, and that should be no problem. > What do I miss? Hmm. Maybe you are right. I just haven't been thinking about it that way.
So if two identifiers identify the same resource, what assertions can we make? Assuming uri1 and uri2 are the same resource... And assuming the same accept headers, no caching, etc. 1 equivalent representations content1 = server.resource(uri1); // via GET content2 = server.resource(uri2); // via GET // are these true? assert(content1.type == content2.type); assert(content1.length == content2.length); assert(content1.body == content2.body); 2 equivalent state content1.body = "hello world"; content1.type = "text/plain"; server.resource(uri1) = content1; // via PUT content2.body = "<hello>world</hello>"; content2.type = "text/xml"; server.resource(uri2) = content2; // via PUT // are these true? assert(server.resource(uri1).body == content2.body); assert(server.resource(uri1).body != content1.body); assert(server.resource(uri2).body == content2.body); 3 others?
From: "S. Mike Dierken" <mdierken@...> > > So if two identifiers identify the same resource, what assertions can we > make? > > Assuming uri1 and uri2 are the same resource... > And assuming the same accept headers, no caching, etc. > > 1 equivalent representations > content1 = server.resource(uri1); // via GET > content2 = server.resource(uri2); // via GET > > // are these true? > assert(content1.type == content2.type); > assert(content1.length == content2.length); > assert(content1.body == content2.body); Not necessarily. For instance, you may have an online document which show in English for uri1 and French for uri2. Same resource, different representations. > 2 equivalent state > content1.body = "hello world"; > content1.type = "text/plain"; > server.resource(uri1) = content1; // via PUT > > content2.body = "<hello>world</hello>"; > content2.type = "text/xml"; > server.resource(uri2) = content2; // via PUT > > // are these true? > assert(server.resource(uri1).body == content2.body); > assert(server.resource(uri1).body != content1.body); > assert(server.resource(uri2).body == content2.body); I am unclear about what you are asking here. But I'll take a stab and say that only the third assertion is true. --- Seairth Jacobs seairth@...
> > I would think that the naming authority could assert that two > > URIs reference the same resource, and might do that with a third > > resource which is an equivalence relation. > > granted.. > > but shouldn't the equivalence relation be standard, and endorsed by the > W3C or whoever, rather than something each naming authority must > (re)invent? (that was sort of the whole point, though i doubt i made > that clear enough.) The syntax for expressing equivalence relations should be standard (we in the topic maps community have our views on what the standard should be ;-) but anyone the on web should be free to use the syntax. Of course, some expressions of equivalence will be more authoritative than others -- naming autorities, for example. Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
On Sun, Sep 01, 2002 at 10:17:41PM -0000, qchong wrote: > Hello, > I would like to know if anyone has considered how multiple web > services could be composed and coordinated together under the REST > architecture. Specifically: > > 1. What form would the representation of service composition take? A pipeline. > 2. How to handle dynamic binding of multiple services within a > session, given that REST is a stateless and asynchronous model? Why is a session required? > 3. How to automate service discovery, invocation (possibly using > ontology-aware agents?), and execution completion notification, with > provision for graceful recovery from a failed composite service > execution? Whoa, slow down there. "service discovery" is what you do when you find a URI in some manner. "invocation" is just the passage of a message (GET, POST, whatever) through a set of intermediaries in some order. "execution completion notification" seems to be suggesting that a "session" exists. No such beast is required. The message is entirely self-describing. > In a simple composition model, a client (or possibly a coordinator > service) would be responsible for obtaining URLs of the service > providers, invoking them in some order, and converting responses from > one provider into a parameter that would go into the request message > to the other providers. Right, hence the use of data-flow style composition in REST, which is much much simpler because all components have a uniform interface. This is much more amenable to decentralization too. I know because our platform supports fully decentralized routing as well as hub-and- spoke if so desired. > Some way of specifiying how to tranform > between representations would be necessary. Also, this means that > the client (or coordinator) would be responsible for monitoring the > state of the service composition process. Sessions = bad. > What are the kinds of compositions that would work best under REST? Message pipelining is an obvious one. I think there are others. KnowNow found one with the symmetry between GET responses and POST requests. It's still a pipeline, but it's different than with intermediaries since it's not a message pipeline, but a message *body* pipeline. I'm still trying to figure out the difference. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > Not necessarily. For instance, you may have an online document which show > in English for uri1 and French for uri2. Same resource, different > representations. I was thinking that the Accept, Accept-Language, etc. request headers would be used to distinguish certain representations against the same URI. > > // are these true? > > assert(server.resource(uri1).body == content2.body); > > assert(server.resource(uri1).body != content1.body); > > assert(server.resource(uri2).body == content2.body); > > I am unclear about what you are asking here. But I'll take a stab and say > that only the third assertion is true. If I write to URI1, do I see those changes at URI2. If interacting (updating, etc.) with URI1 /never/ appears to change URI2 - if no change is ever visible at the other URI - then why say they are the 'same' resource?
Mathews, Walden wrote, > I suspect that any disagreement about the idempotence of a string > of idempotent HTTP operations has more to do with the way you > might map HTTP operations onto the meaning of 'idempotent' than > with the particular proof you offered. We touched on this before. > What is the 'function' of an HTTP PUT? I.e., which mapping are > we interested in? Clearly, sometimes it's resource before-and-after > state. At other times it may be more like request-to-response > mapping? Yes, I think that's right. The problem here is that these two views clearly aren't equivalent, and are typically in conflict. REST, as I understand it, looks to have a more natural fit with the resource before-and-after state view. So does that mean that REST is in conflict with part of RFC 2616? If it is in conflict, is that a problem for REST, or is it the inevitable consequence of an inconsistency in RFC 2616? FWIW, the interpretation of idempotent sequences of requests isn't merely a niggling theoretical puzzle: it has direct implications for the implementation of HTTP/1.1 request piplining on the client side. Having built non-caching HTTP/1.1 proxies which support piplining across from downstream clients to upstream origin servers, I can vouch for the fact that the tensions in section 9.1 are a real headache with uncomfortable implications for interoperability. Mark (B and N), you've done work in a similar area, so you must have run into the same issue: how did you resolve it? Cheers, Miles
S. Mike Dierken wrote, > > Not necessarily. For instance, you may have an online document > > which show in English for uri1 and French for uri2. Same resource, > > different representations. > > I was thinking that the Accept, Accept-Language, etc. request headers > would be used to distinguish certain representations against the same > URI. Even in this case the response entity is allowed to vary. GET must not mutate the server/resource state, but it doesn't follow that a constant response entity must be returned. Cheers, Miles
> From: S. Mike Dierken [mailto:mdierken@...] > > If interacting (updating, etc.) with URI1 /never/ appears to > change URI2 - if no change is ever visible at the other URI - > then why say they are the 'same' resource? Because you want to use URIs as resource identifiers outside the HTTP context. That is, these things have value outside hypertext retrieval and document oriented worldviews. For example in RDF, who cares whether writing to URI1 affects URI2? If they both represent Planck's constant, of what possible interest is a write operation? What we can care about is the relationship between the two in an RDF graph. If that relationship happens to be resource-identical, then we can do interesting things in terms of merging data. Bill de hra -- Propylon www.propylon.com
> Throwing out the browser as a foundation (or even a good example) for the > 'automatable Web' isn't such a bad thing... Browsers should obviously play nice with any part of the web; but still, I can't think of a machine-to-machine example where a session time-out would be necessary. Nevertheless, Mark's point about proxy caches being able to refresh renders moot the issue I was trying to work through. If they are allowed to refresh when they see fit, that would demand a pretty strict interpretation of safety. All that being said, I still think the Google interface should be GET-able even without a strictly idempotent GET. Their choice of 1000 hits is right on the hairy edge of where it would even matter to a casual developer (the audience they seem to be targeting right now). For this audience it is effectively idempotent. Had they chosen something like a million hits the limit would probably never get hit by anyone, and requiring a POST would be overly strict. Not being able to do some of the XSLT stuff I've been doing with Xoomle and Amazon makes the current Google API less than useful. :[ Thanks all, - Jeff
On Thursday, Sep 5, 2002, at 21:22 Europe/Dublin, S. Mike Dierken wrote: > ----- Original Message ----- > From: "Bill de hra" <dehora@...> > >> I like the idea of stateless servers and client sided session >> management, >> but you'd need to throw out a lot of sites and browsers to see that > realized. > Throwing out the browser as a foundation (or even a good example) for > the > 'automatable Web' isn't such a bad thing... agreed. because of the crippled contemporary browsers, i see REST as being most useful for developing client/server applications where i can control what client is used. it's like a mainframe architecture for the nineties (zeroes?). that way i don't have to deal with html forms and other legacy baggage either. i am experimenting in this regard using perl and poe (poe.perl.org) as a RESTful HTTP server and macos x cocoa apps as clients. the other nice thing is that i can support contemporary browsers, just in the read-only way they support. and perhaps supporting HTML forms via POST where it makes sense. but the custom clients are most powerful because i can have them GET/PUT/DELETE and render/edit XML representations. i think that to a large extent many of the current browsers lock their users into a read-only view of the web. i doubt that IE/netscape were ever architected to allow users to edit representations. aolpress is the last app i saw that did it well. amaya does too but the UI is woeful IMHO. mozilla's editor is a seperate app called composer. why not just have a cursor in the displayed representation (perhaps as part of an edit 'mode'), and a PUT button on the toolbar? i see the seperate app as a false dichotomy from a REST point-of-view. i was wondering whether mozilla (the navigator part) could be made to PUT representations (probably easy enough with some javascript/xul), and whether it would be possible to make representations editable (harder, but possible because mozilla composer exists), but i shelved the idea for a while. i'm waiting for o'reilly's mozilla applications book because right now i find it too difficult to figure out how things work. http://www.oreilly.com/catalog/mozilla/ i am trying to teach myself cocoa development on macos x by writing a RESTful browser. this hasn't advanced much beyond the 'idea' stage and i've just been building interfaces in Interface Builder so far. it has a box for a URL, GET, PUT, DELETE buttons, and a pane for a fully editable view of the representation. and very little else. i'll tell you all if/when it ever works.
Do you mean that the form of representation of URI->URI equivalence should be standardized by the W3C? That seems to make sense, but I didn't think that was the thrust of the original question. I thought the original questions was more to the authority of the assertion than to its format. Walden > -----Original Message----- > From: Vincent D Murphy [mailto:vdm@...] > Sent: Thursday, September 05, 2002 6:10 PM > To: Mathews, Walden > Cc: 'rest-discuss' > Subject: Re: [rest-discuss] Resources vs. Representations > (was Re: Other > v iew of DELETE?) > > > On Thursday, Sep 5, 2002, at 22:30 Europe/Dublin, Mathews, > Walden wrote: > > I would think that the naming authority could assert that two > > URIs reference the same resource, and might do that with a third > > resource which is an equivalence relation. > > granted.. > > but shouldn't the equivalence relation be standard, and > endorsed by the > W3C or whoever, rather than something each naming authority must > (re)invent? (that was sort of the whole point, though i doubt i made > that clear enough.) >
My exposure to RDF & DAML is minimal. But it seems that all it would take to assert that two URI refer to the same resource is a 'deference' property and a logical 'equivalence'. Neither seems like hard baking to me, i.e., they are both rather universally applicable. Walden > -----Original Message----- > From: Bill de hra [mailto:dehora@...] > Sent: Thursday, September 05, 2002 6:21 PM > To: 'Vincent D Murphy' > Cc: 'S. Mike Dierken'; 'rest-discuss' > Subject: RE: [rest-discuss] Resources vs. Representations > (was Re: Other > view of DELETE?) > > > > > From: Vincent D Murphy [mailto:vdm@...] > > > > however, i also haven't seen it specified anywhere in the > > semantic web > > propoganda (in the positive sense of the word) that i've > > seen, how you > > assert that two URI are equivalent, or identify the same resource. > > But you will see it specified that a URI can only ever denote one > resource. There isn't a way in RDF to say two resources > denote the same > thing (DAML maybe). It's been a while since I looked at the Model > Theory, so I could be wrong there... What you could do with > it is merge > graphs and from there determine if two URIs are likely as not pointing > at the same thing, possibly by swapping one URI for another in a graph > and seeing if the entailments remain the same or just counting up how > many property values the things have in common. > > > this troubles me. sometimes i struggle to see how the > > semantic web can work without it. > > Think of how tricky the semantics of object equality can get in Java. > I'd be disinclined to bake in resource equality at the RDF level. > > Bill de hra > -- > Propylon > www.propylon.com > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Looking for a more powerful website? Try GeoCities for $8.95 > per month. > Register your domain name (http://your-name.com). More > storage! No ads! > http://geocities.yahoo.com/ps/info > http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Fri, 6 Sep 2002, Jeffrey Winter wrote: > > All that being said, I still think the Google interface should be > GET-able even without a strictly idempotent GET. Their choice of > 1000 hits is right on the hairy edge of where it would even matter to a > casual developer (the audience they seem to be targeting right now). > For this audience it is effectively idempotent. Had they chosen > something like a million hits the limit would probably never get hit > by anyone, and requiring a POST would be overly strict. I've made roughly the same argument here: http://www.blogstream.com/pauls/1031155140 > Not being able to do some of the XSLT stuff I've been doing with Xoomle > and Amazon makes the current Google API less than useful. :[ I agree. It *is* useful to you because it is *effectively* idempotent. Because you probably don't do anywhere near 1000 hits per day. If you needed to do somewhere between 500-1500 hits per day, you would probably offer Google money for a service that would allow you to get back to "effective idempotence." After all, a service that regularly craps out on you sometime in the afternoon is hardly something you can trust and build important applications on. Paul Prescod
> -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Friday, September 06, 2002 12:54 AM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Idempotent sequences > > The problem here is that these two views clearly aren't > equivalent, and > are typically in conflict. REST, as I understand it, looks to have a > more natural fit with the resource before-and-after state > view. So does > that mean that REST is in conflict with part of RFC 2616? If it is in > conflict, is that a problem for REST, or is it the inevitable > consequence of an inconsistency in RFC 2616? Sorry, which part of 2616 do you think is in conflict with REST over the issue of idempotence? Walden
> From: Mathews, Walden [mailto:waldenm@...] > > My exposure to RDF & DAML is minimal. But it seems that all > it would take to assert that two URI refer to the same > resource is a 'deference' property and a logical > 'equivalence'. Neither seems like hard baking to me, i.e., > they are both rather universally applicable. If you mean equivalence of representations, I don't think that would work very well. Bill de hra -- Propylon www.propylon.com
I'll take a stab ... > -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Thursday, September 05, 2002 10:38 PM > To: rest-discuss > Subject: [rest-discuss] Resources - when two are one > > > So if two identifiers identify the same resource, what > assertions can we > make? > > Assuming uri1 and uri2 are the same resource... > And assuming the same accept headers, no caching, etc. > > 1 equivalent representations > content1 = server.resource(uri1); // via GET > content2 = server.resource(uri2); // via GET > > // are these true? > assert(content1.type == content2.type); > assert(content1.length == content2.length); > assert(content1.body == content2.body); No to all, not even if the two GETs both happen 'at the same time t'. Practically speaking, I intuit that there should be high consistency, but I don't know how to formalize that expectation. > > 2 equivalent state > content1.body = "hello world"; > content1.type = "text/plain"; > server.resource(uri1) = content1; // via PUT > > content2.body = "<hello>world</hello>"; > content2.type = "text/xml"; > server.resource(uri2) = content2; // via PUT > > // are these true? > assert(server.resource(uri1).body == content2.body); According to that weird 'PUT' rule, it would have to be :-( > assert(server.resource(uri1).body != content1.body); Ditto :-( > assert(server.resource(uri2).body == content2.body); Stop, you're making me suicidal :-( Try running this simulation with MarkB's 'SET' in place of 'PUT' and watch some different answers come pouring out. :-) Walden
> -----Original Message----- > From: Bill de hra [mailto:dehora@eircom.net] > Sent: Friday, September 06, 2002 10:55 AM > To: Mathews, Walden; 'Vincent D Murphy' > Cc: 'S. Mike Dierken'; 'rest-discuss' > Subject: RE: [rest-discuss] Resources vs. Representations > (was Re: Other > view of DELETE?) > > > > > > From: Mathews, Walden [mailto:waldenm@...] > > > > My exposure to RDF & DAML is minimal. But it seems that all > > it would take to assert that two URI refer to the same > > resource is a 'deference' property and a logical > > 'equivalence'. Neither seems like hard baking to me, i.e., > > they are both rather universally applicable. > > If you mean equivalence of representations, I don't think that would > work very well. Agreed. I mean that two URIs are 'equivalent' => they both reference the same resource. I.e., when I say 'deference' above, I mean the traversal from URI to its resource, not from resource to representation, and certainly not all the way from URI to representation. Walden
Dear Abby, In all of these conversations, we keep speaking of resource state. However, I am losing all understanding of what resource state actually is... A resource has a state. One can only retrieve a representation of the current state of a resource. But then we are told that we can receive different representations of the same state. For instance, the same resource could be returned in different spoken languages or in different content-types. However, these are both indicated by HTTP headers and not within the returned entity itself. However, it you look at the infamous "hit counter", the returned entity could differ between calls. But it seems to me that people are saying that the state hasn't necessarily changed. If this is true, then it seems to me that the concept of "state" is more of a logical (?) concept than a physical (?) concept. In other words, state is subjective. One person may say that the state of a resource means one thing while another person would say that the state of another resource means something entirely different. Is this true? And if so, what is the value of talking about state when discussing REST? Isn't this just adding one more jargon word for us to all trip over? Signed, In A State of Confussion (aka: --- Seairth Jacobs seairth@... )
FWIW, both HTTP 301 and daml:equivalentTo should be considered authoritative with respect to asserting resource equivalence. I also believe that they are equivalent, ala; GET(uri1) = 301(uri2) <=> uri1 daml:equivalentTo uri2 but I could be wrong about that, not being a DAML guru. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
My reservations about 301 indicating equivalence comes from the asymmetry of 301, but otherwise I see where you're coming from. As for authoritative, I assume your DAML example was offered by the naming authority, that latter fact making it authoritative, not the fact that it's DAML (or damn anything, for that matter). :-) Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Friday, September 06, 2002 12:49 PM > To: Mathews, Walden > Cc: 'Bill de hra'; 'Vincent D Murphy'; 'S. Mike Dierken'; > 'rest-discuss' > Subject: Re: [rest-discuss] Resources vs. Representations > (was Re: Other > v iew of DELETE?) > > > FWIW, both HTTP 301 and daml:equivalentTo should be considered > authoritative with respect to asserting resource equivalence. > I also believe that they are equivalent, ala; > > GET(uri1) = 301(uri2) <=> uri1 daml:equivalentTo uri2 > > but I could be wrong about that, not being a DAML guru. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
On Fri, Sep 06, 2002 at 01:08:32PM -0400, Mathews, Walden wrote: > My reservations about 301 indicating equivalence comes from the > asymmetry of 301, but otherwise I see where you're coming from. Hmm, what asymmetry? > As for authoritative, I assume your DAML example was offered > by the naming authority, that latter fact making it authoritative, > not the fact that it's DAML (or damn anything, for that matter). > :-) Heh, yep. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
From: "Mathews, Walden" <waldenm@...> > > My reservations about 301 indicating equivalence comes from the > asymmetry of 301, but otherwise I see where you're coming from. How about if we defined a new content-type (e.g. "text/uri-equivalent") such that we could make a GET request to any URI where the content-type was passed in the Accept: header? In return, assuming that the server recognized the content-type, it would return a CR/LF delimited list of all equivalent URIs that it knows about. The client can then use the list to determine equivalence itself by testing the second URI against the returned list. --- Seairth Jacobs seairth@...
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Friday, September 06, 2002 1:20 PM > To: Mathews, Walden > Cc: 'Mark Baker'; 'Bill de hra'; 'Vincent D Murphy'; 'S. > Mike Dierken'; > 'rest-discuss' > Subject: Re: [rest-discuss] Resources vs. Representations > (was Re: Other > v iew of DELETE?) > > > On Fri, Sep 06, 2002 at 01:08:32PM -0400, Mathews, Walden wrote: > > My reservations about 301 indicating equivalence comes from the > > asymmetry of 301, but otherwise I see where you're coming from. > > Hmm, what asymmetry? X says "see Y", but Y doesn't say "see X", so it's asymmetric. Walden
On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote: > Mathews, Walden wrote, > > I suspect that any disagreement about the idempotence of a string > > of idempotent HTTP operations has more to do with the way you > > might map HTTP operations onto the meaning of 'idempotent' than > > with the particular proof you offered. We touched on this before. > > What is the 'function' of an HTTP PUT? I.e., which mapping are > > we interested in? Clearly, sometimes it's resource before-and-after > > state. At other times it may be more like request-to-response > > mapping? > > Yes, I think that's right. I don't understand the distinction I guess. > The problem here is that these two views clearly aren't equivalent, and > are typically in conflict. REST, as I understand it, looks to have a > more natural fit with the resource before-and-after state view. So does > that mean that REST is in conflict with part of RFC 2616? If it is in > conflict, is that a problem for REST, or is it the inevitable > consequence of an inconsistency in RFC 2616? > > FWIW, the interpretation of idempotent sequences of requests isn't > merely a niggling theoretical puzzle: it has direct implications for > the implementation of HTTP/1.1 request piplining on the client side. > Having built non-caching HTTP/1.1 proxies which support piplining > across from downstream clients to upstream origin servers, I can vouch > for the fact that the tensions in section 9.1 are a real headache with > uncomfortable implications for interoperability. > > Mark (B and N), you've done work in a similar area, so you must have run > into the same issue: how did you resolve it? We haven't had any troubles. We tried to use Jeff Mogul's out-of-order spec, but had practical issues with it (it requires using a new client stack). But we don't have a lot of heard reliability guarantees in our use of our platform, so it's possible that I'm missing an edge case that demonstrates the disconnect. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mathews, Walden wrote, > Miles Sabin wrote, > > The problem here is that these two views clearly aren't equivalent, > > and are typically in conflict. REST, as I understand it, looks to > > have a more natural fit with the resource before-and-after state > > view. So does that mean that REST is in conflict with part of RFC > > 2616? If it is in conflict, is that a problem for REST, or is it the > > inevitable consequence of an inconsistency in RFC 2616? > > Sorry, which part of 2616 do you think is in conflict with REST over > the issue of idempotence? REST operates only in terms of resource/server state (ie. the resource before-and-after state view) and understands idempotence in only those terms. RFC 2616's understanding of idempotence seems to defined in terms of both resource/server state and client-visible results. That means it's likely that there will be cases which are idempotent according to REST, but not according to RFC 2616 (and possibly vice versa). My proof that on the resource/server state view (which I take to be the REST view) all sequences of idempotent requests are idempotent sequences looks like being an example because it rules out a possibility explictly mentioned by RFC 2616. It could be that RFC 2616 is wrong to suggest the possiblity of non-idempotent sequences of idempotent methods. OTOH, it could mean that there's a disconnect with REST, and that RFC 2616 really does mean to include client visible results in it's definition of idempotence (tho' if that's the case there are some delicate issues with client visible results of PUT and DELETE). I'd like to know which. If nothing else, it'd make implementing HTTP/1.1 request piplining a lot easier if the REST view is right. Cheers, Miles
Mark Baker wrote, > On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote: > > Mathews, Walden wrote, > > > > > I suspect that any disagreement about the idempotence of a string > > > of idempotent HTTP operations has more to do with the way you > > > might map HTTP operations onto the meaning of 'idempotent' than > > > with the particular proof you offered. We touched on this > > > before. What is the 'function' of an HTTP PUT? I.e., which > > > mapping are we interested in? Clearly, sometimes it's resource > > > before-and-after state. At other times it may be more like > > > request-to-response mapping? > > > > Yes, I think that's right. > > I don't understand the distinction I guess. OK, I think this example illustrates the difference, DELETE /foo => 200 OK DELETE /foo => 404 Not Found On the resource/server state view the only things which count towards idempotence are changes of state at the server (I take this to be the REST view). Because the effect on the server of deleting /foo two or more times is the same as the effect on the server of deleting it just once we can count DELETE as idempotent. On the client-visible-effects view the result is relevant (maybe as well as server state, maybe instead of). Because the client visible results of the second and subsequent deletions of /foo are different from that of the first we can't count DELETE as idempotent. Given that RFC 2616 stipulates that DELETE is idempotent it seems as tho' the client-visible-effects view must be wrong. But that can't be the whole story because of RFC 2616's allusions to non-idempotent sequences of idempotent requests. If my proof that on the resource/ server view all sequences of idempotent requests are idempotent sequences is correct, then either there's something wrong with RFC 2616 (maybe the discussion of non-idempotent sequences should be dropped, or maybe there's an inconsistency somewhere), or there's something wrong with the resource/server state view and hence a disconnect between REST and RFC 2616. > We haven't had any troubles. We tried to use Jeff Mogul's > out-of-order spec, but had practical issues with it (it requires using > a new client stack). But we don't have a lot of heard reliability > guarantees in our use of our platform, so it's possible that I'm > missing an edge case that demonstrates the disconnect. Does your client stack implement request piplining? If it does, there's presumably somewhere where a decision has to be made about whether to pipeline a request immediately or wait for pending responses to arrive. I played cautious and only allowed piplining for GET and then only if the only pending responses were for GETs. Cheers, Miles
On Fri, Sep 06, 2002 at 08:18:58PM +0100, Miles Sabin wrote: > OK, I think this example illustrates the difference, Ah, ok. I didn't recognize those terms as characterizing this example. > DELETE /foo => 200 OK > DELETE /foo => 404 Not Found I wonder, but I can't find anything in 2616 which says that a DELETE on a non-existent resource has to return 404. I also can't find anything that suggests that a 200 response is wrong. So perhaps DELETE is just under-defined? Are there other examples that demonstrate this issue that don't use DELETE? Conditional PUTs maybe? Dunno. > Does your client stack implement request piplining? If it does, there's > presumably somewhere where a decision has to be made about whether to > pipeline a request immediately or wait for pending responses to arrive. > I played cautious and only allowed piplining for GET and then only if > the only pending responses were for GETs. We only block on non-idempotent methods (POST). MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote, > Ah, ok. I didn't recognize those terms as characterizing this > example. > > > DELETE /foo => 200 OK > > DELETE /foo => 404 Not Found > > I wonder, but I can't find anything in 2616 which says that a DELETE > on a non-existent resource has to return 404. I also can't find > anything that suggests that a 200 response is wrong. True, but consider this sequence, DELETE /foo => 200 OK GET /foo => 404 Not Found DELETE /foo => 200 OK (Huh??? Wasn't /foo gone just a moment ago ?) > So perhaps DELETE is just under-defined? Perhaps, but I don't think 200 would be the right way to fill out the gap in this case. > Are there other examples that demonstrate this issue that don't use > DELETE? Conditional PUTs maybe? Dunno. Well, anything where you'd expect to get a different response on the first request than on a second or subsequent request. Actually if the first PUT creates a new resource the request doesn't even need to be conditional to get something similar, PUT /foo => 201 Created (this is a MUST in 9.6) PUT /foo => 200 OK (this is a SHOULD) Given that this behavior isn't underspecified, PUT is probably a better eg. than DELETE. > > Does your client stack implement request piplining? If it does, > > there's presumably somewhere where a decision has to be made about > > whether to pipeline a request immediately or wait for pending > > responses to arrive. I played cautious and only allowed piplining > > for GET and then only if the only pending responses were for GETs. > > We only block on non-idempotent methods (POST). So unless I'm missing something you're treating all sequences of idempotent requests as idempotent sequences? In which case how do you interpret that passage from RFC 2616, 9.1? (seeing as you're ignoring it ;-) Cheers, Miles
Miles, This is not a properly researched statement (sorry for that, no time) but I think I recall the same language in the REST manifesto (to be called "maniRESTo" hence) about non-idempotence in sequences of idempotent operations. So if that's true, then it's not RFC 2616 vs. REST, it's something else. Walden > -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Friday, September 06, 2002 3:19 PM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Idempotent sequences > > > Mark Baker wrote, > > On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote: > > > Mathews, Walden wrote, > > > > > > > I suspect that any disagreement about the idempotence > of a string > > > > of idempotent HTTP operations has more to do with the way you > > > > might map HTTP operations onto the meaning of 'idempotent' than > > > > with the particular proof you offered. We touched on this > > > > before. What is the 'function' of an HTTP PUT? I.e., which > > > > mapping are we interested in? Clearly, sometimes it's resource > > > > before-and-after state. At other times it may be more like > > > > request-to-response mapping? > > > > > > Yes, I think that's right. > > > > I don't understand the distinction I guess. > > OK, I think this example illustrates the difference, > > DELETE /foo => 200 OK > DELETE /foo => 404 Not Found > > On the resource/server state view the only things which count towards > idempotence are changes of state at the server (I take this to be the > REST view). Because the effect on the server of deleting /foo two or > more times is the same as the effect on the server of > deleting it just > once we can count DELETE as idempotent. > > On the client-visible-effects view the result is relevant > (maybe as well > as server state, maybe instead of). Because the client > visible results > of the second and subsequent deletions of /foo are different > from that > of the first we can't count DELETE as idempotent. > > Given that RFC 2616 stipulates that DELETE is idempotent it seems as > tho' the client-visible-effects view must be wrong. But that can't be > the whole story because of RFC 2616's allusions to non-idempotent > sequences of idempotent requests. If my proof that on the resource/ > server view all sequences of idempotent requests are idempotent > sequences is correct, then either there's something wrong > with RFC 2616 > (maybe the discussion of non-idempotent sequences should be > dropped, or > maybe there's an inconsistency somewhere), or there's something wrong > with the resource/server state view and hence a disconnect > between REST > and RFC 2616. > > > We haven't had any troubles. We tried to use Jeff Mogul's > > out-of-order spec, but had practical issues with it (it > requires using > > a new client stack). But we don't have a lot of heard reliability > > guarantees in our use of our platform, so it's possible that I'm > > missing an edge case that demonstrates the disconnect. > > Does your client stack implement request piplining? If it > does, there's > presumably somewhere where a decision has to be made about whether to > pipeline a request immediately or wait for pending responses > to arrive. > I played cautious and only allowed piplining for GET and then only if > the only pending responses were for GETs. > > Cheers, > > > Miles > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > i doubt that IE/netscape were ever architected to allow users to edit representations. IE has some pretty amazing 'edit mode' DHTML capabilities. With DOM events and javascript you can build a full wysiwyg editor totally within the browser. I even remember seeing some company (blox?) with a spreadsheet done in dhtml+script.
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > > > // are these true? > > assert(server.resource(uri1).body == content2.body); > > According to that weird 'PUT' rule, it would have to be :-( I was assuming that the GET requests against the two different URI (which are the 'same' resource) have the exact same headers. I wasn't relying on PUT's weird definition for the content to be equivalent. I'm just trying to figure out /why/ they would be different.
----- Original Message ----- From: "Miles Sabin" <miles@...> > S. Mike Dierken wrote, > > > Not necessarily. For instance, you may have an online document > > > which show in English for uri1 and French for uri2. Same resource, > > > different representations. > > > > I was thinking that the Accept, Accept-Language, etc. request headers > > would be used to distinguish certain representations against the same > > URI. > > Even in this case the response entity is allowed to vary. GET must not > mutate the server/resource state, but it doesn't follow that a constant > response entity must be returned. Yes, I got that... its the approach where you have the same resource, but different representation at /different/ URIs. I don't get that usage. HTTP has enough headers to do most any varying representation against a single URI. I'm looking for what guarantees can be made when two URI are one resource.
----- Original Message ----- From: <paul@...> > After all, a service that regularly craps out on you sometime in the afternoon > is hardly something you can trust and build important applications on. You mean like a programmer without coffee?
Good gravy... I was going to post the same question last night.... ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Friday, September 06, 2002 8:41 AM Subject: [rest-discuss] what is state?
Seairth Jacobs wrote: >Not necessarily. For instance, you may have an online document which show >in English for uri1 and French for uri2. Same resource, different >representations. > Your mistake is thinking that the document is the resource. In this case, it is not. Using your scheme, the resource identified by uri1 is 'the document rendered in English'. The resource identified by uri2 is 'the document rendered in French'. Of course, one can argue as to whether this is an appropriate way to make the French and English version of the document available... --Chuck
Mark Baker wrote: >On Thu, Sep 05, 2002 at 01:59:40PM -0400, Mathews, Walden wrote: > >>Oh, I wanted to say one other thing on this subject. There is >>this idea that if we PUT a resource through its URI, then we GET >>that resource back, we should get back the same value as we PUT. >>That statement implies that we have representation-level control, >>which we do not. It would make more sense to think of it this >>way. If we PUT a representation to a URI, then GET back a representation, >>the latter representation *means the same thing* as the former, >>though it may differ in format or even typographically. THoughts? >> > >Actually, PUT's a bit funny that way. It's definined to really mean >"store" more than "set the state", so it is expected that bits are >preserved. > I'm having a hard time understanding why you say this. In reading 2616, I can see how that might be one possible interpretation, but I don't see that it requires that interpretation. Perhaps I'm missing something (quite likely). I would like to think that if I want to create a resource that indicates the temperature in Paris at 0600 25-May-2002, I should be able to PUT the temperature in degrees Farenheit or Celcius. And further, assuming some suitable kind of content negotiation, I would think that even though I PUT degrees Farenheit, I should be able to GET degrees Celcius. --Chuck
From: "Chuck Hinson" <cmhinson@...> > > >Not necessarily. For instance, you may have an online document which show > >in English for uri1 and French for uri2. Same resource, different > >representations. > > > Your mistake is thinking that the document is the resource. In this > case, it is not. Using your scheme, the resource identified by uri1 is > 'the document rendered in English'. The resource identified by uri2 is > 'the document rendered in French'. Okay, change it from "an online document" to "a resource". I think the example was perfectly valid. Of course, it was pointed out that this particular example gets into the issue of the "Accept-Language". The point I was making was that it's perfectly legitimate to have a single resource that returns different representations (where only the entity is different). Therefore, you could not depend on content-type, content-length, or the entity body itself (or any combination of them) to confidently state whether two URIs point to the same resource or not. --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > The point > I was making was that it's perfectly legitimate to have a single resource > that returns different representations (where only the entity is different). > Therefore, you could not depend on content-type, content-length, or the > entity body itself (or any combination of them) to confidently state > whether two URIs point to the same resource or not. Right - so if we /did/ hold the accept-style headers constant for requests against the two URIs, what logical guarantees can be made? If not for read-operations, what about write-operations? Will there be a guarantee that a write operation of some kind against uri1 has a visible effect when inspecting uri2?
From: "Chuck Hinson" <cmhinson@...>
>
> Seairth Jacobs wrote:
>
> >In all of these conversations, we keep speaking of resource state.
However,
> >I am losing all understanding of what resource state actually is...
> >
> >A resource has a state. One can only retrieve a representation of the
> >current state of a resource.
> >
> >But then we are told that we can receive different representations of the
> >same state. For instance, the same resource could be returned in
different
> >spoken languages or in different content-types. However, these are both
> >indicated by HTTP headers and not within the returned entity itself.
> >
> What is the problem with that? If the resource is 'the temperature at
> which water freezes' then there are at least two representations: 32
> degrees Farenhiet or 0 degrees Celsius. (Ignore for now how the server
> decides which representation to deliver.)
I have not problem with that. At this point, I would consider "state" and
"resource" to be one and the same.
> >
> >However, it you look at the infamous "hit counter", the returned entity
> >could differ between calls. But it seems to me that people are saying
that
> >the state hasn't necessarily changed.
> >
> >If this is true, then it seems to me that the concept of "state" is more
of
> >a logical (?) concept than a physical (?) concept.
> >
>
> If I understand your distinction between logical and physical, then I
> would say that not only is "state" a logical concept, but so is
> "resource". The only thing that is "physical" is the representation.
Sure, I too believe that "resources" only logically exist. It is not
possible for a client to *know* the physical format of what makes up the
"resource".
I realize after reading my original post that I wasn't very clear in my
thoughts. So, I'll try again...
In REST, we have three things (of interest to this topic):
1) Resource : we all agree that a resource is something identified by a URI.
The resource itself is only a concept. It may or may not have a one-to-one
relationship with a "physical" entity (file, purchase order, person, car,
etc.). For instance, one could have a purchase order stored in multiple
tables on a remote SQL server and we would still be able to consider the PO
as a resource. Also, it is possible for more than one URI to identify the
same resource.
2) Representation : when one requests a resource, it can never be given the
actual resource. Instead, the request gets back a representation of the
resource. This representation is unique to the request URI (though more
than one URI could return unique representations that are byte-wise
identical). An important point here is that "representation" only has
meaning in context to a response from the server. In other words, one
cannot speak of sending a representation in a request.
3) State : what is state? On the one hand, I think of state in the
"traditional" sense, which just means "what the resource is at a given
moment in time (usually 'now')". But it is not possible to know what the
state of a resource is. All that one can know is the representation
returned, which is presumably the "current state". In fact, all that is
ever visible is the "current state". From what I've read so far, there's
nothing in REST itself with clearly defines how to know when "state" has
changed. This is left up to the application.
The other way of thinking of state it to related it to "representation"
instead. In other words, under this view, all that a client knows is the
state of a resource, not the resource itself. When we PUT an entity, we are
PUTting "the current state" of a resource and not the resource itself. When
we use GET, we get back a "representation of the state of the resource", not
the resource itself. This view certainly makes it more clear what "state"
is, but it also raises some questions.
a) RFC2616 Section 9.6 (PUT) talks about the ability of a client to
request the creation of a resource located at the Request-URI. Now, in term
s of REST, would it be more appropriate to say that the client is requesting
the creation of a resource whose initial state is that of the
request-entity?
b) If you have two URIs identifing the same resource, suppose the
following sequence:
PUT <entity> uri1
GET uri1
PUT <entity2> uri2
GET uri1
We would agree that the state of the resource changed after each PUT
request. However, it would still be possible for the second GET to return a
byte-wise identical representation as the first GET. How would we know that
the state changed? Or is this scenario not allowed when using PUT? Can
this only happen with POST?
c) When issuing a DELETE against a URI, are we deleting the current
state or the resource itself? [note: In an earlier post, I had suggested
that the DELETE was actually deleting the identity (i.e. the relationship of
the URI to the resource). It was up to the server to delete the resource or
not.]
d) Does a URI identify the state of a resource or the resource itself?
<sigh>well, I had to step away again and have lost my train of thought...
again. re-reading what I wrote hasn't helped, so I will stop here.</sigh>
I guess the nutshell version of all of the above is that "state" obviously
has a place in the REST (it's even in the name!). But I am not
understanding how it fits. I have all sorts of individual notions of how
"state" may be used, but none of them really work with each other and they
all bring up questions that cause the REST model to be unclear in other
areas.
Now, I realize that this could also be due to the fact that we use HTTP 1.1
as a RESTful example. I am beginning to wonder if this is not so much the
case as we are led to believe. Or it could be that the things I am asking
about and the questions I have are mostly "edge cases" and therefore less
likely to be an issue for 80% of the people who will use REST....
---
Seairth Jacobs
seairth@...
On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote: > 2) Representation : when one requests a resource, it can never be > given the > actual resource. Instead, the request gets back a representation of > the > resource. This representation is unique to the request URI (though > more > than one URI could return unique representations that are byte-wise > identical). agreed.. > An important point here is that "representation" only has > meaning in context to a response from the server. In other words, one > cannot speak of sending a representation in a request. i think this is incorrect. can't representations be PUT/POSTed as well, as the body of the request?
From: "Vincent D Murphy" <vdm@...> > > On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote: > > An important point here is that "representation" only has > > meaning in context to a response from the server. In other words, one > > cannot speak of sending a representation in a request. > > i think this is incorrect. can't representations be PUT/POSTed as > well, as the body of the request? No, I wouldn't think so. You can send "request data". The data may either have a specific meaning (e.g. PUT of a resource state) or not (e.g. various uses of POST), but it isn't a representation. A representation (in the context of this discussion) can only exist as it relates to a resource. Only the server has resources and only the server returns representations of those resources. I think... --- Seairth Jacobs seairth@...
S. Mike Dierken wrote:
>----- Original Message -----
>From: "Seairth Jacobs" <seairth@...>
>
>>The point
>>I was making was that it's perfectly legitimate to have a single resource
>>that returns different representations (where only the entity is
>>
>different).
>
>>Therefore, you could not depend on content-type, content-length, or the
>>entity body itself (or any combination of them) to confidently state
>>whether two URIs point to the same resource or not.
>>
>
>Right - so if we /did/ hold the accept-style headers constant for requests
>against the two URIs, what logical guarantees can be made?
>If not for read-operations, what about write-operations?
>Will there be a guarantee that a write operation of some kind against uri1
>has a visible effect when inspecting uri2?
>
First, I'm not sure I understand why it would be useful to be able to do
this.
Second, I don't think you can make any sort of generalization about what
behavior or properties you might observe when two URIs name the same
resource. The characteristics of resources vary so greatly, that I
don't see that there would be any way to establish any kind of generic
guarantee that would hold across all resources. I'm sure that for set
of simple cases you might be able to guarantee some sort of byte-wise
equivalence, but I don't see that happening across all types of resources.
Third, I suspect that in many cases, when two URIs appear to name the
same resource, they actually don't. For example, some people might
(mistakenly) believe that the following URIs name the same resource
http://www.w3.org/TR/2002/WD-webarch-20020830/
http://www.w3.org/TR/webarch/
--Chuck
Seairth Jacobs wrote: >From: "Vincent D Murphy" <vdm@...> > >>On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote: >> >>>An important point here is that "representation" only has >>>meaning in context to a response from the server. In other words, one >>>cannot speak of sending a representation in a request. >>> >>i think this is incorrect. can't representations be PUT/POSTed as >>well, as the body of the request? >> > >No, I wouldn't think so. You can send "request data". The data may either >have a specific meaning (e.g. PUT of a resource state) or not (e.g. various >uses of POST), but it isn't a representation. A representation (in the >context of this discussion) can only exist as it relates to a resource. >Only the server has resources and only the server returns representations of >those resources. I think... > Yes, you do send representations in PUT and POST. The "Transfer" in Representational State Transfer is not just for responses - it also applies to requests. A PUT request contains a representation of the resource you want to store at the specified URI. And according to Mark B., the representation transferred in the PUT is the same representation (bytewise) that'll be returned by a GET of the same resource (assuming no intervening state changes). I would argue the same holds for POST. A POST request transfers an entity to the server. I don't see any reason not to consider that entity a representation of some (perhaps unnamed) resource. In fact, in some cases, the representation that is transferred will be GETable as a named resource once it is submitted to the server. --Chuck
>
> Second, I don't think you can make any sort of generalization about what
> behavior or properties you might observe when two URIs name the same
> resource.
The point I'm making is that any claim that server.resource(uri1) ===
server.resource(uri2) is unverifiable and indistinguishable from bogus
claims like server.resource("www.slashdot.net") ===
server.resource("www.microsoft.com")
If you can't demonstrate any runtime effects of claming two resources are
the same, then why make the claim?
Seairth Jacobs wrote: [...] > >1) Resource : we all agree that a resource is something identified by a URI. >The resource itself is only a concept. It may or may not have a one-to-one >relationship with a "physical" entity (file, purchase order, person, car, >etc.). For instance, one could have a purchase order stored in multiple >tables on a remote SQL server and we would still be able to consider the PO >as a resource. Also, it is possible for more than one URI to identify the >same resource. > For the most part, I think I agree, although I'm suspicious of the first and last sentences. In my mind, the only relationship between URIs and resources is that resources arent very useful if they dont have names with which they can be referenced. > >2) Representation : when one requests a resource, it can never be given the >actual resource. Instead, the request gets back a representation of the >resource. This representation is unique to the request URI (though more >than one URI could return unique representations that are byte-wise >identical). An important point here is that "representation" only has >meaning in context to a response from the server. In other words, one >cannot speak of sending a representation in a request. > I don't understand what you're trying to say when you say the representation is unique to the request URI. A representation only has meaning in connection with the resource it represents. Actually, the meaning of a representation is dependent on the resource it represents. But I'm not sure what we're accomplishing by pointing that out. > > >3) State : what is state? On the one hand, I think of state in the >"traditional" sense, which just means "what the resource is at a given >moment in time (usually 'now')". But it is not possible to know what the >state of a resource is. > What do you mean by this? The representation tells you exactly what the state of the resource was when the request was serviced. > All that one can know is the representation >returned, which is presumably the "current state". In fact, all that is >ever visible is the "current state". From what I've read so far, there's >nothing in REST itself with clearly defines how to know when "state" has >changed. This is left up to the application. > I would agree - REST focuses mainly on transferring state. Only the application can determine what you should do or observe in order to determine whether the state of a resource has changed. > > >The other way of thinking of state it to related it to "representation" >instead. In other words, under this view, all that a client knows is the >state of a resource, not the resource itself. When we PUT an entity, we are >PUTting "the current state" of a resource and not the resource itself. > When we do a PUT, we are transferring a representation of the state we want the specified resource to have. If the specified resource does not already exist, it will be created before the PUT operation is applied to it. >When >we use GET, we get back a "representation of the state of the resource", not >the resource itself. This view certainly makes it more clear what "state" >is, but it also raises some questions. > > a) RFC2616 Section 9.6 (PUT) talks about the ability of a client to >request the creation of a resource located at the Request-URI. Now, in term >s of REST, would it be more appropriate to say that the client is requesting >the creation of a resource whose initial state is that of the >request-entity? > From 9.6 in 2616 <quote> The PUT method requests that the enclosed entity be stored under the supplied Request-URI. </quote> The enclosed entity is a representation of the resource's "inital state" as you call it. > > b) If you have two URIs identifing the same resource, suppose the >following sequence: > > PUT <entity> uri1 > GET uri1 > PUT <entity2> uri2 > GET uri1 > > We would agree that the state of the resource changed after each PUT >request. > I'm not sure that I would agree to that. You can't know whether or not the resource will change state without knowing the specifics of that particular resource. For some resources, your statement would be true. For others it would not. >However, it would still be possible for the second GET to return a >byte-wise identical representation as the first GET. How would we know that >the state changed? > You'd have to read the [API] documentation for that specific resource in order to know what you have to do to detect a state change. >Or is this scenario not allowed when using PUT? Can >this only happen with POST? > > c) When issuing a DELETE against a URI, are we deleting the current >state or the resource itself? > From 9.7 in 2616 <quote>The DELETE method requests that the origin server delete the resource identified by the Request-URI. </quote> >[note: In an earlier post, I had suggested >that the DELETE was actually deleting the identity (i.e. the relationship of >the URI to the resource). It was up to the server to delete the resource or >not.] > > d) Does a URI identify the state of a resource or the resource itself? > A URI identifies a resource. The state of the resource is what is transferred as input and/or output by some of the various methods that can be applied to the resource. I'm not sure whether I'm helping here or not. It all seems clear to me (for now) - I'm just not sure I can describe things in a way that's helpful to anyone else. --Chuck
S. Mike Dierken wrote:
>
>>Second, I don't think you can make any sort of generalization about what
>>behavior or properties you might observe when two URIs name the same
>>resource.
>>
>The point I'm making is that any claim that server.resource(uri1) ===
>server.resource(uri2) is unverifiable and indistinguishable from bogus
>claims like server.resource("www.slashdot.net") ===
>server.resource("www.microsoft.com")
>
>If you can't demonstrate any runtime effects of claming two resources are
>the same, then why make the claim?
>
In the general case I agree. For two arbitrary URIs, I don't believe
there's any way to determine whether they identify the same resource or not.
However, for a specific resource identified by two or more URIs, I would
think that it might be possible to determine equivalence of URIs. The
rules for making that determination would, however, only be valid for
that specific resource and would probably require detailed knowledge of
the resource for which URI equivalence was being tested.
Hmm. Having said all that, I'm beginning to think the best you may be
able to do is to determine non-equivalence.
--Chuck
From: "Chuck Hinson" <cmhinson@...> > > Seairth Jacobs wrote: > > >No, I wouldn't think so. You can send "request data". The data may either > >have a specific meaning (e.g. PUT of a resource state) or not (e.g. various > >uses of POST), but it isn't a representation. A representation (in the > >context of this discussion) can only exist as it relates to a resource. > >Only the server has resources and only the server returns representations of > >those resources. I think... > > > Yes, you do send representations in PUT and POST. The "Transfer" in > Representational State Transfer is not just for responses - it also > applies to requests. This makes no sense to me. What is a request entity a representation of? > A PUT request contains a representation of the > resource you want to store at the specified URI. And according to Mark > B., the representation transferred in the PUT is the same representation > (bytewise) that'll be returned by a GET of the same resource (assuming > no intervening state changes). >From RFC2616 Section 9.6: <quote>The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.</quote> I see nothing here saying that the request entity is a representation. All that I see is a request entity that may replace or create a new resource identified by the request-URI. > I would argue the same holds for POST. A POST request transfers an > entity to the server. I don't see any reason not to consider that > entity a representation of some (perhaps unnamed) resource. In fact, in > some cases, the representation that is transferred will be GETable as a > named resource once it is submitted to the server. I would be even less inclined to agree with you for POST. POST only tansfers a request entity. That's it. Seeing it as a representation of an unnamed resource only make the REST model (as applied to HTTP) more confusing to me, not less. This would be an entirely different matter if the request also contained a URI that identified an actual resource that the request entity could be considered a representation of (sort of a PUSH usage instead of PULL). But it doesn't. Not even when using PUT. --- Seairth Jacobs seairth@...
On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote: > I would argue the same holds for POST. A POST request transfers an > entity to the server. I don't see any reason not to consider that > entity a representation of some (perhaps unnamed) resource. In fact, in > some cases, the representation that is transferred will be GETable as a > named resource once it is submitted to the server. Exactly. If the data being transferred cannot be described as a representation of some (perhaps unnamed) resource, then you're not doing it right. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote: > On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote: > > I would argue the same holds for POST. A POST request transfers an > > entity to the server. I don't see any reason not to consider that > > entity a representation of some (perhaps unnamed) resource. In fact, in > > some cases, the representation that is transferred will be GETable as a > > named resource once it is submitted to the server. > > Exactly. > > If the data being transferred cannot be described as a representation of > some (perhaps unnamed) resource, then you're not doing it right. Hmm ... On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote: > > I see nothing here saying that the request entity is a representation. All > that I see is a request entity that may replace or create a new resource > identified by the request-URI. This has always bothered me too. Unless I misunderstand the concept of 'representation' (which is perfectly possible--I haven't gotten around to reading Fielding's dissertation or other deep scholarly work on REST), the ability to PUT or POST a representation raises a serious issue which I have not seen addressed on this list. What if a client PUTs a representation of a type that is impractical to transform to the type of the existing resource? Doesn't that effectively cripple the resource, upsetting the expectations of other clients? For example, suppose your resource is an SVG graphic--one of the most information-rich image formats, and one that can be transformed to any output format (known in this context as a representation, right?) you like. So your server might make available JPEG, PNG, and EPS representations of the image. Outbound, there's no problem. But now suppose somebody wants to PUT a JPEG to the URI? If you allow the put, then your information-rich SVG image is now degraded to a dumb JPEG (I'm talking about what happens in the real world, not the MIT Media Lab), which not only contains less information than the old resource, but may be impractical to transform to some of the representation types that are supposed to be available. So do you disallow certain types of representations from being PUT or POSTed? That certainly seems like a practical response to the problem. But I would think that in a very large proportion of cases, you'd have to prohibit any type but the original type of the resource--in which case the distinction between resource and representation seems rather academic. Or am I just confused? -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Seairth Jacobs wrote: >From: "Chuck Hinson" <cmhinson@...> > >>Seairth Jacobs wrote: >> >>>No, I wouldn't think so. You can send "request data". The data may >>> >either > >>>have a specific meaning (e.g. PUT of a resource state) or not (e.g. >>> >various > >>>uses of POST), but it isn't a representation. A representation (in the >>>context of this discussion) can only exist as it relates to a resource. >>>Only the server has resources and only the server returns representations >>> >of > >>>those resources. I think... >>> >>Yes, you do send representations in PUT and POST. The "Transfer" in >>Representational State Transfer is not just for responses - it also >>applies to requests. >> > >This makes no sense to me. What is a request entity a representation of? > It is a respresentation of some resource. One of the main concepts of REST is that you transfer representations of things, not the things themselves. Note that there is no requirement that a resource have a URI. I dont think its a terrible stretch to go from "POSTing some data" to "POSTing a representation." After all, what is the data that you're POSTing but a representation of some concept (resource). > >> A PUT request contains a representation of the >>resource you want to store at the specified URI. And according to Mark >>B., the representation transferred in the PUT is the same representation >>(bytewise) that'll be returned by a GET of the same resource (assuming >>no intervening state changes). >> > >>From RFC2616 Section 9.6: > ><quote>The PUT method requests that the enclosed entity be stored under the >supplied Request-URI. If the Request-URI refers to an already existing >resource, the enclosed entity SHOULD be considered as a modified version of >the one residing on the origin server. If the Request-URI does not point to >an existing resource, and that URI is capable of being defined as a new >resource by the requesting user agent, the origin server can create the >resource with that URI.</quote> > >I see nothing here saying that the request entity is a representation. All >that I see is a request entity that may replace or create a new resource >identified by the request-URI. > The request entity is a representation. In other words, the data in the request entity comprises a representation of some resource/concept. > >>I would argue the same holds for POST. A POST request transfers an >>entity to the server. I don't see any reason not to consider that >>entity a representation of some (perhaps unnamed) resource. In fact, in >>some cases, the representation that is transferred will be GETable as a >>named resource once it is submitted to the server. >> > >I would be even less inclined to agree with you for POST. POST only >tansfers a request entity. That's it. Seeing it as a representation of an >unnamed resource only make the REST model (as applied to HTTP) more >confusing to me, not less. > >This would be an entirely different matter if the request also contained a >URI that identified an actual resource that the request entity could be >considered a representation of (sort of a PUSH usage instead of PULL). But >it doesn't. Not even when using PUT. > See my response above for PUT. REST is about transferring representations of things. You don't transfer anything else between client and server. --Chuck
Matt Gushee wrote:
>On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote:
>
>>On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote:
>>
>>>I would argue the same holds for POST. A POST request transfers an
>>>entity to the server. I don't see any reason not to consider that
>>>entity a representation of some (perhaps unnamed) resource. In fact, in
>>>some cases, the representation that is transferred will be GETable as a
>>>named resource once it is submitted to the server.
>>>
>>Exactly.
>>
>>If the data being transferred cannot be described as a representation of
>>some (perhaps unnamed) resource, then you're not doing it right.
>>
>
>Hmm ...
>
>On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote:
>
>>I see nothing here saying that the request entity is a representation. All
>>that I see is a request entity that may replace or create a new resource
>>identified by the request-URI.
>>
>
>This has always bothered me too. Unless I misunderstand the concept of
>'representation' (which is perfectly possible--I haven't gotten around
>to reading Fielding's dissertation or other deep scholarly work on
>REST), the ability to PUT or POST a representation raises a serious
>issue which I have not seen addressed on this list.
>
>What if a client PUTs a representation of a type that is impractical to
>transform to the type of the existing resource? Doesn't that effectively
>cripple the resource, upsetting the expectations of other clients?
>
The server is free to reject the PUT request with something like:
406 Not Acceptable
409 Conflict
415 Unsupported Media Type
Also, some readings of 2616 woud say that on a PUT, there's no
transforming a representation to the existing resource type. You're
just storing the representation as is.
> For
>example, suppose your resource is an SVG graphic--one of the most
>information-rich image formats, and one that can be transformed to any
>output format (known in this context as a representation, right?) you
>like. So your server might make available JPEG, PNG, and EPS
>representations of the image. Outbound, there's no problem. But now
>suppose somebody wants to PUT a JPEG to the URI? If you allow the put,
>then your information-rich SVG image is now degraded to a dumb JPEG (I'm
>talking about what happens in the real world, not the MIT Media Lab),
>which not only contains less information than the old resource, but may
>be impractical to transform to some of the representation types that are
>supposed to be available.
>
Depending on the definition of the resource, it may be perfectly
reasonable to accept a JPEG as 'input' and transform it to PNG. Yes,
this may result in some degradation of information, but in this case the
owner of the resource has decided that that's OK. Of course the
resource may be defined in such a way that only requests in PNG format
are accepted.
>
>So do you disallow certain types of representations from being PUT or
>POSTed? That certainly seems like a practical response to the problem.
>But I would think that in a very large proportion of cases, you'd have
>to prohibit any type but the original type of the resource--in which
>case the distinction between resource and representation seems rather
>academic.
>
Dont confuse a resource with the entity that backs the resource. A
resource is a logical construct - a concept. A resource may be backed
by a document, and the bytes that comprise that document may correspond
exactly to the representation of the resource, but the resource and the
representation are never the same thing.
--Chuck
On Mon, Sep 09, 2002 at 12:21:34AM -0400, Chuck Hinson wrote: > > > >What if a client PUTs a representation of a type that is impractical to > >transform to the type of the existing resource? Doesn't that effectively > >cripple the resource, upsetting the expectations of other clients? > > > The server is free to reject the PUT request with something like: > 406 Not Acceptable > 409 Conflict > 415 Unsupported Media Type > > Also, some readings of 2616 woud say that on a PUT, there's no > transforming a representation to the existing resource type. You're > just storing the representation as is. In that case, does the PUTted representation become the resource at that URI? If not, the implications are scary. > > > >So do you disallow certain types of representations from being PUT or > >POSTed? That certainly seems like a practical response to the problem. > >But I would think that in a very large proportion of cases, you'd have > >to prohibit any type but the original type of the resource--in which > >case the distinction between resource and representation seems rather > >academic. > > > Dont confuse a resource with the entity that backs the resource. A > resource is a logical construct - a concept. A resource may be backed > by a document, and the bytes that comprise that document may correspond > exactly to the representation of the resource, but the resource and the > representation are never the same thing. I'm aware of the distinction, but I'm questioning whether it has any practical value in cases where there is no transformation. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
> I'm aware of the distinction, but I'm questioning whether it has any > practical value in cases where there is no transformation. "resource vs representation" only makes sense at a conceptual level, not at a protocol-sending-bytes-over-the-wire level. For the image example: - http://foo.com/logo is a resource: a company logo - GET returns a representation of the company logo, possibly with content negotiation applied to determine the image format. - PUT allows the webmaster to change the company logo by uploading a representation of another resource, in this case: "the logo I have been editing to replace our current company logo". This resource does not have a HTTP URI, although it may have a URI in a local namespace, such as a filename. As was described before, the company logo resource can maintain its own policy for accepting PUTs, depending on its internal nature (a PNG file, an SVG file that gets rendered, a program drawing the logo on the fly, who knows). So: - resource is a concept - representation is a stream of bytes you can mess around with Anyone have better definitions? Worth putting them in the REST FAQ, if they are not already. Michael
> > I'm aware of the distinction, but I'm questioning whether it has any > > practical value in cases where there is no transformation. > > "resource vs representation" only makes sense at a conceptual level, not > at a protocol-sending-bytes-over-the-wire level. I wasn't very clear; the answer was supposed to be "no it has no practical value whatsoever, except as an aid to the conceptual design of the system in question." Michael
Matt Gushee wrote: >On Mon, Sep 09, 2002 at 12:21:34AM -0400, Chuck Hinson wrote: > >>>What if a client PUTs a representation of a type that is impractical to >>>transform to the type of the existing resource? Doesn't that effectively >>>cripple the resource, upsetting the expectations of other clients? >>> >>The server is free to reject the PUT request with something like: >> 406 Not Acceptable >> 409 Conflict >> 415 Unsupported Media Type >> >>Also, some readings of 2616 woud say that on a PUT, there's no >>transforming a representation to the existing resource type. You're >>just storing the representation as is. >> > >In that case, does the PUTted representation become the resource at that >URI? > Yes. >If not, the implications are scary. > >>>So do you disallow certain types of representations from being PUT or >>>POSTed? That certainly seems like a practical response to the problem. >>>But I would think that in a very large proportion of cases, you'd have >>>to prohibit any type but the original type of the resource--in which >>>case the distinction between resource and representation seems rather >>>academic. >>> >>Dont confuse a resource with the entity that backs the resource. A >>resource is a logical construct - a concept. A resource may be backed >>by a document, and the bytes that comprise that document may correspond >>exactly to the representation of the resource, but the resource and the >>representation are never the same thing. >> > >I'm aware of the distinction, but I'm questioning whether it has any >practical value in cases where there is no transformation. > I guess I'm not sure I understand what you're getting at. What do you mean by "there is no transformation"? I don't think you can (or should) say that a resource is transformed into a representation - that might imply many things that probably aren't true. It might be better to say that a resource generates a representation. The only entity that knows whether there is "no transformation" is the resource's implementation. No other entity has any way to make that determination - nor do I see any value in trying to do so. When you request a representation of a resource, why do you care how that representation was generated? --Chuck
On Mon, Sep 09, 2002 at 02:59:54PM +1000, Michael Day wrote: > > > > I'm aware of the distinction, but I'm questioning whether it has any > > > practical value in cases where there is no transformation. > > > > "resource vs representation" only makes sense at a conceptual level, not > > at a protocol-sending-bytes-over-the-wire level. > > I wasn't very clear; the answer was supposed to be "no it has no practical > value whatsoever, except as an aid to the conceptual design of the system > in question." Okay, that's pretty much what I thought. I guess I'm satisfied for tonight. Thanks. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
On Mon, Sep 09, 2002 at 01:05:18AM -0400, Chuck Hinson wrote: > >>Dont confuse a resource with the entity that backs the resource. A > >>resource is a logical construct - a concept. A resource may be backed > >>by a document, and the bytes that comprise that document may correspond > >>exactly to the representation of the resource, but the resource and the > >>representation are never the same thing. > >> > > > >I'm aware of the distinction, but I'm questioning whether it has any > >practical value in cases where there is no transformation. > > > I guess I'm not sure I understand what you're getting at. What do you > mean by "there is no transformation"? I don't think you can (or should) > say that a resource is transformed into a representation - that might > imply many things that probably aren't true. It might be better to say > that a resource generates a representation. Whoa, not so fast there! We were talking about PUTting and POSTing things *to* a server ... let's limit it to PUT for the moment. I understand that what lives at the URI is a resource; we are told that what you PUT to the URI is a representation. And--perhaps out of ignorance--I'm seeing conceptual and/or practical difficulties with that notion. When you successfully put a representation, its contents become the contents of a resource, right? And in that process, either those contents can change form (e.g. from one XML vocabulary to another) or they can't. If they can, then there's an issue of how to ensure that the server receives something that can be meaningfully transformed --and I'm wondering if REST has anything to say about that, or if it's left to the application. If, on the other hand, those contents can never change on the way to becoming a resource, then why not say that you 'PUT a resource'? Is there any reason other than 'because that's not how a resource is defined'? > The only entity that knows whether there is "no transformation" is the > resource's implementation. No other entity has any way to make that > determination - nor do I see any value in trying to do so. When you > request a representation of a resource, why do you care how that > representation was generated? Quite right--and my concern at the moment is how to implement those resources. If I were only considering things from the client side, I wouldn't care. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
Mark Baker wrote, > If the data being transferred cannot be described as a representation > of some (perhaps unnamed) resource, then you're not doing it right. If resources can be nameless then we can't define "resource" primarily in terms of URIs ... ie. we can't say, X is a resource if and only if X is identified by some URI I think that raises several interesting questions, * Unnamed resources do away with the "only if", but is this a step in the direction of doing away with the "if" too ... ie. if we can have unnamed resources, why can't we also have names with no resource? eg. http://www.example.com/nothing-here-folks. * If having a URI isn't the criterion of resource-hood, then what is? Is "resource" just an RFC 2396 compliant way of saying "thing"? * In the context of the discussions on the TAG list, is a URI-less resource "part of the Web"? * How, if at all, do the kind of unamed resources that Mark's talking about here relate to RDFs anonymous nodes? Cheers, Miles
> If resources can be nameless then we can't define "resource" primarily > in terms of URIs ... ie. we can't say, > > X is a resource if and only if X is identified by some URI That seems reasonable, as there will always be some things we want to talk about, refer to, infer properties of and so on for which there are no suitable URI schemes. Or, resources that have a local name but no global name, such as the email I am editing right now, before I send it (after it is sent it will end up with possibly many global names, such as message id URI and HTTP URI for the archive, etc). > * Unnamed resources do away with the "only if", but is this a step in > the direction of doing away with the "if" too ... ie. if we can have > unnamed resources, why can't we also have names with no resource? eg. > http://www.example.com/nothing-here-folks. The only way to have a name without a resource is to have a randomly generated URI with no intended meaning whatsoever. That's subtly different from having a meaningful resource with no representation. For example, consider "news for 1 Jan 2003". That's a resource, but until 1 Jan 2003 you won't be able to get a representation of it. Nonetheless, you can reason about it, assert properties of it such as "the news for 1 Jan 2003 will be read by news presenter X" and so on. > * If having a URI isn't the criterion of resource-hood, then what is? Is > "resource" just an RFC 2396 compliant way of saying "thing"? Perhaps this thread would be a good place to come up with a canonical sentence describing resource, if there isn't one already. I see it as being any thing that has a meaning. Which, is not much of a definition. > * In the context of the discussions on the TAG list, is a URI-less > resource "part of the Web"? A few years ago, resources without HTTP URIs would not have been considered to be part of the web (barring FTP, Gopher proxies and what not). Now, who knows? With RDF, presumably foo://your/mother is a perfectly valid resource that's part of the semantic web, once the foo URI scheme has been approved. > * How, if at all, do the kind of unamed resources that Mark's talking > about here relate to RDFs anonymous nodes? Someone who knows more about RDF please answer this :) Michael
Michael Day wrote, > Miles Sabin wrote, > > * Unnamed resources do away with the "only if", but is this a step > > in the direction of doing away with the "if" too ... ie. if we can > > have unnamed resources, why can't we also have names with no > > resource? eg. http://www.example.com/nothing-here-folks. > > The only way to have a name without a resource is to have a randomly > generated URI with no intended meaning whatsoever. Did you try that example URI? If you think a 404 response is a resource, how about, http://this.host.does.not.exist.com/nothing-here-folks The point at issue is whether or not we can treat resources as being defined in terms of URIs ... this is a coherent view, tho' not mine. At the very least for that we need it to be the case that every resource has a URI, and that every URI has a resource (irrespective of whether or not there's a server prepared to return a useful representation). The possibility of unnamed resources is inconsistent with that view, clearly. But the only good argument I've seen against the claim that particular URIs might be empty (have no resource, not name anything, etc., etc.) is that there's nothing more to being a resource than having a URI and that the existence of a corresponding resource is guaranteed by definition. IOW, the argument depends on the definition. But allowing unnamed resources means abandoning the definition, so we might as well be hung for a sheep as a lamb, and allow resourceless names too. Cheers, Miles
> Did you try that example URI? If you think a 404 response is a resource, > how about, > > http://this.host.does.not.exist.com/nothing-here-folks A 404 response is not a resource. Nor is that URI a resource. The question is whether it identifies a resource, or whether you just made it up randomly to demonstrate a point. If you just made it up randomly, then the URI does not identify a resource. (In my opinion. Again, it's a subtle difference, because made up URIs can still identify resources, even the this.host.does... etc. variety. But, made up URIs need not identify resources. Perhaps a good example is John Smith of Number 42 High St, which is an identifier for a resource (some guy). Also, Frodo Baggins of Bag End, which is also an identifier for a resource, in this case a fictional character, so it's not something that you can access directly over HTTP. However FOOP!SQUIGGLE, which I just typed in randomly, is not a resource, nor is Mr FOOP!SQUIGGLE of Number 42 High St, as this identifier does not identify a resource to which I (nor anyone else) has assigned meaning). > The point at issue is whether or not we can treat resources as being > defined in terms of URIs ... this is a coherent view, tho' not mine. > At the very least for that we need it to be the case that every resource > has a URI, and that every URI has a resource (irrespective of whether > or not there's a server prepared to return a useful representation). > The possibility of unnamed resources is inconsistent with that view, > clearly. Not every URI identifies a resource, as the example you gave shows. Two URIs may both return 404, and yet one identifies a resource (such as my future news example) and one does not (such as your random URI example). Result of dereferencing does not indicate resourcefulness; the URI must identify something which has been assigned meaning by someone (or some process, in the case of programs generating/naming resources). > But the only good argument I've seen against the claim that particular > URIs might be empty (have no resource, not name anything, etc., etc.) > is that there's nothing more to being a resource than having a URI and > that the existence of a corresponding resource is guaranteed by > definition. IOW, the argument depends on the definition. But allowing > unnamed resources means abandoning the definition, so we might as well > be hung for a sheep as a lamb, and allow resourceless names too. Resourceless names are certainly possible, nameless resources will exist until we have a method to identify every possible resource, which may take a while. Michael
Michael Day wrote, > Resourceless names are certainly possible, nameless resources will > exist until we have a method to identify every possible resource, > which may take a while. OK, we agree on this. Not everyone does tho' ... Cheers, Miles
> -----Original Message----- > From: Miles Sabin [mailto:miles@...] > Sent: Monday, September 09, 2002 3:47 AM > To: rest-discuss > Subject: [rest-discuss] Unamed resources? (WAS: what is state?) > > > Mark Baker wrote, > > If the data being transferred cannot be described as a > representation > > of some (perhaps unnamed) resource, then you're not doing it right. > > If resources can be nameless then we can't define "resource" > primarily > in terms of URIs ... ie. we can't say, > > X is a resource if and only if X is identified by some URI Agreed that you can't say that. But you might be able to say that "X is a resource if and only if X *could be* identified by some URI". This is pretty broad, granted, but it's not quite vacuous. For instance, "walking down the road" seems to me like something that fails the predicate above. Although there are extreme cases that almost break the rule, remember that the purpose for a resource to exist is to have state that we can communicate about. > > I think that raises several interesting questions, > > * Unnamed resources do away with the "only if", but is this a step in > the direction of doing away with the "if" too ... ie. if we can have > unnamed resources, why can't we also have names with no > resource? eg. > http://www.example.com/nothing-here-folks. It's a funny property of namings that they always seem to bind to some state. Given that REST resources are conceptual, it's hard to imagine naming something that can't be a resource. > > * If having a URI isn't the criterion of resource-hood, then > what is? Is > "resource" just an RFC 2396 compliant way of saying "thing"? It says more than just "thing"; it says "thing with meaning", and moreover, it says "thing with meaning that we can talk about all day long and never change or directly touch the meaning itself". > > * In the context of the discussions on the TAG list, is a URI-less > resource "part of the Web"? I'd say if it's not connected, it's not part of the Web, and if the URI is the only way to connect it, then .... > > * How, if at all, do the kind of unamed resources that Mark's talking > about here relate to RDFs anonymous nodes? Dunno! Walden Mathews
It might be a good idea to realize that the web is evolving from a web of documents into a web of concepts, any of which may at some point be realized in the form of a document. As it undergoes this change, some of the legacy language will get in the way and harken back to a simpler but less versatile time. The description around PUT in RFC 2616 seems to leave a little too little to the imagination. Walden > -----Original Message----- > From: Matt Gushee [mailto:mgushee@...] > Sent: Sunday, September 08, 2002 10:50 PM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] what is state? > > > On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote: > > On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote: > > > I would argue the same holds for POST. A POST request > transfers an > > > entity to the server. I don't see any reason not to > consider that > > > entity a representation of some (perhaps unnamed) > resource. In fact, in > > > some cases, the representation that is transferred will > be GETable as a > > > named resource once it is submitted to the server. > > > > Exactly. > > > > If the data being transferred cannot be described as a > representation of > > some (perhaps unnamed) resource, then you're not doing it right. > > Hmm ... > > On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote: > > > > I see nothing here saying that the request entity is a > representation. All > > that I see is a request entity that may replace or create a > new resource > > identified by the request-URI. > > This has always bothered me too. Unless I misunderstand the concept of > 'representation' (which is perfectly possible--I haven't gotten around > to reading Fielding's dissertation or other deep scholarly work on > REST), the ability to PUT or POST a representation raises a serious > issue which I have not seen addressed on this list. > > What if a client PUTs a representation of a type that is > impractical to > transform to the type of the existing resource? Doesn't that > effectively > cripple the resource, upsetting the expectations of other clients? For > example, suppose your resource is an SVG graphic--one of the most > information-rich image formats, and one that can be transformed to any > output format (known in this context as a representation, right?) you > like. So your server might make available JPEG, PNG, and EPS > representations of the image. Outbound, there's no problem. But now > suppose somebody wants to PUT a JPEG to the URI? If you allow the put, > then your information-rich SVG image is now degraded to a > dumb JPEG (I'm > talking about what happens in the real world, not the MIT Media Lab), > which not only contains less information than the old > resource, but may > be impractical to transform to some of the representation > types that are > supposed to be available. > > So do you disallow certain types of representations from being PUT or > POSTed? That certainly seems like a practical response to the problem. > But I would think that in a very large proportion of cases, you'd have > to prohibit any type but the original type of the resource--in which > case the distinction between resource and representation seems rather > academic. > > Or am I just confused? > > -- > Matt Gushee > Englewood, Colorado, USA > mgushee@... > http://www.havenrock.com/ > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Looking for a more powerful website? Try GeoCities for $8.95 > per month. > Register your domain name (http://your-name.com). More > storage! No ads! > http://geocities.yahoo.com/ps/info > http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> -----Original Message-----
> From: Chuck Hinson [mailto:cmhinson@...]
> Sent: Sunday, September 08, 2002 1:37 AM
> To: S. Mike Dierken
> Cc: rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
>
>
>
>
> S. Mike Dierken wrote:
>
> >
> >>Second, I don't think you can make any sort of
> generalization about what
> >>behavior or properties you might observe when two URIs name the same
> >>resource.
> >>
> >The point I'm making is that any claim that server.resource(uri1) ===
> >server.resource(uri2) is unverifiable and indistinguishable
> from bogus
> >claims like server.resource("www.slashdot.net") ===
> >server.resource("www.microsoft.com")
> >
> >If you can't demonstrate any runtime effects of claming two
> resources are
> >the same, then why make the claim?
> >
> In the general case I agree. For two arbitrary URIs, I don't believe
> there's any way to determine whether they identify the same
> resource or not.
>
> However, for a specific resource identified by two or more
> URIs, I would
> think that it might be possible to determine equivalence of
> URIs. The
> rules for making that determination would, however, only be valid for
> that specific resource and would probably require detailed
> knowledge of
> the resource for which URI equivalence was being tested.
>
> Hmm. Having said all that, I'm beginning to think the best
> you may be
> able to do is to determine non-equivalence.
>
> --Chuck
Determinations may be an individual thing. For instance, I may
have determined that for my own use, Stop & Shop is equivalent to
Shop Rite. However, other shoppers would not agree, nor would
the managements of these two different concerns.
If you're talking about some kind of authoritative determination
of equivalence among URI's, you have to appeal to the author, just
as you have to when you want to know the "real meaning" of a work
of art. The naming authority picks the meanings and the symbols.
When you interact with a resource, you are playing by the author's
rules; period.
SO:
If you repeatedly GET two URIs and get back identical bit streams,
that does not make for authoritative equivalence.
If you repeatedly GET two URIs and get back utterly different bit
streams, nor does that make for authoritative unequivalence.
The equivalence of two URIs should mean one and only one thing:
that they may be used interchangeably with the guarantee that substitution
of one for the other yields the exact same result as no substitution.
One should also ponder whether it would ever be wise to have two
URI that are equivalent by design.
Walden
I think the only "runtime effect" you should be claiming is that
they are interchangeable symbols for the same concept.
Walden
> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Sunday, September 08, 2002 1:22 AM
> To: rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
>
>
>
>
> >
> > Second, I don't think you can make any sort of
> generalization about what
> > behavior or properties you might observe when two URIs name the same
> > resource.
> The point I'm making is that any claim that server.resource(uri1) ===
> server.resource(uri2) is unverifiable and indistinguishable from bogus
> claims like server.resource("www.slashdot.net") ===
> server.resource("www.microsoft.com")
>
> If you can't demonstrate any runtime effects of claming two
> resources are
> the same, then why make the claim?
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Looking for a more powerful website? Try GeoCities for $8.95
> per month.
> Register your domain name (http://your-name.com). More
> storage! No ads!
> http://geocities.yahoo.com/ps/info
> http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
Chuck Hinson wrote: > Second, I don't think you can make any sort of generalization > about what > behavior or properties you might observe when two URIs name the same > resource. The characteristics of resources vary so greatly, that I > don't see that there would be any way to establish any kind > of generic > guarantee that would hold across all resources. I'm sure > that for set > of simple cases you might be able to guarantee some sort of byte-wise > equivalence, but I don't see that happening across all types > of resources. That's the way I see it, too. If not for the variable characteristics, guaranteed by the designed-in indirection between names and resource and between resources and their representations, you could make some claims about repeatable results with different URIs. But the variability is designed in, so you can't. Walden
> -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Saturday, September 07, 2002 3:01 PM > To: rest-discuss > Subject: Re: [rest-discuss] Resources - when two are one > > > > ----- Original Message ----- > From: "Seairth Jacobs" <seairth@...> > > > The point > > I was making was that it's perfectly legitimate to have a > single resource > > that returns different representations (where only the entity is > different). > > Therefore, you could not depend on content-type, > content-length, or the > > entity body itself (or any combination of them) to > confidently state > > whether two URIs point to the same resource or not. > > Right - so if we /did/ hold the accept-style headers constant > for requests > against the two URIs, what logical guarantees can be made? > If not for read-operations, what about write-operations? > Will there be a guarantee that a write operation of some kind > against uri1 > has a visible effect when inspecting uri2? The terminology is too direct for the architecture. You can't "write against a URI". You can transfer a representation to a resource behind a name. The great thing about resource modeling is the way it parallels people management! I can give you a hint, but I can't tell you what to do. But if the URI are authoritatively equivalent, then you are addressing the same resource no matter which URI you pick for a given request. If you only care about which resource you are addressing, then that should answer your question. Walden
> -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Friday, September 06, 2002 5:28 PM > To: Mathews, Walden; rest-discuss > Subject: Re: [rest-discuss] Resources - when two are one > > > > ----- Original Message ----- > From: "Mathews, Walden" <waldenm@...> > > > > > > > // are these true? > > > assert(server.resource(uri1).body == content2.body); > > > > According to that weird 'PUT' rule, it would have to be :-( > > I was assuming that the GET requests against the two > different URI (which > are the 'same' resource) have the exact same headers. > I wasn't relying on PUT's weird definition for the content to > be equivalent. > I'm just trying to figure out /why/ they would be different. > I think that except for the wierd 'PUT' rule, it's unsafe to make any concrete assertions about the values returned by a GET, so trying to set 'server.resource(uri1).body' equal to some pre-calculated value is risky. Mark's 'PUT' rule seems to override the otherwise absolute rule that resources are not their representations. Walden
On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > Mark Baker wrote, > > If the data being transferred cannot be described as a representation > > of some (perhaps unnamed) resource, then you're not doing it right. > > If resources can be nameless then we can't define "resource" primarily > in terms of URIs ... ie. we can't say, I think that's a good thing. > X is a resource if and only if X is identified by some URI > > I think that raises several interesting questions, > > * Unnamed resources do away with the "only if", but is this a step in > the direction of doing away with the "if" too ... ie. if we can have > unnamed resources, why can't we also have names with no resource? eg. > http://www.example.com/nothing-here-folks. > > * If having a URI isn't the criterion of resource-hood, then what is? Is > "resource" just an RFC 2396 compliant way of saying "thing"? Having identity. > * In the context of the discussions on the TAG list, is a URI-less > resource "part of the Web"? I thought about that for a bit, but decided that it wasn't really a very interesting question, because the cost is zero for assigning a URI to something that already has identity. The easy answer would be "no", but then you'd also have to ask yourself if maybe it did have a URI, but you just don't know it. Or, even if you don't know if it has a URI, just assign your own. > * How, if at all, do the kind of unamed resources that Mark's talking > about here relate to RDFs anonymous nodes? A bNode is a good example of a resource with identity, but without a (known) URI. Of course, they could trivially be given one, and why RDF doesn't do this, I have no idea. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark,
I thought that I had the issue of Google allowing an strictly
non-idempotent GET resolved in my mind, but a recent item on
the tag list pointed out this:
http://www.w3.org/2001/tag/doc/get7#obligations
I had been trying to argue - perhaps ineffectually - that the
Developer's Key effects the notion of what "safety" means.
The key is obtained through of an authorization relationship
established in a way similar to that described in the "TAG Finding:
URIs, Addressability, and the use of HTTP GET" document
referenced above.
I gave up on this line of reasoning because of your point
about proxy cache refereshing.
Do you think that your point effects the findings described
in that TAG document? Or do you not think that the way
Google is setup falls under this notion of "obligation"?
Thanks,
- Jeff
Yah, I'm following that too, and admit to being a bit puzzled by Dan's response and the finding. I think each request has to stand alone in its status as state-changing or not, for all the reasons I gave. I'll see how the discussion, if any, goes, before chiming in. Dan's a smart guy, so you better make sure your ducks are lined up before challenging him. 8-) MB On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote: > Mark, > > I thought that I had the issue of Google allowing an strictly > non-idempotent GET resolved in my mind, but a recent item on > the tag list pointed out this: > > http://www.w3.org/2001/tag/doc/get7#obligations > > I had been trying to argue - perhaps ineffectually - that the > Developer's Key effects the notion of what "safety" means. > The key is obtained through of an authorization relationship > established in a way similar to that described in the "TAG Finding: > URIs, Addressability, and the use of HTTP GET" document > referenced above. > > I gave up on this line of reasoning because of your point > about proxy cache refereshing. > > Do you think that your point effects the findings described > in that TAG document? Or do you not think that the way > Google is setup falls under this notion of "obligation"? > > Thanks, > > - Jeff > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote, > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > > * If having a URI isn't the criterion of resource-hood, then what > > is? Is "resource" just an RFC 2396 compliant way of saying "thing"? > > Having identity. I'm heartily sick of this "having identity" nonsense ;-) If tacking "having identity" onto the end of "thing" isn't completely redundant, then presumably it also makes sense to talk about things which *don't* have identity ... except of course that it doesn't, or at any rate it hasn't seemed attractive since Parmenides, Heraclitus and Hegel went out of fashion. At least starting with Frege, (Vx)(x = x) has been taken as a logical truth. IOW, *everything* has identity. Or to quote Quine, "No entity without identity". Seeing as RFC 2396 is coming up for revision I think now would be a good time to get rid of this silliness once and for all. Cheers, Miles
+1, heartily On Mon, 9 Sep 2002, Miles Sabin wrote: > Mark Baker wrote, > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > > > * If having a URI isn't the criterion of resource-hood, then what > > > is? Is "resource" just an RFC 2396 compliant way of saying "thing"? > > > > Having identity. > > I'm heartily sick of this "having identity" nonsense ;-) > > If tacking "having identity" onto the end of "thing" isn't completely > redundant, then presumably it also makes sense to talk about things > which *don't* have identity ... except of course that it doesn't, or at > any rate it hasn't seemed attractive since Parmenides, Heraclitus and > Hegel went out of fashion. At least starting with Frege, > > (Vx)(x = x) > > has been taken as a logical truth. IOW, *everything* has identity. Or to > quote Quine, "No entity without identity". > > Seeing as RFC 2396 is coming up for revision I think now would be a good > time to get rid of this silliness once and for all. > > Cheers, > > > Miles > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote: > Mark Baker wrote, > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > > > * If having a URI isn't the criterion of resource-hood, then what > > > is? Is "resource" just an RFC 2396 compliant way of saying "thing"? > > > > Having identity. > > I'm heartily sick of this "having identity" nonsense ;-) > > If tacking "having identity" onto the end of "thing" isn't completely > redundant, It is most definitely redundant. > Seeing as RFC 2396 is coming up for revision I think now would be a good > time to get rid of this silliness once and for all. I think it's quite clear when it says; "A resource can be anything that has identity." It doesn't say that resources have to have URIs, only that they have to have identity. But of course, anything with identity can have a URI. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote, > On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote: > > Mark Baker wrote, > > > > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > > > > * If having a URI isn't the criterion of resource-hood, then > > > > what is? Is "resource" just an RFC 2396 compliant way of saying > > > > "thing"? > > > > > > Having identity. > > > > I'm heartily sick of this "having identity" nonsense ;-) > > > > If tacking "having identity" onto the end of "thing" isn't > > completely redundant, > > It is most definitely redundant. Then what was the point of your response to my original question? > > Seeing as RFC 2396 is coming up for revision I think now would be a > > good time to get rid of this silliness once and for all. > > I think it's quite clear when it says; > > "A resource can be anything that has identity." > > It doesn't say that resources have to have URIs, I agree, tho' FWIW I'm sure that lots of people have read this as, A resource can be anything that has an identifier (ie. a URI). or, A resource can be anything that can be identified (ie. be picked out effectively). > only that they have to have identity. But of course, anything with > identity can have a URI. Sure, but what's the point of the the "with identity"? Any *thing*, period, can have an identifier: "with identity" is completely redundant as you've just agreed. The RFC 2396 text is misleading, because it suggests that the potential resources are a *proper* subset of the set of things, the proper subset which has identity as opposed to the subset which doesn't. That's close to gibberish IMO. Cheers, Miles
On Mon, Sep 09, 2002 at 06:11:58PM +0100, Miles Sabin wrote: > > It is most definitely redundant. > > Then what was the point of your response to my original question? 'cause you asked! 8-O > I agree, tho' FWIW I'm sure that lots of people have read this as, > > A resource can be anything that has an identifier (ie. a URI). > > or, > > A resource can be anything that can be identified (ie. be picked out > effectively). > > > only that they have to have identity. But of course, anything with > > identity can have a URI. > > Sure, but what's the point of the the "with identity"? Any *thing*, > period, can have an identifier: "with identity" is completely redundant > as you've just agreed. IMO, it's just clearer language. > The RFC 2396 text is misleading, because it suggests that the potential > resources are a *proper* subset of the set of things, the proper subset > which has identity as opposed to the subset which doesn't. That's close > to gibberish IMO. I wouldn't say that. It's just saying the same thing twice, since to only say it once would look odd, ala "a resource can be anything"(?!). Followups to uri@..., I suggest. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Mon, 9 Sep 2002, Mark Baker wrote: > On Mon, Sep 09, 2002 at 06:11:58PM +0100, Miles Sabin wrote: > > The RFC 2396 text is misleading, because it suggests that the potential > > resources are a *proper* subset of the set of things, the proper subset > > which has identity as opposed to the subset which doesn't. That's close > > to gibberish IMO. > > I wouldn't say that. It's just saying the same thing twice, since to > only say it once would look odd, ala "a resource can be anything"(?!). In RDF circles, the phrase 'a resource can be anything with identity' has often been taken to suggest that there might be some non-Resource things, which has led to much time wasted in trying to figure out what those are, how we identify them, etc etc. > Followups to uri@..., I suggest. (didn't seem worth doing that for my followup...) Dan -- mailto:danbri@... http://www.w3.org/People/DanBri/
Miles, When you say: > Sure, but what's the point of the the "with identity"? Any >*thing*, period, can have an identifier This is a meaningless statement. As soon as you've stated **that thing** you've identified it. What you might be asking is whether there are concepts and abstractions which cannot be universally and uniquely addressed. Most likely there are. For example, it makes sense for a specific person to have a URI but you can't really assign a URI to the concept of 'people'. (And if you do, it's guaranteed not everybody will agree that your URI addresses the 'people' resource since everybody has different notions of what the 'people' resource might constitute). Or can you assign URIs to emotions like 'happy' and 'jealous'? Again you can, but these URIs no longer have the same edge of universality as a URI that addresses yahoo's webpage or your mailbox. The point is resources aren't meant to be super-historical entities though there are many people who believe such super-historical entities exist. The word 'identity' implies a certain physicality and concreteness which jives well with REST because ultimately it comes down to executing methods against objects that exist on a network. Anyways I doubt anybody is really mislead by the "with identity" part unless they've already worked into a confusing, never-ending spiral of tautology and assumption while trying to decide what constitutes a resource. - itdp --- In rest-discuss@y..., Miles Sabin <miles@m...> wrote: > Mark Baker wrote, > > On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote: > > > Mark Baker wrote, > > > > > > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote: > > > > > * If having a URI isn't the criterion of resource-hood, then > > > > > what is? Is "resource" just an RFC 2396 compliant way of saying > > > > > "thing"? > > > > > > > > Having identity. > > > > > > I'm heartily sick of this "having identity" nonsense ;-) > > > > > > If tacking "having identity" onto the end of "thing" isn't > > > completely redundant, > > > > It is most definitely redundant. > > Then what was the point of your response to my original question? > > > > Seeing as RFC 2396 is coming up for revision I think now would be a > > > good time to get rid of this silliness once and for all. > > > > I think it's quite clear when it says; > > > > "A resource can be anything that has identity." > > > > It doesn't say that resources have to have URIs, > > I agree, tho' FWIW I'm sure that lots of people have read this as, > > A resource can be anything that has an identifier (ie. a URI). > > or, > > A resource can be anything that can be identified (ie. be picked out > effectively). > > > only that they have to have identity. But of course, anything with > > identity can have a URI. > > Sure, but what's the point of the the "with identity"? Any *thing*, > period, can have an identifier: "with identity" is completely redundant > as you've just agreed. > > The RFC 2396 text is misleading, because it suggests that the potential > resources are a *proper* subset of the set of things, the proper subset > which has identity as opposed to the subset which doesn't. That's close > to gibberish IMO. > > Cheers, > > > Miles
inthedarkplace wrote, > When you say: > > Sure, but what's the point of the the "with identity"? Any > >*thing*, period, can have an identifier > > This is a meaningless statement. As soon as you've stated **that > thing** you've identified it. You're confusing identity with identification. Someone will be the first person to call me on the phone tomorrow, I've no idea who (ie. I couldn't identify them), but whoever it will be is (and always was and will be) a satisifer of x = x. That's all identity is, nothing more, nothing less. Cheers, Miles
Miles Sabin wrote:
>inthedarkplace wrote,
>
>>When you say:
>>
>>>Sure, but what's the point of the the "with identity"? Any
>>>*thing*, period, can have an identifier
>>>
>>This is a meaningless statement. As soon as you've stated **that
>>thing** you've identified it.
>>
>
>You're confusing identity with identification. Someone will be the first
>person to call me on the phone tomorrow, I've no idea who (ie. I
>couldn't identify them), but whoever it will be is (and always was and
>will be) a satisifer of x = x. That's all identity is, nothing more,
>nothing less.
>
Hmm. Seems like different people are operating with different (pefrectly
valid) definitions for the word identity:
1. The collective aspect of the set of characteristics by which a
thing is definitively recognizable or known: ?If the broadcast
group is the financial guts of the company, the news division is
its public identity? (Bill Powell).
2. The set of behavioral or personal characteristics by which an
individual is recognizable as a member of a group.
3. The quality or condition of being the same as something else.
4. _/Mathematics./_
1. An equation that is satisfied by any number that replaces
the letter for which the equation is defined.
2. Identity element.
Personally, I think of 1. when seeing the word. It would appear that
others may be thinking more in terms of 4.
I'll not argue which should be used.
--Chuck
On Fri, Sep 06, 2002 at 01:31:53PM -0400, Mathews, Walden wrote: > > Hmm, what asymmetry? > > X says "see Y", but Y doesn't say "see X", so it's asymmetric. Ok. Also, I don't know why this just occurred to me, but clearly 301, in addition to meaning "equivalent" (I think), also means "and I'm going away" too. So it's most definitely not the same as daml:equivalentTo. Duh. I expect that equivalence would best be expressed as a response header rather than a response code. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Chuck Hinson wrote, > Hmm. Seems like different people are operating with different > (pefrectly valid) definitions for the word identity: > > 1. The collective aspect of the set of characteristics by which a > thing is definitively recognizable or known: ?If the broadcast > group is the financial guts of the company, the news division > is its public identity? (Bill Powell). > 2. The set of behavioral or personal characteristics by which an > individual is recognizable as a member of a group. Yup, this is one way of understanding the concept of identity. I guess you could call it the social or psychological sense. > 3. The quality or condition of being the same as something else. > 4. _/Mathematics./_ > 1. An equation that is satisfied by any number that replaces > the letter for which the equation is defined. > 2. Identity element. Call this the logical sense. These two are pretty much equivalent. An equation states that the expression on the LHS of an '=' picks out the same entity as the expression on the RHS. An identity element is an element which supports a particular class of equations, eg. 0 and 1 in x+0 = x and x*1 = x. FWIW, I think the logical sense is the only sensible option (if nothing else because in the social/psychological sense things can have multiple identities, which would be much too confusing to be useful here). Cheers, Miles
I wrote, <snip/> > I guess you could call it the social or psychological sense. <snip/> > Call this the logical sense. > > These two are pretty much equivalent. I didn't mean that quite the way it sounded ;-) What I _actually_ meant was that Chucks (3) and (4) are pretty much equivalent, *not* that the social and logical senses of identity are equivalent. Cheers, Miles
I thinked "equivalence" (as if that's really a meaningful word) can best be expressed by returning HTTP 303 SeeOther. This doesn't carry the connotations of expiration carried by the HTTP 301 Moved but it makes it clear what the client wants is to be found at another place. In reality, I believe all of the 3xx codes express equivalence because the client MUST follow the redirect--if the client fails to follow it then she can make no inferrences about the nature of the resource located at the original URI that caused the redirect. - itdp --- In rest-discuss@y..., Mark Baker <distobj@a...> wrote: > On Fri, Sep 06, 2002 at 01:31:53PM -0400, Mathews, Walden wrote: > > > Hmm, what asymmetry? > > > > X says "see Y", but Y doesn't say "see X", so it's asymmetric. > > Ok. > > Also, I don't know why this just occurred to me, but clearly 301, > in addition to meaning "equivalent" (I think), also means "and I'm > going away" too. So it's most definitely not the same as > daml:equivalentTo. Duh. > > I expect that equivalence would best be expressed as a response header > rather than a response code. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@a... > http://www.markbaker.ca http://www.idokorro.com
My current company is closing its doors today - the thundering silence in the sales dept (in which there were no actual employees... - a possible problem...) got too loud to ignore. Which means I am available for freelance contracting in the near term. So if anybody has a strong need for a crack Web architect (in the Seattle area), send me some mail and let's see what we can do. Mike
The recent discussion about unnamed resources and the implications of URIs and identity has been very interesting, but given that we are trying to resolve this in a REST context rather than a URI or RDF context, how about we stick to the following definition of resource: "A thing with meaning that has been assigned (or will be assigned?) a HTTP or HTTPS URI." A lot of the resources I've been thinking about are completely useless from a REST perspective; for example urn:isbn:123-456 might identify a resource, namely a book (in the abstract, not any particular copy). And yet, what good is it? Handy for RDF, but it's not HTTP addressable so there is not much to say about it in a REST context. Any thoughts? Michael
Stephen Cranefield wrote, > Miles Sabin <miles@...> wrote: > > At issue is the first sentence of the informal definition of > > resource in RFC 2396 1.1, > > > > A resource can be anything that has identity. > > > > "that has identity" is redundant because *everything* has identity > > in the only reasonably straightforward understanding of identity, > > ie. the logical truth in all but the most obscure formal systems > > that, > > > > (Vx) x = x > > A discussion of the philosophical notion of identity can be found in: > > Guarino, Nicola and Chris Welty. 2000. Identity, Unity, and > Individuality: Towards a formal toolkit for ontological analysis. In, > Horn, W. ed., Proceedings of ECAI-2000: The European Conference on > Artificial Intelligence. pp. 219-223. Berlin: IOS Press. August, 2000 > http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/LADSEB02-2000.pdf It's an interesting enough paper, but it's about unity, integrity and persistence of physical objects rather than identity. And that's a good thing, because their theory appears to be expressed in terms of first-order predicate calculus with identity initially, then later a simple first-order mereology and set theory, both of which presuppose identity: so if it really was supposed to be a theory of identity it'd be hopelessly circular. There are formal systems around which don't take identity as a primitive, but, like I said, they're somewhat obscure. That said, if the qualifier in RFC 2396 said something like, A resource can be anything that is integrated (for some value of "integrated") it would at least be adding something non-trivial. But I'd strongly advise against going down that route. Integrity is a slippery enough concept for physical objects (eg. it's extremely difficult to distinguish is-attached-to from is-part-of without running into all kinds of awkward edge cases) never mind the kind of electronic artifacts which are RFC 2396's primary (tho' maybe not exclusive) concern. There's also a brief discussion of the relation between stuffs and things, but that's irrelevant here: RFC 2396 talks about things from the outset, so individuation is already presupposed. Cheers, Miles
Michael Day wrote, > A lot of the resources I've been thinking about are completely > useless from a REST perspective; for example urn:isbn:123-456 might > identify a resource, namely a book (in the abstract, not any > particular copy). And yet, what good is it? Handy for RDF, but it's > not HTTP addressable so there is not much to say about it in a REST > context. There's a perfectly good URI resolution mechanism built on top of DNS, http://www.uri.net/ All that's missing is clients. Cheers, Miles
----- Original Message ----- From: "Michael Day" <mikeday@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, September 09, 2002 4:03 PM Subject: [rest-discuss] Resources > > > A lot of the resources I've been thinking about are completely useless > from a REST perspective; for example urn:isbn:123-456 might identify a > resource, namely a book (in the abstract, not any particular copy). In theory REST is not limited to HTTP - but in practice it usually is. > And > yet, what good is it? Handy for RDF, but it's not HTTP addressable so > there is not much to say about it in a REST context. Well... you technically /can/ de-reference non http URI via HTTP. GET urn:isbn:123-456 HTTP/1.1 Host: www.library-of-congress.gov
Miles Sabin <miles@...> wrote: > At issue is the first sentence of the informal definition of resource in > RFC 2396 1.1, > > A resource can be anything that has identity. > > "that has identity" is redundant because *everything* has identity in > the only reasonably straightforward understanding of identity, ie. the > logical truth in all but the most obscure formal systems that, > > (Vx) x = x A discussion of the philosophical notion of identity can be found in: Guarino, Nicola and Chris Welty. 2000. Identity, Unity, and Individuality: Towards a formal toolkit for ontological analysis. In, Horn, W. ed., Proceedings of ECAI-2000: The European Conference on Artificial Intelligence. pp. 219-223. Berlin: IOS Press. August, 2000 http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/LADSEB02-2000.pdf More pragmatically, a distinction between things with and things without identity should be quite familiar to Java programmers. You can distinguish between two instances of the String class that happen to have the same content, but you can't distinguish between two occurrences of the int value 7. Unless you consider that a literal is not a "thing", you have to allow for there to be things that don't have identity. I have argued that ontology modelling languages need to be able to declare which concepts have identity (and thus correspond to resources) and which represent structured "value types" without identity. See the following paper for a discussion of this in the context of ontology modelling using UML: Stephen Cranefield and Martin Purvis A UML profile and mapping for the generation of ontology-specific content languages Knowledge Engineering Review, 17(1) 2002 Pages 21-39 - Stephen
Al Gilman wrote, > At 07:17 PM 2002-09-09, Miles Sabin wrote: > >There's also a brief discussion of the relation between stuffs and > >things, but that's irrelevant here: RFC 2396 talks about things from > >the outset, so individuation is already presupposed. > > Yes, but erroneously so. This language in RFC 2396 was heuristic, > and the idea that individuation and a persistent referenceable > identity are intrinsic and universal in the Web, while central to the > thinking of some people, did not at that time nor at this one reflect > a globally valid interpretation of all the uses of URIs. I must admit I'm a bit taken aback by this response, however ... > And the distinction between things and stuffs is not at all > irrelevant to building a reasonable engineering foundation for > semantics for the Web. > > On the web we need to be able to refer to both stuffs and things. ... even tho' I don't have any particular metaphysical scruples when it comes to stuffs and substances, I'm afraid I simply don't buy this. Stuffs probably have a useful place somewhere, but I think not here. > We just discovered we needed to factor ACSS into perturbations of the > text-to-speech transform, which is analogous to font characteristic > manipulation, and sonicons that are used as punctuation for phrasal > elements. Analogous to quotation marks and other punctuation which > appear in the final stream as characters but this is because these > controls are of such antiquity that there are standard glyphic > characters for them. > > The moral here is that this points straight at a distinction between > text and fills, which are styled as stuffs, and list elements and > paragraphs and such, which are styled as things. > > If we comprehend this distinction at the outset, it would make the > whole job of characterizing styling a lot easier, and the result more > like natural language semantics. Why are fills stuffs? Sure, I fill my pies with apple (apple-stuff, not individual apples), but text is nothing like a pie. This is a physical analogy too far: surely text-fills are properties. That gets you a categorical distinction between text and fill ... but a different one. > In particular, for my dump on how regarding a search URL as a > reference to an identity is spurious, see > > http://lists.w3.org/Archives/Public/www-talk/2001NovDec/0058.html > > It is just much more direct to view a search URL as subclassing a > stuff and the server as returning references to things that exemplify > the stuff that the user's URL described. I have no idea what "subclassing a stuff" could possibly mean. I do understand types and subtypes tho'. And I've no idea how a thing "exemplifies" a stuff. A thing might exemplify (I'd prefer instantiate) a property, but it's _made_ of stuff ... and that's a different kind of relationship altogether. Are we talking at cross-purposes? Do you mean by stuff what I mean by property? > The data of the 'dark Web' is more practical to approach as stuff > typed by tuples of properties than as entified things. Or at least > that view matches application semantics better. > > http://lists.w3.org/Archives/Public/uri/2000Apr/thread.html#18 I can't see anything there which directly relates to this thread. Could you give me an example? I can certainly see a case for properties having first class status on the web, and I have no problem with properties counting as resources and having URIs. You'd need, in effect a second-order version of, A resource can be anything that has identity. but it's also true that in almost all second-order systems, (VX)(X = X) (ie. a second-order quantifier ranging over properties) is either an axiom or a theorem, so "that has identity" is _still_ redundant. I can't see any immediate role for stuffs tho', and the fact that there's no well worked out formal theory of stuffs doesn't help either. Cheers, Miles
> Well... you technically /can/ de-reference non http URI via HTTP. > > GET urn:isbn:123-456 HTTP/1.1 > Host: www.library-of-congress.gov My goodness. That never occurred to me :) In that case, what I was ineffectually grasping for was that while you can operate on a resource identified by a non-HTTP URI over HTTP, how will you know which server to go to? But I think the link to "Dynamic Delegation Discovery System" Miles Sabin just posted is probably an answer to that. So, no further questions :) Michael
all this discussion about state and identity has been really great. I've regularly been running off to my philosophy and maths books (and my dictionary half the time, too) to try to figure out what some of the more educated folks on this list are saying. Responding to some of the thoughts, I came up with a physical analogy: some of the physicists around the joint have come up with a way to teleport a laser beam across a room. They shine the beam into a detector, which translates the beam's 'entangled' photons into a radio signal, beam /that/ across the room, and use it to reconstruct the 'original' beam. Problem is, the original beam is destroyed in the process. I personally think this is a little bogus, because it isn't the original beam that comes out the other end, just a 'copy'. I thought this was great at describing the way you can't get a resource, only a representation. But it's WRONG. I thought of internet-connected fridges and air-conditioners GET www.my-airconditioner.net/bedroom/temperature HTTP/1.1 -> 24 degrees C POST www.my-airconditioner.net/bedroom/temperature HTTP/1.1 Content-type: text/xml <new-temperature>19</new-temperature> -> 200 OK (a bit more comfortable) Does that make my air conditioner a resource? I really couldn't tell. So I went to the source, and read 5.2.2.1-2 of Roy's dissertation over and over. And got confused. <quote>Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on</quote> That means it is possible that the air conditioner /could be/ a resource, by Roy's use of the word 'can', and inclusion of non- virtual objects. No? <quote>In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource</quote> What? That means my air conditioner isn't a resource, because I can't reference it through hypertext (HTTP). It does have a temperature function, however, that I can reference. Does the presence of the temperature function as part of the air conditioner make the air conditioner a resource? <quote>A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time More precisely, a resource R is a temporally varying membership function M<sub>R</sub>(t), which for time t maps to a set of entities, or values, which are equivalent. The values in the set may be resource representations and/or resource identifiers</quote> Ah, the resource is nothing I can ever get my hands on. The resource is the 'concept' that maps to reporting/changing temperature in my bedroom (and/or humidity, if my air conditioner was fancy enough). So the air conditioner itself, the physical, plastic reality of the thing, is not a resource. But by the act of mapping some of its functions as URIs, it becomes conceptually a resource, providing representations of its functions. Additionally, the functions of temperature and humidity, though subordinate to the air conditioner, because they are both concepts that map to one or more representations (change temperature, report temperature). So now I see it is /both/. It is the act of performing the mapping that makes a resource, in the context of REST. This makes my PUT above a representation, but not a resource, because I am not defining the mapping, I am using it. In a similar vein, just because I can identify my air conditioner, doesn't mean that it has identity /in the context of REST/. It is only the representations of its functions that it provides as URIs that have any identity /in the context of REST/. I keep repeating that about context, because I keep losing it in the discussion. However, at this moment, I am basking in extraordinary clarity. I can see a way ahead to do something practical. 1) Define a resource, conceptually 2) Define representations of that resource 3) Map one URI to each representation - two representations being equivalent at some time does not confuse the issue, they are representations I have chosen to present. 4) Give the URIs to others to play with :-) A note: Reading RFC 2068 Section 9.6 on PUT, I see a lot of stuff about PUTting resources, not representations. I think this means to me, in the light of what is above, that put /creates/ resources while, ie the conceptual mapping of some thing/function, and its associated representations. A PUT to http://www.myairconditioner.net/time may add a 'time' component (also a resource in its own right, in lieu of the fact that it provides one or more representations) that allows me to GET the time, or POST a time if it's wrong. This is seen to have a dual purpose: while the conceptual framework of the air conditioner (a resource) is /modified/ by the PUT, the conceptual framework of the time functions (also a resource) is /created/. Roy says I can't GET the time functions that I just PUT, though, because you can't GET resources. I can, however, GET a representation which seems to me like a fine compromise - the RFC says nothing about GETting back what you put, so that's OK (an indeed necessary by definition of a resource). In a Java/Tomcat context, this also means that I am PUTting Java class files the place I specify, creating a new 'context' in my server configuration file, and running the manager program to start that context up within the Tomcat container. I don't see any problem with this except in regards to security. Michael
----- Original Message ----- From: "Michael Day" <mikeday@...> > > Well... you technically /can/ de-reference non http URI via HTTP. > > > > GET urn:isbn:123-456 HTTP/1.1 > > Host: www.library-of-congress.gov > > My goodness. That never occurred to me :) > > In that case, what I was ineffectually grasping for was that while you can > operate on a resource identified by a non-HTTP URI over HTTP, how will you > know which server to go to? That and a million dollars of VC funding will get you my answer...
> That and a million dollars of VC funding will get you my answer... How enigmatic :) Can't say I like the implementation of DDDS, given that I don't particularly appreciate the implementation of DNS. Has the topic of DNS reimplemented over HTTP requests to known server IPs, acting as proxy caches to root HTTP domain name servers been covered on this list? It would be fun to reimplement DNS and cover generic URI/URN resolving at once. (Not that the world would rush to adopt it or anything; you'd spend your million dollars on marketing and bribery, not development...) Michael
Michael Day wrote: >The recent discussion about unnamed resources and the implications of URIs >and identity has been very interesting, but given that we are trying to >resolve this in a REST context rather than a URI or RDF context, how about >we stick to the following definition of resource: > >"A thing with meaning that has been assigned (or will be assigned?) a HTTP >or HTTPS URI." > Because there is no requirement that a resource be assigned a URI. REST is about (among other things) the transfer of representations of resources. Representations can be transferred in both requests and responses. A POST request transfers a representation to the server to be processed by the resource identified by the request. It's kind of hard to have a representation if there's no resource (however temporary or unreferencable that resource might be). Here's a snippet from Fielding's _Principled design of the modern Web Architecture_ : <snippet> Depending on the message control data, a given representation may indicate the current state of the requested resource, the desired state for the requested resource, or the value of some other resource, such as a representation of the input data within a client's query form, or a representation of some error condition for a response. </snippet> I read this to say that "the input data within a client's query form" is a resource. Note that it is not likely that the data within a client's query form has a URI. (I also note that the first three examples seem to line up pretty well with GET, PUT and POST.) > >A lot of the resources I've been thinking about are completely useless >from a REST perspective; for example urn:isbn:123-456 might identify a >resource, namely a book (in the abstract, not any particular copy). And >yet, what good is it? Handy for RDF, but it's not HTTP addressable so >there is not much to say about it in a REST context. > There's nothing preventing me from POSTing a representation of urn:isbn:123-456 to some other resource that is HTTP addressable. The fact that its not HTTP addressable does not prevent it from being used as a resource. I apoligize if I'm beating the proverbial dead horse (take my stick, please!), but... I dont understand this desire to pigeonhole resources as only (HTTP) addressable things. One way to look at it is that resources don't exist so they can have names - resources exist so that representations of them can be transferred to or from other resources. --Chuck
> > > That and a million dollars of VC funding will get you my answer... > > How enigmatic :) Can't say I like the implementation of DDDS, given that I > don't particularly appreciate the implementation of DNS. Has the topic of > DNS reimplemented over HTTP requests to known server IPs, acting as proxy > caches to root HTTP domain name servers been covered on this list? It > would be fun to reimplement DNS and cover generic URI/URN resolving at > once. (Not that the world would rush to adopt it or anything; you'd spend > your million dollars on marketing and bribery, not development...) > True. True.
"resources exist so that representations of them can be transferred to or from other resources." That's a nice definition to keep in mind. Rather circular, but it seems to make sense :) Michael
We say that it is possible for a URI to not identify anything. However, I
am beginning to wonder if that's true. Suppose you were to take the English
language. Now, suppose I were to present to you the following:
twipperty
You say: "what's that?" I answer absolutely nothing. It has not meaning
(identifies nothing) as a result it isn't even a word, even though it looks
like one.
And this brings us to URIs. Just because you can put together a random
string of characters that looks like a URI does not, in fact, make it a URI.
And this is where I think we make our mistake....
If you were to see:
http://www.not-an-actual-website.com/some-random-path/twipperty
Is it a URI? Well, it looks like one (and "twipperty" looked like a word).
But until you can resolve it to some sort of meaning (identify something
with it), then it ain't a URI, no matter how much it looks like one!
---
Seairth Jacobs
seairth@...
I have been learning REST for some time now, and I feel that I have even more to learn. However, I keep coming to one conclusion in partcicular. This conclusion may not be very popular within this list, esp. since this list is generally pro-HTTP. But I like sticking my neck out, so here goes... The most common "proof" that REST works is HTTP. This makes sense considering that Fielding had been looking at HTTP when he did his work on REST. Also, considering that he helped author HTTP 1.1, this would lend even more credence to the statement that "The Web proves that REST works." Because of this, I have focused on learning REST as it applies to HTTP, though I had initially started by trying to learn REST independent of any application or protocol. In this learning process, I continually run into questions that do not seem to have clear, understandable answers. Considering that HTTP was considered RESTful, I thought this to be an odd thing. I would expect a RESTful protocol to clearly show how the REST architecture works. Then it hit me. I have let myself fall victem to marketing hype! And here is why I say that. I took it as gospel that HTTP === REST. I believed in the statement that "The Web proves that REST works." But I kept coming up with these "issues" I couldn't reconcile. So I sat down this weekend and instead of considering *what* wasn't reconciling, I considered *why* it wasn't reconciling. And I think I finally hit upon the reason. HTTP is not as RESTful as we would all like to believe. For years, people have been building web sites, mostly static pages. Did these people use HTTP PUT to update the server? Absolutely not! They used FTP. They used the access to their HTTP server through their local network. To some extent, they even used HTML Form-base file uploads via POST. But PUT? Hardly. The exact same could be said for DELETE. So, then we are left with POST and GET. How do their "typical" usage play out in the REST arena? Well, as has been pointed out by many, many threads on this very list, POST is often missused. I'd even be willing to bet that the vast majority of uses for POST are wrong in the eyes of REST. This leaves us with GET. GET is probably the one HTTP verb that generally conforms to the REST architecture. This is a good thing, considering that probably 90% or more of the web traffic uses GET. Sure, there *are* more and more implemenations of REST showing up, but in ratio to the existing "non-REST" implementations already on the web, this is probably quite a small number. So, how can people say that "The Web proves that REST works"? It's because one (GET) of the four major HTTP verbs provides for 90% or more of the proof. POST provides the most of the remaining percentage, and even though many consider its usage to often be non-RESTful, we'll conveniently ignore that. And, as usual, PUT and DELETE are pretty much non-existant (in terms of actual usage). In the end, this does not make the Web a killer app that proves REST works. If anything, it proves that certain aspects of REST work (i.e. GET). Beyond that, I am beginning to feel that HTTP has as much to prove as a truly RESTful tool as does just about any other web-based technology out there right now.... --- Seairth Jacobs seairth@...
On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth Jacobs wrote: > So, how can people say that "The Web proves that REST works"? to be honest, i have always been a bit dubious about that statement as well, given that (among many other things) so many websites use URIs of the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of simply "/articles/123". i don't think the Web (or more precisely the ubiquity of HTTP) proves that REST works. much of the time HTTP is being used as something else, which i am thus far incapable of labelling. that said, i am a firm believer that REST does work, but more because it 'feels right' than because the Web (or anything else) /proves/ that it works.
> -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Tuesday, September 10, 2002 1:15 AM > To: rest-discuss > Subject: [rest-discuss] REST and the Web > > > I have been learning REST for some time now, and I feel that > I have even > more to learn. However, I keep coming to one conclusion in > partcicular. > This conclusion may not be very popular within this list, > esp. since this > list is generally pro-HTTP. But I like sticking my neck out, so here > goes... > > > The most common "proof" that REST works is HTTP. This makes sense > considering that Fielding had been looking at HTTP when he > did his work on > REST. Also, considering that he helped author HTTP 1.1, this > would lend > even more credence to the statement that "The Web proves that > REST works." According to Fielding, REST provided valuable guidance in some of the more recent design of web protocol, and in that sense he's declaring it to "work", but we mostly mean something else when we talk about REST "working". > > Because of this, I have focused on learning REST as it > applies to HTTP, > though I had initially started by trying to learn REST > independent of any > application or protocol. In this learning process, I > continually run into > questions that do not seem to have clear, understandable answers. > Considering that HTTP was considered RESTful, I thought this > to be an odd > thing. I would expect a RESTful protocol to clearly show how the REST > architecture works. The protocol itself can support REST architected applications, but it can't control the way it is used, just like you can't prevent houses from being used as targets on Halloween. So while HTTP may be considered "RESTful", the same doesn't go for all applications of HTTP. But sans applications (which admittedly makes architecture study that much harder) you can see HTTP as an example of a way to bring REST style to life. You can see that it has a limited number of very generic methods, that it has uniform identifiers built right in, that it separates client from server in each task it undertakes, that it has directives for caching, and so on. One of the things HTTP doesn't do well is constrain applications from holding conversational state on the server. Another thing it really can't constrain is whether your application can directly address the resources in its domain or whether you tunnel all requests through a single identifier. Instead of thinking of HTTP as a proof of REST, it might be more productive to think of REST of a guideline for using HTTP for maximum benefit. > > Then it hit me. I have let myself fall victem to marketing > hype! In the application design arena, this is inevitable, even when you go in with your eyes wide open. The fact is that we're only playing a game here, applying heuristics to find the best patterns to spend time with. There's no way to do this without employing faith, because otherwise you'd never make any sweeping decisions. So unlax. REST isn't perfect; neither is HTTP. Still, the discovery of simple forms that do powerful work is an exciting discovery. I had a ball piecing together the puzzle of how to map a set of entitlements function calls onto an entitlements resource model, and I'm still having fun refining that model and selling the results. I can tell it's good because the API keeps shrinking without losing function. > And here > is why I say that. I took it as gospel that HTTP === REST. > I believed in > the statement that "The Web proves that REST works." But I > kept coming up > with these "issues" I couldn't reconcile. So I sat down this > weekend and > instead of considering *what* wasn't reconciling, I > considered *why* it > wasn't reconciling. And I think I finally hit upon the reason. > > HTTP is not as RESTful as we would all like to believe. For > years, people > have been building web sites, mostly static pages. Did these > people use > HTTP PUT to update the server? Absolutely not! They used > FTP. They used > the access to their HTTP server through their local network. To some > extent, they even used HTML Form-base file uploads via POST. But PUT? > Hardly. The exact same could be said for DELETE. REST merely says that connectors are constrained to a limited set of very generic methods. HTTP supplies such a set of methods, plus some rules for when they apply. I'm not sure if REST says that there has to be a resource modification method that's idempotent, a retrieval method that's safe, etc. I'm pretty sure REST says nothing about there having to be a deletion method. So, the fact that you can design systems around GET and POST doesn't disprove REST; nor does it disprove HTTP. The argument in favor of using what's already in HTTP instead of reinventing is different from the more general argument for styling applications with REST, IMO. The distinction is there if you wish to observe it, but culturally the two seem to blend in the name of common sense. > In the end, this does not make the Web a killer app that > proves REST works. > If anything, it proves that certain aspects of REST work > (i.e. GET). Beyond > that, I am beginning to feel that HTTP has as much to prove as a truly > RESTful tool as does just about any other web-based > technology out there > right now.... That's a fair assessment, and it corresponds with my experience in trying to go beyond what Jackson calls the "static information frame"-type application using HTTP. Making intricate behaviors occur through a very generic interface is a real challenge. But, the fact that I can use the web to research the things I do gives credibility to the fact that at least the GET side is "killer". Walden
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > > to be honest, i have always been a bit dubious about that statement as > well, given that (among many other things) so many websites use URIs of > the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of > simply "/articles/123". Both are equivalent from the "URI is an identifier" point of view. The path-based URI has certain nice properties, as does the query-based URI. REST and RESTful HTTP designs do not necessarily prefer one over the other.
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > Instead of thinking of HTTP as a proof of REST, it might be more > productive to think of REST of a guideline for using HTTP for > maximum benefit. Well put. > Still, the discovery of simple forms that do powerful > work is an exciting discovery. I had a ball piecing together > the puzzle of how to map a set of entitlements function calls > onto an entitlements resource model, and I'm still having fun > refining that model and selling the results. I can tell it's > good because the API keeps shrinking without losing function. Cool!
Seairth Jacobs wrote: >... > HTTP is not as RESTful as we would all like to believe. For years, people > have been building web sites, mostly static pages. Did these people use > HTTP PUT to update the server? Absolutely not! They used FTP. They used > the access to their HTTP server through their local network. To some > extent, they even used HTML Form-base file uploads via POST. But PUT? > Hardly. The exact same could be said for DELETE. I don't think that PUT and DELETE are core to REST. They are just logical extensions of HTTP's two core methods of GET and POST. Fielding's interface doesn't say WHAT generic interface you should use, just that you should use one. > So, then we are left with POST and GET. How do their "typical" usage play > out in the REST arena? Well, as has been pointed out by many, many threads > on this very list, POST is often missused. I'd even be willing to bet that > the vast majority of uses for POST are wrong in the eyes of REST. It might be accurate to say that most uses of POST are wrong in one way or the other. But how many object oriented programs do not 100% conform to that paradigm? The important thing is that the *best* web-based services tend to use REST principles quite a bit, and the more they do the better they tend to get -- at least from the client's perspective. The more they uniquely identify things with URIs, the more the client can bookmark. The more they use GET for GET and POST for POST the fewer issues they will have with spiders that trigger actions or things that should be bookmarkable but aren't. The less they use cookies, the easier it is for customers to move between devices. etc. >... > So, how can people say that "The Web proves that REST works"? It's because > one (GET) of the four major HTTP verbs provides for 90% or more of the > proof. POST provides the most of the remaining percentage, and even though > many consider its usage to often be non-RESTful, we'll conveniently ignore > that. And, as usual, PUT and DELETE are pretty much non-existant (in terms REST isn't GET+PUT+POST+DELETE. It's identification of resources (name a website without a URL ;) ), manipulation of resources through representations (e.g. form-encoded), self-descriptive messages and hypermedia as the engine of application state, universal interfaces, ... You can do these things with only two methods. Having four instead increases interoperability and I would have no compunction about going beyond four (e.g. adding WATCH or NOTIFY or maybe GETCHILDREN). > In the end, this does not make the Web a killer app that proves REST works. > If anything, it proves that certain aspects of REST work (i.e. GET). Beyond > that, I am beginning to feel that HTTP has as much to prove as a truly > RESTful tool as does just about any other web-based technology out there > right now.... HTTP explicitly supports the things I describe above. Other protocols don't. That doesn't mean that HTTP is perfect but it is the starting point. BTW, if you look at BEEP, the issues they punt on are exactly the issues that HTTP addresses. Paul Prescod
Michael Day wrote: > How enigmatic :) Can't say I like the implementation of DDDS, given that I > don't particularly appreciate the implementation of DNS. Has the topic of > DNS reimplemented over HTTP requests to known server IPs, acting as proxy > caches to root HTTP domain name servers been covered on this list? It > would be fun to reimplement DNS and cover generic URI/URN resolving at > once. (Not that the world would rush to adopt it or anything; you'd spend > your million dollars on marketing and bribery, not development...) I think that if you want DNS' performance you'd at least need to move HTTP to a UDP foundation before moving DNS to an HTTP foundation. TCP connections are kind of expensive and DNS runs all over the Internet trying to resolve each address. Paul Prescod
> I think that if you want DNS' performance you'd at least need to move > HTTP to a UDP foundation before moving DNS to an HTTP foundation. TCP > connections are kind of expensive and DNS runs all over the Internet > trying to resolve each address. How about the variant of TCP whose name I sadly forget which piggybacks the first data on the connect packets? I seem to recall that reduced the overhead of TCP compared to UDP, particularly for small requests like DNS lookups, but as I can't remember the name I'm having trouble finding it. Michael
> How about the variant of TCP whose name I sadly forget which piggybacks > the first data on the connect packets? I seem to recall that reduced the > overhead of TCP compared to UDP, particularly for small requests like DNS > lookups, but as I can't remember the name I'm having trouble finding it. Ah, it was T/TCP, RFC 1644. Michael
Michael Day wrote: >>How about the variant of TCP whose name I sadly forget which piggybacks >>the first data on the connect packets? I seem to recall that reduced the >>overhead of TCP compared to UDP, particularly for small requests like DNS >>lookups, but as I can't remember the name I'm having trouble finding it. > > > Ah, it was T/TCP, RFC 1644. Looks interesting. Is it implemented anywhere? Paul Prescod
> > Ah, it was T/TCP, RFC 1644. > > Looks interesting. Is it implemented anywhere? I've seen a prototype implementation for Linux, but I don't know if the protocol is in widespread use anywhere. Theoretically it should be easy to deploy, as you can always fallback to regular TCP operation if the host doesn't understand the T/TCP request and refuses the connection. Michael
Today, Apple released iCal, a calendaring product that uses the IETF format of the same name, today. It claims to require a WEBDAV-enabled Web server to publish to. Aaron and I did some testing of it tonight, and discovered that it's perfectly possible to use with a PUT/DELETE-enabled Web server; it only seems to use MKCOL from WebDAV to make sure that the containing resource is present. Question: has anyone done a writeup of WebDAV to see what the additional functionality over REST is, and how often it's required? To my knowledge, the only notable bits are MKCOL and properties (which IIRC have been discussed here as capable of being modeled in a more RESTful manner). Anything else? P.S. iCal supports Digest Auth; yippee! -- Mark Nottingham
I'm sure this has come up before, but it's bugging me, so: Many protocols such as XML Namespaces and RDF compare URIs syntactically. Consider the following six URIs: 1. http://www.foo.com/resource 2. http://www.foo.com/resource/ 3. http://www.foo.com/resource# 4. http://www.foo.com/resource? 5. http://www.foo.com/resource?# 6. http://www.foo.com/resource/?# Syntactically they are all different, and yet different in different ways. 1 and 2 have been giving me trouble as I originally used 1 for many resources that were actually directories underneath, and Apache insisted on redirecting to 2. So I use 2 now. 3 seems to come up very often when using RDF, and appears to be a namespace URI hack to generate URIs with fragment IDs from namespace qualified names. I haven't seen examples of the rest. Can anyone comment on the differences between these URIs? Are there any rough guidelines as to which style should be used in different circumstances? Michael
On Wednesday, Sep 11, 2002, at 10:31 Europe/Dublin, Michael Day wrote: > 1. http://www.foo.com/resource > 2. http://www.foo.com/resource/ > > Syntactically they are all different, and yet different in different > ways. > 1 and 2 have been giving me trouble as I originally used 1 for many > resources that were actually directories underneath, and Apache > insisted > on redirecting to 2. So I use 2 now. i have thought for a while now that this behaviour in apache is incorrect. URIs without trailing slashes should be just accepted. i reckon the trailing slash is just a side-effect of apache's filesystem-bias. (along with index.html, which is meaningless IMHO). what's the best place to 'change' this behavior? mod_dir? anyway, to answer your question (partially): i avoid the trailing slash in URIs whenever i can.
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > i reckon the trailing slash is just a side-effect of apache's > filesystem-bias. (along with index.html, which is meaningless IMHO). Oh, I don't know about meaningless for index.html. That's the 'magic name' of the 'list all children' or 'list all outbound links' for a collection based resource. If you squint a little bit... Doing just a file-system list isn't flexible enough - as index.html can hold links to arbitrary (non-relative) resources.
Mark Nottingham wrote: > Today, Apple released iCal, a calendaring product that uses the IETF > format of the same name, today. It claims to require a WEBDAV-enabled Web > server to publish to. > > Aaron and I did some testing of it tonight, and discovered that it's > perfectly possible to use with a PUT/DELETE-enabled Web server; it only > seems to use MKCOL from WebDAV to make sure that the containing resource > is present. > > Question: has anyone done a writeup of WebDAV to see what the additional > functionality over REST is, and how often it's required? Just to clarify... I'd phrase that: "has anyone done a writeup of WebDAV to see how closely it adheres to the REST architectural style?" The reason I quibble is because some people have the sense that REST is GET/PUT/POST/DELETE and I'm probably as much at fault for that as anyone. But I don't think Fielding's thesis mentions any particular methods at all. WebDAV's "extra" methods are not against REST merely because they are extra methods. Perhaps if they violate some of the other constraints of REST...(e.g. if they were specific, or stateful, ...) I'm not convinced that WebDAV properties are necessarily "against" REST but it may be that could have been done in a manner that fit Web infrastructure better. Someone definately needs to write a paper on that one day. You probably know this Mark but I just wanted to make the point. > P.S. iCal supports Digest Auth; yippee! Alright! Did you reverse engineer the iCal protocol and file formats enough to determine to what extent it is RESTful? Does it use URIs in a sane way etc? Paul Prescod
> I'd phrase that: "has anyone done a writeup of WebDAV to see how closely > it adheres to the REST architectural style?" I was interested in how much of the functionality of WebDAV actually comes from vanilla HTTP (PUT, DELETE, and so forth); i.e., "What does compiling in WebDAV give me over mod_put?" But this would be a good thing as well... > Did you reverse engineer the iCal protocol and file formats enough to > determine to what extent it is RESTful? Does it use URIs in a sane way etc? Just some live testing whilst watching the logs; I may set up a proxy to examine the headers as they fly by as well. Its use of URIs seems quite sensible (i.e., having a calendar or group of events identifiable as a URI), except for the one problem with the new scheme, as noted to the URI list.
Hi, > Just some live testing whilst watching the logs; I may set up a proxy to > examine the headers as they fly by as well. Its use of URIs seems quite > sensible (i.e., having a calendar or group of events identifiable as a > URI), except for the one problem with the new scheme, as noted to the URI > list. is this scheme documented somewhere, or did you just see it in the traces? Where does it appear? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
It wasn't in the traces; the request-line was relative, not absolute, and I haven't had a chance to hook up a proxy capable of recording header traces yet. iCal has a function where you can send someone a notification of your calendar through e-mail. This e-mail contains a URI with the webcal scheme. Also, see the 'subscribe' links at: http://www.apple.com/ical/library/ ----- Original Message ----- From: "Julian Reschke" <julian.reschke@...> To: "Mark Nottingham" <mnot@...>; <rest-discuss@yahoogroups.com>; "Paul Prescod" <paul@...> Cc: <me@...> Sent: Thursday, September 12, 2002 12:40 AM Subject: RE: [rest-discuss] FYI: iCal > Hi, > > > Just some live testing whilst watching the logs; I may set up a proxy to > > examine the headers as they fly by as well. Its use of URIs seems quite > > sensible (i.e., having a calendar or group of events identifiable as a > > URI), except for the one problem with the new scheme, as noted to the URI > > list. > > is this scheme documented somewhere, or did you just see it in the traces? > Where does it appear? > > Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > >
Michael Day wrote: > I'm sure this has come up before, but it's bugging me, so: > > Many protocols such as XML Namespaces and RDF compare URIs syntactically. > Consider the following six URIs: > > 1. http://www.foo.com/resource > 2. http://www.foo.com/resource/ > 3. http://www.foo.com/resource# > 4. http://www.foo.com/resource? > 5. http://www.foo.com/resource?# > 6. http://www.foo.com/resource/?# > > Syntactically they are all different, and yet different in different ways. > 1 and 2 have been giving me trouble as I originally used 1 for many > resources that were actually directories underneath, and Apache insisted > on redirecting to 2. So I use 2 now. 3 seems to come up very often when > using RDF, and appears to be a namespace URI hack to generate URIs with > fragment IDs from namespace qualified names. I haven't seen examples of > the rest. I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate between 1. and 3. IIRC, Basically Tim's position is that "1" identifies the HTTP resource (the W3C's web page) and "3" identifies the "logical concept" (the W3C). I believe that Fielding thinks that 1. identifies the logical concept and it is up to the identifying context to be explicit whether it is talking about a resource or a representation. I tend to agree with Vincent that there is no reason in Web architecture to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource is a container. But if it isn't then it is especially annoying that it is difficult to leave off the slash in most web servers. Paul Prescod
firepipe_au wrote: > ... > > <quote>Any information that can be named can be a resource: a > document or image, a temporal service (e.g. "today's weather in Los > Angeles"), a collection of other resources, a non-virtual object > (e.g. a person), and so on</quote> > > That means it is possible that the air conditioner /could be/ a > resource, by Roy's use of the word 'can', and inclusion of non- > virtual objects. No? > > <quote>In other words, any concept that might be the target of an > author's hypertext reference must fit within the definition of a > resource</quote> > > What? That means my air conditioner isn't a resource, because I > can't reference it through hypertext (HTTP). If the air conditioner has a URI then you can reference it through hypertext. When you dereference you don't get back the air conditioner, though, you get back a representation of it (perhaps a webcam snapshot, perhaps a static HTML document, perhaps an RDF instance) > ... > Ah, the resource is nothing I can ever get my hands on. The resource > is the 'concept' that maps to reporting/changing temperature in my > bedroom (and/or humidity, if my air conditioner was fancy enough). > So the air conditioner itself, the physical, plastic reality of the > thing, is not a resource. But by the act of mapping some of its > functions as URIs, it becomes conceptually a resource, providing > representations of its functions. When you give URIs to the functions, the functions become Web resources. But if you want the air conditioner to be a Web resource then it needs its own URI. > 1) Define a resource, conceptually > 2) Define representations of that resource > 3) Map one URI to each representation - two representations being > equivalent at some time does not confuse the issue, they are > representations I have chosen to present. > 4) Give the URIs to others to play with :-) Note that there is nothing wrong with having multiple representations at one URI. That's what HTTP content negotiation allows. Then your air conditioner can report itself in XML to XML clients and JPEG to graphically oriented clients. > A note: > Reading RFC 2068 Section 9.6 on PUT, I see a lot of stuff about > PUTting resources, not representations. The HTTP spec uses the term "entity" not representation for historical reasons. And in fact it does talk about PUTting entities, not resources. > Roy says I can't GET the time functions that I just PUT, though, > because you can't GET resources. I can, however, GET a > representation which seems to me like a fine compromise - the RFC > says nothing about GETting back what you put, so that's OK (an indeed > necessary by definition of a resource). I disagree. I do think that GET and PUT are meant to be symmetrical. Resources can not be GOT nor PUT. Only representations/entities. Paul Prescod
> From: Paul Prescod [mailto:paul@...] > Sent: Thursday, September 12, 2002 1:14 PM > To: Michael Day > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] URI syntax > ... > > > > Many protocols such as XML Namespaces and RDF compare URIs > syntactically. > > Consider the following six URIs: > > > > 1. http://www.foo.com/resource > > 2. http://www.foo.com/resource/ > > 3. http://www.foo.com/resource# > > 4. http://www.foo.com/resource? > > 5. http://www.foo.com/resource?# > > 6. http://www.foo.com/resource/?# > > > > Syntactically they are all different, and yet different in > different ways. > > 1 and 2 have been giving me trouble as I originally used 1 for many > > resources that were actually directories underneath, and Apache insisted > > on redirecting to 2. So I use 2 now. 3 seems to come up very often when > > using RDF, and appears to be a namespace URI hack to generate URIs with > > fragment IDs from namespace qualified names. I haven't seen examples of > > the rest. > > I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate > between 1. and 3. IIRC, Basically Tim's position is that "1" identifies > the HTTP resource (the W3C's web page) and "3" identifies the "logical > concept" (the W3C). I believe that Fielding thinks that 1. identifies > the logical concept and it is up to the identifying context to be > explicit whether it is talking about a resource or a representation. > > I tend to agree with Vincent that there is no reason in Web architecture > to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource > is a container. But if it isn't then it is especially annoying that it > is difficult to leave off the slash in most web servers. I think the issue here is that 1 and 2 may identify *different* resources. WebDAV says that collections should be identified with trailing "/", but that a server should basically treat the same URI without slash as identifying the same resource. But that's just WebDAV :-) -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
I think this is an odd discussion. REST doesn't "work" or "not work". The Web works, and REST describes the architectural constraints that were in part responsible for why it works. Obviously there are many other reasons for why the Web was successful, only some of them technical. MB On Tue, Sep 10, 2002 at 02:41:19PM +0100, Vincent D Murphy wrote: > On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth Jacobs wrote: > > So, how can people say that "The Web proves that REST works"? > > to be honest, i have always been a bit dubious about that statement as > well, given that (among many other things) so many websites use URIs of > the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of > simply "/articles/123". > > i don't think the Web (or more precisely the ubiquity of HTTP) proves > that REST works. much of the time HTTP is being used as something > else, which i am thus far incapable of labelling. > > that said, i am a firm believer that REST does work, but more because > it 'feels right' than because the Web (or anything else) /proves/ that > it works. > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
"In part responsible" is the key phrase. If you build a system strictly in the REST style, you'll be doing something a little different from the normative web out there. Another way of saying it: if REST was just a description of existing web stuff, it wouldn't be useful in guiding the process of evolving the web. So REST is some kind of logical extension of the existing web, incorporating the ideals formed from lessons learned with the web. If REST were purely descriptive, this would be an odd discussion. But we are attempting to use it prescriptively. I interpret questions like "does REST work?" to mean "does REST work prescriptively?". I think everyone else does too. Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Thursday, September 12, 2002 2:06 PM > To: Vincent D Murphy > Cc: Seairth Jacobs; rest-discuss > Subject: Re: [rest-discuss] REST and the Web > > > I think this is an odd discussion. REST doesn't "work" or "not work". > The Web works, and REST describes the architectural constraints that > were in part responsible for why it works. Obviously there are > many other reasons for why the Web was successful, only some of them > technical. > > MB > > On Tue, Sep 10, 2002 at 02:41:19PM +0100, Vincent D Murphy wrote: > > On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth > Jacobs wrote: > > > So, how can people say that "The Web proves that REST works"? > > > > to be honest, i have always been a bit dubious about that > statement as > > well, given that (among many other things) so many websites > use URIs of > > the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" > instead of > > simply "/articles/123". > > > > i don't think the Web (or more precisely the ubiquity of > HTTP) proves > > that REST works. much of the time HTTP is being used as something > > else, which i am thus far incapable of labelling. > > > > that said, i am a firm believer that REST does work, but > more because > > it 'feels right' than because the Web (or anything else) > /proves/ that > > it works. > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thu, Sep 12, 2002 at 02:46:16PM -0400, Mathews, Walden wrote: > "In part responsible" is the key phrase. Well, by that I meant the non-technical reasons; the internet was becoming more accessible before the Web, it was easy and cheap to author (good tools), it was well lead by a handful of super smart people, etc.. > If you build a system strictly > in the REST style, you'll be doing something a little different from the > normative web out there. I don't think so. > Another way of saying it: if REST was just a > description of existing web stuff, it wouldn't be useful in guiding the > process of evolving the web. So REST is some kind of logical extension > of the existing web, incorporating the ideals formed from lessons learned > with the web. > > If REST were purely descriptive, this would be an odd discussion. But we > are attempting to use it prescriptively. I interpret questions like "does > REST work?" to mean "does REST work prescriptively?". I think everyone > else does too. I don't attempt to use it prescriptively, though I know it probably looks this way. When that happens, it's because there is some desirable set of properties that I'm trying to achieve, and I know that they can only reasonably be had with some subset of REST's constraints. REST is most defintely *descriptive*. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Thursday, September 12, 2002 3:12 PM > To: Mathews, Walden > Cc: 'Mark Baker'; Vincent D Murphy; Seairth Jacobs; rest-discuss > Subject: Re: [rest-discuss] REST and the Web > > > On Thu, Sep 12, 2002 at 02:46:16PM -0400, Mathews, Walden wrote: > > "In part responsible" is the key phrase. > > Well, by that I meant the non-technical reasons; the internet was > becoming more accessible before the Web, it was easy and cheap to > author (good tools), it was well lead by a handful of super smart > people, etc.. > > > If you build a system strictly > > in the REST style, you'll be doing something a little > different from the > > normative web out there. > > I don't think so. Okay, have a Cookie! :-0 > > > Another way of saying it: if REST was just a > > description of existing web stuff, it wouldn't be useful in > guiding the > > process of evolving the web. So REST is some kind of > logical extension > > of the existing web, incorporating the ideals formed from > lessons learned > > with the web. > > > > If REST were purely descriptive, this would be an odd > discussion. But we > > are attempting to use it prescriptively. I interpret > questions like "does > > REST work?" to mean "does REST work prescriptively?". I > think everyone > > else does too. > > I don't attempt to use it prescriptively, though I know it probably > looks this way. When that happens, it's because there is > some desirable > set of properties that I'm trying to achieve, and I know that they can > only reasonably be had with some subset of REST's constraints. That's a terribly subtle distinction. There's no question that REST (via the Fielding paper) doesn't tell you what steps to follow. In that sense it's not prescriptive. But when you talk about "RESTifying" some service, you're almost certainly following some hidden process that could easily (?) be documented. InTheDarkPlace documented such a process here recently. But we'll agree in advance that that process is not REST. Whether you call that prescriptive or descriptive -- I don't care what the correct word is -- people are using this as a design guide, applying it to all sorts of things that didn't start out as hypertext, so in that context "does it work?" seems quite reasonable (to me). > > REST is most defintely *descriptive*. Technically, Mark, REST was described in a thesis, but that doesn't make REST descriptive. It makes the thesis descriptive. The thesis is careful to draw this very distinction, so I thought it appropriate to drag it out. Walden
Mark Baker wrote: >... >> >>If REST were purely descriptive, this would be an odd discussion. But we >>are attempting to use it prescriptively. I interpret questions like "does >>REST work?" to mean "does REST work prescriptively?". I think everyone >>else does too. > > > I don't attempt to use it prescriptively, though I know it probably > looks this way. When that happens, it's because there is some desirable > set of properties that I'm trying to achieve, and I know that they can > only reasonably be had with some subset of REST's constraints. When we tell someone to make their messages stateless so that they can improve scalability and reliability, that's a "prescription" to solve their (real or potential) "illness" of poor scalability. Paul Prescod
On Thu, Sep 12, 2002 at 12:55:22PM -0700, Paul Prescod wrote: > > I don't attempt to use it prescriptively, though I know it probably > > looks this way. When that happens, it's because there is some desirable > > set of properties that I'm trying to achieve, and I know that they can > > only reasonably be had with some subset of REST's constraints. > > When we tell someone to make their messages stateless so that they can > improve scalability and reliability, that's a "prescription" to solve > their (real or potential) "illness" of poor scalability. Right, I should have been more careful with my wording. *I'm* clearly using it prescriptively that way. But REST (the style and the dissertation) is not. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Paul Prescod wrote, > When we tell someone to make their messages stateless so that they > can improve scalability and reliability, that's a "prescription" to > solve their (real or potential) "illness" of poor scalability. Which, I guess, leaves the original question of REST, its relation to the actually existing web, and the success of that latter validating the former. The web works, despite the fact that lots of folks don't take their medicine. What other technical characteristics of the web account for that? Is there a RESTful core that's holding the whole thing together, or are there other principles at work? Would those other principles on their own be sufficient for a viable web? Cheers, Miles
Miles Sabin wrote: >... > > The web works, despite the fact that lots of folks don't take their > medicine. I think most people take their medicine most of the time. Consider the biggest perceived difference between web services of a year ago and the REST model. It was: "should there be a predefined method for getting information or is it okay for everyone to choose their own methods." It is pretty clear that significant parts of the Web would keel over and die if we had not standardized on the GET method. What would clicking on links do? How would Google work? Similarly, if the Web didn't have POST then it couldn't support creative activities like page authoring, booking flights, discussion etc. So I see those as irreducible. > ... What other technical characteristics of the web account for > that? Is there a RESTful core that's holding the whole thing together, > or are there other principles at work? Would those other principles on > their own be sufficient for a viable web? I don't personally know where REST stops and "web architecture" starts so I can't answer that question. I am confident that without the fixed, stateless, address-centric interface of HTTP, the Web wouldn't work the way we know it today. Paul Prescod
Paul Prescod wrote, > Miles Sabin wrote: > >... > > > > The web works, despite the fact that lots of folks don't take their > > medicine. > > I think most people take their medicine most of the time. As Walden said: have a cookie ... or an unsafe GET, or an abused POST. Like it or not, they're everywhere. Cheers, Miles
Miles Sabin wrote: > Paul Prescod wrote, > >>Miles Sabin wrote: >> >>>... >>> >>>The web works, despite the fact that lots of folks don't take their >>>medicine. >> >>I think most people take their medicine most of the time. > > > As Walden said: have a cookie ... or an unsafe GET, or an abused POST. What does the fact that someone, somewhere, uses an unsafe GET mean to me implementing a REST system? When I read a book on structured programming and decide to use it, it doesn't bother me that someone elsewhere is using "goto" statements to their own detriment. Most idempotent operations on the Web are done with GET. Most non-idempotent operations are done with POST. Most cookies are trivial marketing spy-ware that have nothing to do with the functionality of the site (barring authentication cookies). Most people, most of the time, use Web architecture properly whether they know they are doing that or not. Paul Prescod
Paul Prescod wrote, > > As Walden said: have a cookie ... or an unsafe GET, or an abused > > POST. > > What does the fact that someone, somewhere, uses an unsafe GET mean > to me implementing a REST system? Nothing at all. But if you're claiming that the success of web as it is is evidence for the architectural merits of REST, then it's a bit awkward if big lumps of it aren't particularly RESTful. Cheers, Miles
Kendall Clark has written an article [1] discussing the TAG 'Architectural Principles of the World Wide Web' (APW) [2] which adds some clarity to this discussion (at least from my perspective). Some of the salient points: "RFC 2396 fails spectacularly as a definition of "resource". It's wrong to commend a definition which doesn't provide any traction (a property, or condition, or state) by which one might distinguish between its *definiendum*, the thing being defined, in this case, resource, and anything else at all. " "At least two things follow from this criticism. First, it doesn't seem to make much practical difference that RFC 2396 and the APW rely on a weird definition of "resource". Second, in the problem domain of Web specifications and standards, the conceptual boundaries between "resource", "identity", "identifier", and "representation" are gerrymandered, constantly shifting, and provisional at best." "According to the APW (more accurately, to my reading of an early draft of the APW), a URI identifies one and only one *resource*, unambiguously, and the fragment identifier part of an absolute URI reference identifies some part of the *representation* of that resource. In effect, URIs have two namespaces: one which points to entities with the shared information space of the Web, another which points inside the representational space of the state of a Web resource. If URIs identify one and only resource, is there a parallel expectation that fragment identifiers identity one and only part (for lack of a more general word) of a representation? Should we extend the URI persistence practice to fragment identifiers, too? Do "cool" fragment identifiers change? " "I take the cash value of the URI-Resource unambiguity principle above to mean that the representations of the state of a resource retrieved by, say, successive HTTP GET's of the same URI are representations of the state of the *same* resource, no matter how different that state may be." In this light, PUT becomes "setting the *representation* of the state of the resource", DELETE "removing the *representation* of the state of the resource" and POST is "supplying a new *representation* of an as yet unidentified resource" or more broadly "supplying a *representation* of some state that may be of interest (directly or indirectly) to the resource or at least that the resource can do something with other than setting, deleting or retrieving a representation of the state of itself" ! Robert [1] http://www.xml.com/pub/a/2002/09/11/deviant.html [2] http://www.w3.org/TR/webarch/
> I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate > between 1. and 3. IIRC, Basically Tim's position is that "1" identifies > the HTTP resource (the W3C's web page) and "3" identifies the "logical > concept" (the W3C). I believe that Fielding thinks that 1. identifies > the logical concept and it is up to the identifying context to be > explicit whether it is talking about a resource or a representation. Tim's approach seems less robust, but the disagreement is really the problem here, as if people publish RDF that makes assertions about the following resources: http://www.w3.org http://www.w3.org/ http://www.w3.org# http://www.w3.org/# http://w3.org ... ...all of which will reach the homepage of the W3C (albeit possibly after a redirect) and yet these are all syntactically distinct, so logical statements involving one cannot be used in inferences involving the others. Problem for RDF, no? And any other mechanism used to describe web services that depends on URI syntax, which is why I mention it here. It also brings up the thorny question or URI equivalence again. > I tend to agree with Vincent that there is no reason in Web architecture > to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource > is a container. But if it isn't then it is especially annoying that it > is difficult to leave off the slash in most web servers. Again, the problem is more with the lack of consistency and the problems that will create when exact comparisons are required. Michael
Miles Sabin wrote: >As Walden said: have a cookie ... or an unsafe GET, or an abused POST. >Like it or not, they're everywhere. > But I dont think HTTP == REST. HTTP is one part of an application whose architectural style is described by REST. HTTP is what defines the semantics of GET and POST. REST only says that the command set should be small and general and that messages should be stateless. I think if you look at why people claim the web is successful, you can probably relate most of those claims to some principle of a REST-style architecture. For instance, it seems to me that a large part of the web's scalability (performance-wise) is related to the pervasiveness of caches and proxies. I don't think caches and proxies would work very well if they couln't rely on the majority of messages being stateless. (Caches are great for detecting deviations from REST.) And, I think caches and proxies would be much harder to implement if the set of commands in HTTP was much larger than it is. --Chuck
I found a site (a friend of a friend runs it) that provides free pure-HTTP access to Web search results in XML. They serve 2M queries a day and index about 5M base URLs. http://www.searchhippo.com/webservices.php http://www.searchhippo.com/partner-httpxml.php Sample: http://www.searchhippo.com/qxml.php?q=john+milton He also has some other nifty XML services: Get SMS routing info (the email address) for US cell phones. http://www.searchhippo.com/sms-httpxml.php Sample: http://www.searchhippo.com/sms-xml-resolver.php?ToPhone=4254428000
Folks, My quote (see below) seems to have left its context behind. Let me please bring it back. REST (the description of the architecture style of the same name) describes certain properties of the "legacy" web, but not others. For instance, it describes stateless client-server interaction all the while widely deployed web technologies like servlet support session state. (You can add other examples.) So REST is *selectively* descriptive, with an improvement goal espoused by its author. At the same time, REST seems to describe resources at a level of conceptualness that perhaps leads implementation by a few steps. We trip over little pieces of the HTTP spec that still make resources sound like documents instead of the concepts behind them. The verbatim relationship between PUT and GET representations, e.g.. So, while REST is not *prescriptive* in the sense that it offers process guidance or method for designing web applications, it's also not *descriptive* without the above qualifications. In other words, there may be a large intersection between REST and the deployed web in the large, but there are also significant differences (in the set theory sense of the word -- adds and deletes). Fielding said that REST emerged through analysis of the web and proposals to enhance it, and that REST has provided useful guidance in settling on enhancements. That in itself tells you that REST is not *just* a description of what exists. It also tells you that REST "works", at least for Fielding. But Fielding is doing a job somewhat different than the job we, individually, are trying to do. I think that to address the question of whether REST "works" in the sense of offering you valuable guidance in designing an application, it's important to ground that in specific problem scenarios. We can get lost in theories about idempotence and where resources end and representations begin, but do those weaknesses in the description really bring the design to a halt? I'm as guilty as the next man of attacking on theoretical grounds only. So far, my implementations have only benefitted from keeping REST in mind. Thanks, Walden > -----Original Message----- > From: Chuck Hinson [mailto:cmhinson@...] > Sent: Friday, September 13, 2002 12:03 AM > Cc: rest-discuss > Subject: Re: [rest-discuss] REST and the Web > > > > > Miles Sabin wrote: > > >As Walden said: have a cookie ... or an unsafe GET, or an > abused POST. > >Like it or not, they're everywhere. > > > But I dont think HTTP == REST. HTTP is one part of an > application whose > architectural style is described by REST. HTTP is what defines the > semantics of GET and POST. REST only says that the command > set should > be small and general and that messages should be stateless. > > > I think if you look at why people claim the web is > successful, you can > probably relate most of those claims to some principle of a > REST-style > architecture. > > For instance, it seems to me that a large part of the web's > scalability > (performance-wise) is related to the pervasiveness of caches and > proxies. I don't think caches and proxies would work very > well if they > couln't rely on the majority of messages being stateless. > (Caches are > great for detecting deviations from REST.) And, I think caches and > proxies would be much harder to implement if the set of > commands in HTTP > was much larger than it is. > > --Chuck > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
So it looks like DELETE should not return 404. Interesting. MB ----- Forwarded message from "Roy T. Fielding" <fielding@...> ----- Return-Path: <uri-request@...> Date: Fri, 13 Sep 2002 11:16:55 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: uri <uri@...> To: Paul Prescod <paul@...> From: "Roy T. Fielding" <fielding@...> In-Reply-To: <3D80EE67.9070203@...> Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> Content-Transfer-Encoding: 7bit Subject: Re: Resources always exist X-Mailing-List: <uri@...> archive/latest/1079 Sender: uri-request@... List-Id: <uri.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 X-Spam-Level: > But the HTTP spec says: > > > The DELETE method requests that the origin server delete the resource > > identified by the Request-URI. > > What does "delete the resource" mean if resources always exist? Should > DELETE be understood to clear the mapping from resources to > representations? Yes, but as far as the interface is concerned they mean the same thing. What is the difference between a resource that is DELETEd and later PUT, versus one that has no mapped representations between those two events? There are a lot of things not mentioned in the HTTP specification, for one reason or another unrelated to technology. ....Roy ----- End forwarded message ----- -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Does Roy mean that all resources exist always, even prior to their identification by the relevant naming authority? Or does he mean that once a resource is born, it always exists, even after it's been deleted? I think it must be the latter, else we have to ask what the meaning of "Created" is in response to some PUT or POST. As an implementation detail, it may be difficult for server software to keep track of all deleted resources that may have once existed, given that resource space is effectively infinite. If someone does a DELETE on a resource that has never existed, should the server discriminate that case against the case of a deleted resource? I don't think so... Perhaps a better way to think of it is thus: DELETE is idempotent in the sense that it describes an end-state of a resource, not a method. So, the existence of a resource is not an important pre-condition for DELETE. A 200 response to DELETE always means "okay, it's not mapped (now)". And who cares how we got to that state. Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Friday, September 13, 2002 9:25 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] [fielding@...: Re: Resources always > exist] > > > So it looks like DELETE should not return 404. Interesting. > > MB > > ----- Forwarded message from "Roy T. Fielding" > <fielding@...> ----- > > Return-Path: <uri-request@...> > Date: Fri, 13 Sep 2002 11:16:55 +0200 > Content-Type: text/plain; charset=US-ASCII; format=flowed > Mime-Version: 1.0 (Apple Message framework v482) > Cc: uri <uri@...> > To: Paul Prescod <paul@...> > From: "Roy T. Fielding" <fielding@...> > In-Reply-To: <3D80EE67.9070203@...> > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> > Content-Transfer-Encoding: 7bit > Subject: Re: Resources always exist > X-Mailing-List: <uri@...> archive/latest/1079 > Sender: uri-request@... > List-Id: <uri.w3.org> > List-Help: <http://www.w3.org/Mail/> > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> > X-Spam-Status: No, hits=-3.4 required=5.0 > tests=IN_REP_TO > version=2.30 > X-Spam-Level: > > > > But the HTTP spec says: > > > > > The DELETE method requests that the origin server delete > the resource > > > identified by the Request-URI. > > > > What does "delete the resource" mean if resources always > exist? Should > > DELETE be understood to clear the mapping from resources to > > representations? > > Yes, but as far as the interface is concerned they mean the > same thing. > What is the difference between a resource that is DELETEd and > later PUT, > versus one that has no mapped representations between those > two events? > > There are a lot of things not mentioned in the HTTP specification, for > one reason or another unrelated to technology. > > ....Roy > > > ----- End forwarded message ----- > > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Home Selling? Try Us! > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
I don't know (general response, not to any particular point). It seems there's quite a disconnect between the WebDAV "resource= representation" view of things, which PUT - and now DELETE - appear to be intended to support, versus the uniform interface approach of REST. I'm positive that our interpretation of GET will remain unscathed. I *expect* POST will be fine too, but I'm not certain. Anyhow, somebody should write this model down so that an extended interface could be properly designed to support it. It could end with a clutter of new methods like SET, REMOVE, etc.. but should ultimately be pretty valuable. I'd be happy to design the interface after the model has been described, but I don't think I'm the best person to design the model, since my first stab at my "abstract model" is clearly lacking in important ways, as this discussion has revealed. MB On Fri, Sep 13, 2002 at 11:47:59AM -0400, Mathews, Walden wrote: > Does Roy mean that all resources exist always, even prior to > their identification by the relevant naming authority? Or does > he mean that once a resource is born, it always exists, even > after it's been deleted? > > I think it must be the latter, else we have to ask what the > meaning of "Created" is in response to some PUT or POST. > > As an implementation detail, it may be difficult for server software > to keep track of all deleted resources that may have once existed, > given that resource space is effectively infinite. > > If someone does a DELETE on a resource that has never existed, > should the server discriminate that case against the case of a > deleted resource? I don't think so... > > Perhaps a better way to think of it is thus: DELETE is idempotent > in the sense that it describes an end-state of a resource, not > a method. So, the existence of a resource is not an important > pre-condition for DELETE. A 200 response to DELETE always means > "okay, it's not mapped (now)". And who cares how we got to that > state. > > Walden > > > > -----Original Message----- > > From: Mark Baker [mailto:distobj@...] > > Sent: Friday, September 13, 2002 9:25 AM > > To: rest-discuss@yahoogroups.com > > Subject: [rest-discuss] [fielding@...: Re: Resources always > > exist] > > > > > > So it looks like DELETE should not return 404. Interesting. > > > > MB > > > > ----- Forwarded message from "Roy T. Fielding" > > <fielding@...> ----- > > > > Return-Path: <uri-request@...> > > Date: Fri, 13 Sep 2002 11:16:55 +0200 > > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Mime-Version: 1.0 (Apple Message framework v482) > > Cc: uri <uri@...> > > To: Paul Prescod <paul@...> > > From: "Roy T. Fielding" <fielding@...> > > In-Reply-To: <3D80EE67.9070203@...> > > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> > > Content-Transfer-Encoding: 7bit > > Subject: Re: Resources always exist > > X-Mailing-List: <uri@...> archive/latest/1079 > > Sender: uri-request@... > > List-Id: <uri.w3.org> > > List-Help: <http://www.w3.org/Mail/> > > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> > > X-Spam-Status: No, hits=-3.4 required=5.0 > > tests=IN_REP_TO > > version=2.30 > > X-Spam-Level: > > > > > > > But the HTTP spec says: > > > > > > > The DELETE method requests that the origin server delete > > the resource > > > > identified by the Request-URI. > > > > > > What does "delete the resource" mean if resources always > > exist? Should > > > DELETE be understood to clear the mapping from resources to > > > representations? > > > > Yes, but as far as the interface is concerned they mean the > > same thing. > > What is the difference between a resource that is DELETEd and > > later PUT, > > versus one that has no mapped representations between those > > two events? > > > > There are a lot of things not mentioned in the HTTP specification, for > > one reason or another unrelated to technology. > > > > ....Roy > > > > > > ----- End forwarded message ----- > > > > -- > > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > > Ottawa, Ontario, CANADA. distobj@... > > http://www.markbaker.ca http://www.idokorro.com > > > > ------------------------ Yahoo! Groups Sponsor > > ---------------------~--> > > Home Selling? Try Us! > > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM > > -------------------------------------------------------------- > > -------~-> > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to > > http://docs.yahoo.com/info/terms/ > > > > -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I'm very interested in formalizing the model you're talking about, armed at the start at least with a modeling tool called Alloy, which I have some limited familiarity with but which happens to provide the benefit of automated model checking. I understand that RDF is a more appropriate end goal for expression and also better known within this group, so even if initial attempts are done in RDF, I'll try to parallel that in Alloy for my own personal reaons. However, I don't feel I have a firm enough handle on what the model needs to express to go this alone. So if someone will start to compile some informal material toward that model, I'll definitely get involved with its formalization and perhaps also be able to contribute to its scope. Where do we start? Do we take what Mark already has and start tweaking, or something else? Does this belong on rest-discuss or on some other list? What's the overall level of interest? Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Friday, September 13, 2002 12:01 PM > To: Mathews, Walden > Cc: 'Mark Baker'; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] [fielding@...: Re: Resources always > exi st] > > > I don't know (general response, not to any particular point). > > It seems there's quite a disconnect between the WebDAV "resource= > representation" view of things, which PUT - and now DELETE - > appear to be intended to support, versus the uniform interface > approach of REST. I'm positive that our interpretation of GET will > remain unscathed. I *expect* POST will be fine too, but I'm not > certain. > > Anyhow, somebody should write this model down so that an extended > interface could be properly designed to support it. It could end > with a clutter of new methods like SET, REMOVE, etc.. but should > ultimately be pretty valuable. > > I'd be happy to design the interface after the model has been > described, but I don't think I'm the best person to design the > model, since my first stab at my "abstract model" is clearly > lacking in important ways, as this discussion has revealed. > > MB > > On Fri, Sep 13, 2002 at 11:47:59AM -0400, Mathews, Walden wrote: > > Does Roy mean that all resources exist always, even prior to > > their identification by the relevant naming authority? Or does > > he mean that once a resource is born, it always exists, even > > after it's been deleted? > > > > I think it must be the latter, else we have to ask what the > > meaning of "Created" is in response to some PUT or POST. > > > > As an implementation detail, it may be difficult for server software > > to keep track of all deleted resources that may have once existed, > > given that resource space is effectively infinite. > > > > If someone does a DELETE on a resource that has never existed, > > should the server discriminate that case against the case of a > > deleted resource? I don't think so... > > > > Perhaps a better way to think of it is thus: DELETE is idempotent > > in the sense that it describes an end-state of a resource, not > > a method. So, the existence of a resource is not an important > > pre-condition for DELETE. A 200 response to DELETE always means > > "okay, it's not mapped (now)". And who cares how we got to that > > state. > > > > Walden > > > > > > > -----Original Message----- > > > From: Mark Baker [mailto:distobj@...] > > > Sent: Friday, September 13, 2002 9:25 AM > > > To: rest-discuss@yahoogroups.com > > > Subject: [rest-discuss] [fielding@...: Re: Resources always > > > exist] > > > > > > > > > So it looks like DELETE should not return 404. Interesting. > > > > > > MB > > > > > > ----- Forwarded message from "Roy T. Fielding" > > > <fielding@...> ----- > > > > > > Return-Path: <uri-request@...> > > > Date: Fri, 13 Sep 2002 11:16:55 +0200 > > > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > Mime-Version: 1.0 (Apple Message framework v482) > > > Cc: uri <uri@...> > > > To: Paul Prescod <paul@...> > > > From: "Roy T. Fielding" <fielding@...> > > > In-Reply-To: <3D80EE67.9070203@...> > > > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> > > > Content-Transfer-Encoding: 7bit > > > Subject: Re: Resources always exist > > > X-Mailing-List: <uri@...> archive/latest/1079 > > > Sender: uri-request@... > > > List-Id: <uri.w3.org> > > > List-Help: <http://www.w3.org/Mail/> > > > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> > > > X-Spam-Status: No, hits=-3.4 required=5.0 > > > tests=IN_REP_TO > > > version=2.30 > > > X-Spam-Level: > > > > > > > > > > But the HTTP spec says: > > > > > > > > > The DELETE method requests that the origin server delete > > > the resource > > > > > identified by the Request-URI. > > > > > > > > What does "delete the resource" mean if resources always > > > exist? Should > > > > DELETE be understood to clear the mapping from resources to > > > > representations? > > > > > > Yes, but as far as the interface is concerned they mean the > > > same thing. > > > What is the difference between a resource that is DELETEd and > > > later PUT, > > > versus one that has no mapped representations between those > > > two events? > > > > > > There are a lot of things not mentioned in the HTTP > specification, for > > > one reason or another unrelated to technology. > > > > > > ....Roy > > > > > > > > > ----- End forwarded message ----- > > > > > > -- > > > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > > > Ottawa, Ontario, CANADA. distobj@... > > > http://www.markbaker.ca http://www.idokorro.com > > > > > > ------------------------ Yahoo! Groups Sponsor > > > ---------------------~--> > > > Home Selling? Try Us! > > > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM > > > -------------------------------------------------------------- > > > -------~-> > > > > > > To unsubscribe from this group, send an email to: > > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > > > > > Your use of Yahoo! Groups is subject to > > > http://docs.yahoo.com/info/terms/ > > > > > > > > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > Where do we start? Do we take what Mark already has and start > tweaking, or something else? Does this belong on rest-discuss or > on some other list? What's the overall level of interest? > > > -----Original Message----- > > From: Mark Baker [mailto:distobj@...] > > > > Anyhow, somebody should write this model down so that an extended > > interface could be properly designed to support it. It could end > > with a clutter of new methods like SET, REMOVE, etc.. but should > > ultimately be pretty valuable. What/which model are we talking about here? Can someone list a few aspects of what this model is about? I'm always interested in helping in this sort of thing, but I am having trouble figuring out what the model is in the first place. --- Seairth Jacobs seairth@...
I'm not sure I agree with that. I do agree that DELETE is invalidating the mapping (the mapping from representation to resource), not necessarily the resource. However, if I were to issue a DELETE on an invalid identifier, I think it would be legitimate to return a 404. As RFC2616 notes, you could also return 410 in this case (if the server bothered to keep track). Certainly 410 would be more accurate than 404, but either should be allowed. In this perspective, the server is actually talking about the mapping. As Fielding was saying (I think), from the POV of the request, not finding a resource and not finding a mapping to a resource are just different ways of saying the same thing. --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Mark Baker" <distobj@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, September 13, 2002 9:25 AM Subject: [rest-discuss] [fielding@...: Re: Resources always exist] > So it looks like DELETE should not return 404. Interesting. > > MB > > ----- Forwarded message from "Roy T. Fielding" <fielding@...> ----- > > Return-Path: <uri-request@...> > Date: Fri, 13 Sep 2002 11:16:55 +0200 > Content-Type: text/plain; charset=US-ASCII; format=flowed > Mime-Version: 1.0 (Apple Message framework v482) > Cc: uri <uri@...> > To: Paul Prescod <paul@...> > From: "Roy T. Fielding" <fielding@...> > In-Reply-To: <3D80EE67.9070203@...> > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> > Content-Transfer-Encoding: 7bit > Subject: Re: Resources always exist > X-Mailing-List: <uri@...> archive/latest/1079 > Sender: uri-request@... > List-Id: <uri.w3.org> > List-Help: <http://www.w3.org/Mail/> > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> > X-Spam-Status: No, hits=-3.4 required=5.0 > tests=IN_REP_TO > version=2.30 > X-Spam-Level: > > > > But the HTTP spec says: > > > > > The DELETE method requests that the origin server delete the resource > > > identified by the Request-URI. > > > > What does "delete the resource" mean if resources always exist? Should > > DELETE be understood to clear the mapping from resources to > > representations? > > Yes, but as far as the interface is concerned they mean the same thing. > What is the difference between a resource that is DELETEd and later PUT, > versus one that has no mapped representations between those two events? > > There are a lot of things not mentioned in the HTTP specification, for > one reason or another unrelated to technology. > > ....Roy > > > ----- End forwarded message ----- > > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
I'm not sure I agree with THAT. First, RFC2616 doesn't mention response code 404 in the context of DELETE, which your statement below implies. Second, "The 410 response is primarily intended to assist the task of web maintenance." If I DELETE a resource successfully, then I know that the resource is now unmapped with respect to representations. How does it help me further in the service of web maintenance to get an indication that is was already unmapped? Certainly this is different from the question of which is better, 410 or 404, to return from a GET when the resource is unmapped. RFC2616 seems to be focused on specifying that, not the response codes for a DELETE. That's my reading; it's not clear in the spec. Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Friday, September 13, 2002 12:36 PM > To: rest-discuss > Subject: Re: [rest-discuss] [fielding@...: Re: Resources always > exist] > > > I'm not sure I agree with that. I do agree that DELETE is > invalidating the > mapping (the mapping from representation to resource), not > necessarily the > resource. However, if I were to issue a DELETE on an invalid > identifier, I > think it would be legitimate to return a 404. As RFC2616 > notes, you could > also return 410 in this case (if the server bothered to keep track). > Certainly 410 would be more accurate than 404, but either > should be allowed. > In this perspective, the server is actually talking about the > mapping. As > Fielding was saying (I think), from the POV of the request, > not finding a > resource and not finding a mapping to a resource are just > different ways of > saying the same thing. > > --- > Seairth Jacobs > seairth@... > > > ----- Original Message ----- > From: "Mark Baker" <distobj@...> > To: <rest-discuss@yahoogroups.com> > Sent: Friday, September 13, 2002 9:25 AM > Subject: [rest-discuss] [fielding@...: Re: Resources > always exist] > > > > So it looks like DELETE should not return 404. Interesting. > > > > MB > > > > ----- Forwarded message from "Roy T. Fielding" > <fielding@...> ----- > > > > Return-Path: <uri-request@...> > > Date: Fri, 13 Sep 2002 11:16:55 +0200 > > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Mime-Version: 1.0 (Apple Message framework v482) > > Cc: uri <uri@...> > > To: Paul Prescod <paul@...> > > From: "Roy T. Fielding" <fielding@...> > > In-Reply-To: <3D80EE67.9070203@...> > > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...> > > Content-Transfer-Encoding: 7bit > > Subject: Re: Resources always exist > > X-Mailing-List: <uri@...> archive/latest/1079 > > Sender: uri-request@... > > List-Id: <uri.w3.org> > > List-Help: <http://www.w3.org/Mail/> > > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe> > > X-Spam-Status: No, hits=-3.4 required=5.0 > > tests=IN_REP_TO > > version=2.30 > > X-Spam-Level: > > > > > > > But the HTTP spec says: > > > > > > > The DELETE method requests that the origin server > delete the resource > > > > identified by the Request-URI. > > > > > > What does "delete the resource" mean if resources always > exist? Should > > > DELETE be understood to clear the mapping from resources to > > > representations? > > > > Yes, but as far as the interface is concerned they mean the > same thing. > > What is the difference between a resource that is DELETEd > and later PUT, > > versus one that has no mapped representations between those > two events? > > > > There are a lot of things not mentioned in the HTTP > specification, for > > one reason or another unrelated to technology. > > > > ....Roy > > > > > > ----- End forwarded message ----- > > > > -- > > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > > Ottawa, Ontario, CANADA. distobj@... > > http://www.markbaker.ca http://www.idokorro.com > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> >> Does Roy mean that all resources exist always, even prior to > their identification by the relevant naming authority? Or does > he mean that once a resource is born, it always exists, even > after it's been deleted? > > I think it must be the latter, else we have to ask what the > meaning of "Created" is in response to some PUT or POST. I look at it this way: Resources can be seen from two points of view: the client and the server. >From the server POV, the resource exists exactly as long as the server wants it to exist. The server brings it into being and the server destroys it as well. I suppose you could think of the server as being omniscient with respect to the resources it controls. On the other hand, from the client POV, the resource only exists as long as it can be identified. In other words, the client knows the existance a resource once it has obtained an identifier that is mapped to that resource. When the identifier becomes invalid (via DELETE, for instance), the resource ceases to exist to the client (regardless of whether the server's POV says it still exist or not). > As an implementation detail, it may be difficult for server software > to keep track of all deleted resources that may have once existed, > given that resource space is effectively infinite. > > If someone does a DELETE on a resource that has never existed, > should the server discriminate that case against the case of a > deleted resource? I don't think so... > > Perhaps a better way to think of it is thus: DELETE is idempotent > in the sense that it describes an end-state of a resource, not > a method. So, the existence of a resource is not an important > pre-condition for DELETE. A 200 response to DELETE always means > "okay, it's not mapped (now)". And who cares how we got to that > state. A response of 200 would certainly make the interface less complicated. I have to admit that having the server decide between 200, 404, and 410 and having the client distinguish the responses is potentially unnecessary overhead. However, the one thing that 200 (used in this case) does not tell you is whether the mapping did exist or not. So, supposing you meant to delete a mapping and accidentally entered the identifier wrong. The server would not tell you that you gave an invalid identifier. On the other hand, this could be avoided by performing a GET prior to the DELETE when this was important. The trade-off here is whether you increase code and reduce network traffic by using more than one response, or vice versa. In the end, I'd say provide support for both and leave it up to the application-level semantics to determine which to use. --- Seairth Jacobs seairth@...
Seairth Jacobs wrote: > ... However, the one thing that 200 (used in this > case) does not tell > you is whether the mapping did exist or not. So, supposing > you meant to > delete a mapping and accidentally entered the identifier > wrong. The server > would not tell you that you gave an invalid identifier. I feel most strongly that that problem is out of scope for a definition of the HTTP protocol. Think about all the other undesirable effects that occur when you dereference the wrong thing and how impossible or infeasible it is to design recovery from that into a 'transfer' protocol. I've seen designs that attempt to go there and they all suck big time. I work on a system like that now. It almost chokes on its own transaction excreta. Walden
= Addressing =
The Web is first and foremost a publishing platform. It is used to
publish information and services.
We will start with the question of the best way to publish information.
There are two basic strategies possible: one is to describe uniquely for
each information object how to fetch it. Another is to standardize the
fetching mechanism and instead specify only the minimal information
required to actually do the fetch: an "address".
The older FTP protocol uses the first model. When you wanted someone to
download something through FTP you would give them instructions about
how to log into an FTP site, switch to the appropriate directory and get
the appropriate file. Conversely, HTTP leaves only one free parameter:
the address. Everything else falls out of that. You do not need to
choose the method that is used: it is always GET. You do not need to
decide what server to issue the command to: the address of the
recommended server is embedded in the address ("Uniform Resource
identifier", or "URI").
This leads us to the Web principle that all resources should be
identifiable by unique address so that they can be fetched with only GET
and the address.
= Uniform Interface =
Standardizing the means of information download is important for
maximizing the number of applications that can download information
without necessarily understanding the semantics of the information they
are downloading. Examples include caching and prefetching
proxies, command line downloading tools, web browsers, spiders and XSLT
engines.
Any architecture that has multiple ways of saying "get me some
information" will experience interoperability problems that the Web
avoids by having a few, globally optimized ways of doing so (basically
HTTP and FTP GET methods).
Because HTTP's GET is used by such a wide variety of tools, it is
necessary that it have very clear semantics. For instance, a GET cannot
be interpreted as signing a user up for a service or a prefetching cache
or spider could sign the user up just by doing its job. Therefore the
Web says that end-users are not responsible for any side effects of GET.
Services should not use GET in ways that cause side effects.
Let me stress a point made earlier: any architecture that allows every
end-node to choose its own mechanism for delivering information (SOAP
RPC, CORBA, ...) is strictly less powerful and less interoperable than
an architecture that has a single, standardized way to deliver
information because it means that every potential consumer of
information resources must be customized to talk to every publisher of
information. This is an interoperability nightmare.
The concensus on this point is sufficiently strong that the W3C has
extended SOAP 1.2 to support HTTP GET so that it would better take
advantage of the features of web architecture.
= Hypermedia =
But simply returning named information is not always enough. Often the
client application or human web surfer will not know exactly what
information they need in advance. Essentially they need to be given a
menu of options so that they may choose the appropriate one. For
instance a flight-purchasing agent might be presented with a list of
flights and might choose the "best" one based on a complex algorithm
that depends upon price, flight length and flight time. In this case, we
need an information object (a flight list) that refers to other
information objects (the flights). A data representation that has
references embedded among data is known in Web terminology as "hypermedia".
Listing things is a wonderful way of helping a client navigate to
information because they know exactly what is available and sometimes
knowing the list is as or more important as having access to any
particular item.
Google is an example of an application that really does not care about
any particular page on your site much, but cares very much about
ensuring that it has a relatively complete list of pages. So hypermedia
is a very important part of web architecture because it allows
discovery. Where possible, information delivered on the Web should be
organized into webs of hyperlinked hypermedia documents.
Because the Web is basically a flat, global address space (modulo
machines behind firewalls etc.), any resource can refer to any other
resource, no matter whether they use the same data representation or
even the same access protocol (e.g. HTTP versus FTP). This promiscuous
connectedness is what makes the Web so great and important!
The great thing about using hypermedia as an organizational model for
information repositories and services is that one process or individual
can direct another process or individual to look at and deal with a
particular resource by address and can choose the appropriate amount of
context. For instance, you can direct a purchase order processing
application to a particular purchase order rather than to a whole
"purchase order application". This is in contrast to dominant web
services methodologies that hide many resources behind a single URI and
therefore makes addressing those individual resources impossible.
Imagine if someone wanted to send you a link to the Wall Street Journal
and required you to always go to the front screen!
= Queries =
Sometimes the information provider has such a large database of
information that it is not practically (or economically) feasible for it
to deliver to the requestor in total or even to segment into many
hypermedia documents. The requestor needs to specify some reasonable
filter. This is a fallback position because it becomes difficult or
impossible for the requestor to enumerate all of the information items
even if this might be useful or important. Nevertheless, reality
requires that sometimes filtering happen on the server side and the Web
allows this through HTTP URI "query parameters".
The beautiful part of query parameters is that they are expressed as
part of the URI so that all of the tools we've built up for downloading
ordinary hyperdocument resources and lists of hyperdocument resources
can also be used on filtered lists of hyperdocument resources. The only
difference is that in this case, the URI is partially constructed by the
client application, under instructions from the server, rather than
being constructed by the server and being totally opaque to the server.
But once the URI is constructed, it is as bonified a URI as any other
one and may be put into any slot expecting a URI. They can be
"promiscuously connected", cached, downloaded with command line tools,
and so forth.
= Representations =
As the Web evolves it becomes increasingly clear that the concepts
addressed by URIs and the bits available at those URIs have distinct
lifecycles and properties. "www.theonion.com" is a news magazine. I
cannot predict what bits you will get if you dereference on the day you
read this essay. In order to discuss this distinction, we need words for
the thing that is addressed and the bits you get by going there on a
particular day, with a particular user agent, etc. The concept is known
as a "resource". The bits are known as a "representation".
Representations have media-types. Resources do not. In-so-far as
resources are "typed" (and HTTP has nothing to say about this) you might
say that they are typed by RDF. The distinction between representation
and resource allows us a very powerful form of extensibility and
adaptability. The Web has a feature called content negotiation which
allows resource consumers to ask for the resource in a variety of
different representations. One representation might be WML optimized for
hand-held computers. Another might be XHTML optimized for browsers.
Others might be PDF optimized for printers and RDF optimized for machine
discovery. As new standards come into existence, they can be served as
new representations for the information, enabling evolution of the
resource without backwards compatibility problems.
This is a good point to emphasize something that has been so-far
implicit. There is nothing in the Web architecture which is specific to
interactions with a human being at one end and a machine at the other.
Existing information resources can be made machine-accessible by adding
an XML (or XML/RDF) representation alongside existing HTML
representations. Human beings are one kind of client for web resources.
Machines are another.
= Services =
So far we have described the Web as an information publishing platform.
But over the years it has also become the world's leading service
publishing platform. There are services for bidding on auctions, booking
flights, generating insults and anything else you might dream of. The
biggest distinction between publishing information and publishing a
service is that the service may require the service provider and client
working together to generate new resources, change existing resources or
delete resources. In other words the conversation is two-way rather than
one-way.
Now before we go into detail on services I want to point out that an
important sub-task in publishing almost any service is publishing
information either held by or relating to that service. There is a
tendency to forget this when developing services using technologies such
as SOAP and XML-RPC. For instance a part of a stock purchasing service
might include a means to get the stock price. The traditional
SOAP/XML-RPC way to do this is to invent a new method called
getStockPrice. I have already discussed the interoperability limitations
of this model. So the first thing to remember about publishing services
is that whatever you do, do not neglect the information publishing part
of your service. If it can benefit from the web architecture features
described above, use them.
The second important thing to remember about publishing services is that
publishing information is crucial for the flexibility, reliability and
scalability of your service. Let's deal with each of these in turn.
Imagine a service that allows the client and server to work together to
generate a purchase order. Now they need to decide what to do with the
generated purchase order. One option is that each of them can give the
order a unique identifier (e.g. "PO number") and maintain a local copy
of it. This arrangement makes it difficult to bring third parties into
the conversation and to utilize URI-aware tools like spiders, caches,
inferencers and XSLT transformation engines. It would be better to give
the purchase order its own URI. Generally, if there is information that
is of interest to both or all participants in a conversation, that
information should be given a URI so that new participants can be easily
brought in after the fact.
Another aspect of flexibility is allowing a variety of different kinds
of clients. As long as the purchase order has a URI, the client can
decide how stateful or stateless it should be. If it wants to keep a
copy of the purchase order it can (more robust and paranoid clients
will). But if it wants to let the server manage it, it can merely keep
the URI and refresh from the server when it needs information. In a case
where the server is allowed to unilaterally change the information
resource (i.e. not a purchase order), the client can always get the
latest version of the resource using a GET.
Emphasizing the information publishing portion of your service is also
important for reliability reasons. Continuing with the purchase order
example, consider what would happen if the client party missed a message
or had its state corrupted during the communication. As long as all
relevant information has been exposed on the server as URIs, it could
rebuild its state with nothing more than the URI representing the
resource. Conversely, in situations where the state of the conversation
is implicit, one lost message can throw the client irreconcilably out of
sync with the server. Of course if the service consumer somehow loses
the URI for the thing it is talking about (e.g. the purchase order URI)
then you are in trouble. But even then you can use discovery and query
techniques to re-establish contact. For this and other reasons, resource
discovery should always be an important part of service design.
Finally there is the issue of scalability. It is often the case that
once an information resource has been created, a representation of it is
retrieved many times. Even a purchase order may be read over and over
again by internal and external auditors and order fulfillment systems.
Using standard web techniques, these representations can be cached.
So far, I've tried to show how information publishing is a crucial part
of all service publishing projects and thus to show that the service
publishing problem is an _extension_ of the information publishing
problem, not a different problem altogether. Next we will describe how
we can extend the web architecture into service publishing.
= Resource construction and mutation =
Consider a service like buying sneakers. There are three reasons that we
need to move beyond the GET-based web we have described. First, we will
want to create purchase orders, so we need a way to create objects.
Second, we need information to flow from the customer to the service
provider rather than vice versa. Third, we need to allow the "side
effect" of actually shipping the shoes.
The HTTP method designed for creating and mutating objects, with
possible side effects, is POST. POST is neither more nor less powerful
than GET. It is just different. GET's safety (side-effect-freeness)
means that clients have extreme flexibility in structuring applications
that rely heavily on GET. In particular, GET allows very "declarative"
applications that say what needs to be done but does not provide any
instructions on how to do it. For instance if an XSLT stylesheet needs
to deal with an XML element inside of a web resource it can retrieve
that document once, or ten times, or a hundred times, at its own
discretion. It might choose to do it once to optimize for bandwidth or a
hundred times to optimize for client-side memory space. If the XSLT is
using multiple documents, it can also choose the order that it retreives
them at its own discretion.
But if you do need side-effects then you need to give up some of GETs
advantages. Then you need POST. Because POST invocations may have side
effects, you must be very careful about the order in which you invoke
POST methods. You need to add the shoes to the shopping cart before you
checkout of the online store and not vice versa.
POST has another related strength/weakness. The input to GET is very
simple: basically just an address. The Web infrastructure strongly
encourages you to move retrievable information into an addressable URI.
But when the service provider and client are working together to create
new resources or modify existing ones, they both need to contribute
information. This requires a higher level of coordination which makes
POST-based integration more difficult than GET-based integration. But
this is the price of solving the more difficult problem of building
information resources rather than simply delivering them.
POST and GET work together in important ways. Using GET-based navigation
you can find the service you want to invoke. It could even report its
quality of service characteristics, terms and conditions and so forth.
Then you use POST to invoke it. This will usually either mutate or
create a resource. This resource has a URI that you can use GET to
retrieve whenever you need it. You can also refer third parties at the
resource via its URI and they can GET it. There is no need to coordinate
who GETs first or how many times you GET because GET is safe and idempotent.
POST can handle any operation which changes client-side state in a
manner that would be inappropriate for GET. But there are two operations
that have pretty clear semantics that can be separated out from the mass
of POST-based actions. Sometimes you have a URI and you want to
overwrite its content. For instance you load a document into your word
processor, make a few changes and want to save it back. Or you are
maintaining a stock quote service and it is your job to udpdate the
quotes as the most recently quoted price change. PUT allows these. The
other operation is DELETE for destroying resources (i.e. making them
into 404s).
Paul,
Stayed late at my desk on a Friday afternoon to read all the
way through. Nicely done, especially the part that explains
why we need both resources and representations. Very clear.
Walden
> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Thursday, September 12, 2002 2:06 PM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Rediscovering Web Architecture from first
> principles
>
>
> = Addressing =
>
> The Web is first and foremost a publishing platform. It is used to
> publish information and services.
>
> We will start with the question of the best way to publish
> information.
> There are two basic strategies possible: one is to describe
> uniquely for
> each information object how to fetch it. Another is to standardize the
> fetching mechanism and instead specify only the minimal information
> required to actually do the fetch: an "address".
>
> The older FTP protocol uses the first model. When you wanted
> someone to
> download something through FTP you would give them instructions about
> how to log into an FTP site, switch to the appropriate
> directory and get
> the appropriate file. Conversely, HTTP leaves only one free
> parameter:
> the address. Everything else falls out of that. You do not need to
> choose the method that is used: it is always GET. You do not need to
> decide what server to issue the command to: the address of the
> recommended server is embedded in the address ("Uniform Resource
> identifier", or "URI").
>
> This leads us to the Web principle that all resources should be
> identifiable by unique address so that they can be fetched
> with only GET
> and the address.
>
> = Uniform Interface =
>
> Standardizing the means of information download is important for
> maximizing the number of applications that can download information
> without necessarily understanding the semantics of the
> information they
> are downloading. Examples include caching and prefetching
> proxies, command line downloading tools, web browsers,
> spiders and XSLT
> engines.
>
> Any architecture that has multiple ways of saying "get me some
> information" will experience interoperability problems that the Web
> avoids by having a few, globally optimized ways of doing so (basically
> HTTP and FTP GET methods).
>
> Because HTTP's GET is used by such a wide variety of tools, it is
> necessary that it have very clear semantics. For instance, a
> GET cannot
> be interpreted as signing a user up for a service or a
> prefetching cache
> or spider could sign the user up just by doing its job. Therefore the
> Web says that end-users are not responsible for any side
> effects of GET.
> Services should not use GET in ways that cause side effects.
>
> Let me stress a point made earlier: any architecture that allows every
> end-node to choose its own mechanism for delivering information (SOAP
> RPC, CORBA, ...) is strictly less powerful and less interoperable than
> an architecture that has a single, standardized way to deliver
> information because it means that every potential consumer of
> information resources must be customized to talk to every publisher of
> information. This is an interoperability nightmare.
>
> The concensus on this point is sufficiently strong that the W3C has
> extended SOAP 1.2 to support HTTP GET so that it would better take
> advantage of the features of web architecture.
>
> = Hypermedia =
>
> But simply returning named information is not always enough. Often the
> client application or human web surfer will not know exactly what
> information they need in advance. Essentially they need to be given a
> menu of options so that they may choose the appropriate one. For
> instance a flight-purchasing agent might be presented with a list of
> flights and might choose the "best" one based on a complex algorithm
> that depends upon price, flight length and flight time. In
> this case, we
> need an information object (a flight list) that refers to other
> information objects (the flights). A data representation that has
> references embedded among data is known in Web terminology as
> "hypermedia".
>
> Listing things is a wonderful way of helping a client navigate to
> information because they know exactly what is available and sometimes
> knowing the list is as or more important as having access to any
> particular item.
>
> Google is an example of an application that really does not care about
> any particular page on your site much, but cares very much about
> ensuring that it has a relatively complete list of pages. So
> hypermedia
> is a very important part of web architecture because it allows
> discovery. Where possible, information delivered on the Web should be
> organized into webs of hyperlinked hypermedia documents.
>
> Because the Web is basically a flat, global address space (modulo
> machines behind firewalls etc.), any resource can refer to any other
> resource, no matter whether they use the same data representation or
> even the same access protocol (e.g. HTTP versus FTP). This promiscuous
> connectedness is what makes the Web so great and important!
>
> The great thing about using hypermedia as an organizational model for
> information repositories and services is that one process or
> individual
> can direct another process or individual to look at and deal with a
> particular resource by address and can choose the appropriate
> amount of
> context. For instance, you can direct a purchase order processing
> application to a particular purchase order rather than to a whole
> "purchase order application". This is in contrast to dominant web
> services methodologies that hide many resources behind a
> single URI and
> therefore makes addressing those individual resources impossible.
> Imagine if someone wanted to send you a link to the Wall
> Street Journal
> and required you to always go to the front screen!
>
> = Queries =
>
> Sometimes the information provider has such a large database of
> information that it is not practically (or economically)
> feasible for it
> to deliver to the requestor in total or even to segment into many
> hypermedia documents. The requestor needs to specify some reasonable
> filter. This is a fallback position because it becomes difficult or
> impossible for the requestor to enumerate all of the information items
> even if this might be useful or important. Nevertheless, reality
> requires that sometimes filtering happen on the server side
> and the Web
> allows this through HTTP URI "query parameters".
>
> The beautiful part of query parameters is that they are expressed as
> part of the URI so that all of the tools we've built up for
> downloading
> ordinary hyperdocument resources and lists of hyperdocument resources
> can also be used on filtered lists of hyperdocument
> resources. The only
> difference is that in this case, the URI is partially
> constructed by the
> client application, under instructions from the server, rather than
> being constructed by the server and being totally opaque to
> the server.
> But once the URI is constructed, it is as bonified a URI as any other
> one and may be put into any slot expecting a URI. They can be
> "promiscuously connected", cached, downloaded with command line tools,
> and so forth.
>
> = Representations =
>
> As the Web evolves it becomes increasingly clear that the concepts
> addressed by URIs and the bits available at those URIs have distinct
> lifecycles and properties. "www.theonion.com" is a news magazine. I
> cannot predict what bits you will get if you dereference on
> the day you
> read this essay. In order to discuss this distinction, we
> need words for
> the thing that is addressed and the bits you get by going there on a
> particular day, with a particular user agent, etc. The
> concept is known
> as a "resource". The bits are known as a "representation".
>
> Representations have media-types. Resources do not. In-so-far as
> resources are "typed" (and HTTP has nothing to say about
> this) you might
> say that they are typed by RDF. The distinction between representation
> and resource allows us a very powerful form of extensibility and
> adaptability. The Web has a feature called content negotiation which
> allows resource consumers to ask for the resource in a variety of
> different representations. One representation might be WML
> optimized for
> hand-held computers. Another might be XHTML optimized for browsers.
> Others might be PDF optimized for printers and RDF optimized
> for machine
> discovery. As new standards come into existence, they can be served as
> new representations for the information, enabling evolution of the
> resource without backwards compatibility problems.
>
> This is a good point to emphasize something that has been so-far
> implicit. There is nothing in the Web architecture which is
> specific to
> interactions with a human being at one end and a machine at the other.
> Existing information resources can be made machine-accessible
> by adding
> an XML (or XML/RDF) representation alongside existing HTML
> representations. Human beings are one kind of client for web
> resources.
> Machines are another.
>
> = Services =
>
> So far we have described the Web as an information publishing
> platform.
> But over the years it has also become the world's leading service
> publishing platform. There are services for bidding on
> auctions, booking
> flights, generating insults and anything else you might dream of. The
> biggest distinction between publishing information and publishing a
> service is that the service may require the service provider
> and client
> working together to generate new resources, change existing
> resources or
> delete resources. In other words the conversation is two-way
> rather than
> one-way.
>
> Now before we go into detail on services I want to point out that an
> important sub-task in publishing almost any service is publishing
> information either held by or relating to that service. There is a
> tendency to forget this when developing services using
> technologies such
> as SOAP and XML-RPC. For instance a part of a stock purchasing service
> might include a means to get the stock price. The traditional
> SOAP/XML-RPC way to do this is to invent a new method called
> getStockPrice. I have already discussed the interoperability
> limitations
> of this model. So the first thing to remember about
> publishing services
> is that whatever you do, do not neglect the information
> publishing part
> of your service. If it can benefit from the web architecture features
> described above, use them.
>
> The second important thing to remember about publishing
> services is that
> publishing information is crucial for the flexibility, reliability and
> scalability of your service. Let's deal with each of these in turn.
> Imagine a service that allows the client and server to work
> together to
> generate a purchase order. Now they need to decide what to do with the
> generated purchase order. One option is that each of them can give the
> order a unique identifier (e.g. "PO number") and maintain a local copy
> of it. This arrangement makes it difficult to bring third parties into
> the conversation and to utilize URI-aware tools like spiders, caches,
> inferencers and XSLT transformation engines. It would be
> better to give
> the purchase order its own URI. Generally, if there is
> information that
> is of interest to both or all participants in a conversation, that
> information should be given a URI so that new participants
> can be easily
> brought in after the fact.
>
> Another aspect of flexibility is allowing a variety of different kinds
> of clients. As long as the purchase order has a URI, the client can
> decide how stateful or stateless it should be. If it wants to keep a
> copy of the purchase order it can (more robust and paranoid clients
> will). But if it wants to let the server manage it, it can merely keep
> the URI and refresh from the server when it needs
> information. In a case
> where the server is allowed to unilaterally change the information
> resource (i.e. not a purchase order), the client can always get the
> latest version of the resource using a GET.
>
> Emphasizing the information publishing portion of your service is also
> important for reliability reasons. Continuing with the purchase order
> example, consider what would happen if the client party
> missed a message
> or had its state corrupted during the communication. As long as all
> relevant information has been exposed on the server as URIs, it could
> rebuild its state with nothing more than the URI representing the
> resource. Conversely, in situations where the state of the
> conversation
> is implicit, one lost message can throw the client
> irreconcilably out of
> sync with the server. Of course if the service consumer somehow loses
> the URI for the thing it is talking about (e.g. the purchase
> order URI)
> then you are in trouble. But even then you can use discovery and query
> techniques to re-establish contact. For this and other
> reasons, resource
> discovery should always be an important part of service design.
>
> Finally there is the issue of scalability. It is often the case that
> once an information resource has been created, a
> representation of it is
> retrieved many times. Even a purchase order may be read over and over
> again by internal and external auditors and order fulfillment systems.
> Using standard web techniques, these representations can be cached.
>
> So far, I've tried to show how information publishing is a
> crucial part
> of all service publishing projects and thus to show that the service
> publishing problem is an _extension_ of the information publishing
> problem, not a different problem altogether. Next we will describe how
> we can extend the web architecture into service publishing.
>
> = Resource construction and mutation =
>
> Consider a service like buying sneakers. There are three
> reasons that we
> need to move beyond the GET-based web we have described.
> First, we will
> want to create purchase orders, so we need a way to create objects.
> Second, we need information to flow from the customer to the service
> provider rather than vice versa. Third, we need to allow the "side
> effect" of actually shipping the shoes.
>
> The HTTP method designed for creating and mutating objects, with
> possible side effects, is POST. POST is neither more nor less powerful
> than GET. It is just different. GET's safety (side-effect-freeness)
> means that clients have extreme flexibility in structuring
> applications
> that rely heavily on GET. In particular, GET allows very "declarative"
> applications that say what needs to be done but does not provide any
> instructions on how to do it. For instance if an XSLT stylesheet needs
> to deal with an XML element inside of a web resource it can retrieve
> that document once, or ten times, or a hundred times, at its own
> discretion. It might choose to do it once to optimize for
> bandwidth or a
> hundred times to optimize for client-side memory space. If the XSLT is
> using multiple documents, it can also choose the order that
> it retreives
> them at its own discretion.
>
> But if you do need side-effects then you need to give up some of GETs
> advantages. Then you need POST. Because POST invocations may
> have side
> effects, you must be very careful about the order in which you invoke
> POST methods. You need to add the shoes to the shopping cart
> before you
> checkout of the online store and not vice versa.
>
> POST has another related strength/weakness. The input to GET is very
> simple: basically just an address. The Web infrastructure strongly
> encourages you to move retrievable information into an
> addressable URI.
> But when the service provider and client are working together
> to create
> new resources or modify existing ones, they both need to contribute
> information. This requires a higher level of coordination which makes
> POST-based integration more difficult than GET-based integration. But
> this is the price of solving the more difficult problem of building
> information resources rather than simply delivering them.
>
> POST and GET work together in important ways. Using GET-based
> navigation
> you can find the service you want to invoke. It could even report its
> quality of service characteristics, terms and conditions and
> so forth.
> Then you use POST to invoke it. This will usually either mutate or
> create a resource. This resource has a URI that you can use GET to
> retrieve whenever you need it. You can also refer third
> parties at the
> resource via its URI and they can GET it. There is no need to
> coordinate
> who GETs first or how many times you GET because GET is safe
> and idempotent.
>
> POST can handle any operation which changes client-side state in a
> manner that would be inappropriate for GET. But there are two
> operations
> that have pretty clear semantics that can be separated out
> from the mass
> of POST-based actions. Sometimes you have a URI and you want to
> overwrite its content. For instance you load a document into
> your word
> processor, make a few changes and want to save it back. Or you are
> maintaining a stock quote service and it is your job to udpdate the
> quotes as the most recently quoted price change. PUT allows
> these. The
> other operation is DELETE for destroying resources (i.e. making them
> into 404s).
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Plan to Sell a Home?
> http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
On Thursday, Sep 12, 2002, at 19:06 Europe/Dublin, Paul Prescod wrote: > [snip] bravo! i'm glad i stopped playing wolf to check my email now. it's time to curl up by the fire and do some RESTful meditation. i especially like the last section, on resource creation/mutation. the idea that service publishing is an extension of information publishing is also intriguing. thank you paul.
First, excellent summary. There wasn't a single thing I found to disagree
with. :~)
Second, you indicate something towards the end of the post that, if I
understand you correctly, mirrors a thought I have been having lately...
From: "Paul Prescod" <paul@...>
>
> [deleted]
>
> = Resource construction and mutation =
>
> [deleted]
>
> POST can handle any operation which changes client-side state in a
> manner that would be inappropriate for GET. But there are two operations
> that have pretty clear semantics that can be separated out from the mass
> of POST-based actions. Sometimes you have a URI and you want to
> overwrite its content. For instance you load a document into your word
> processor, make a few changes and want to save it back. Or you are
> maintaining a stock quote service and it is your job to udpdate the
> quotes as the most recently quoted price change. PUT allows these. The
> other operation is DELETE for destroying resources (i.e. making them
> into 404s).
You mention using PUT to update a resource, but not to create one. In fact,
the only mention of creating a resource is by the use of POST. However, the
HTTP specs state the ability to create a resource with PUT. But I am
beginning to wonder if the use of PUT in this manner is less RESTful. I see
two scenarios when using POST and PUT, the first being the way HTTP allows
and the second being the artificially contstrained (but still perfectly
legal) way that I am beginning to lean towards.
Standard HTTP Usage of POST and PUT:
1) POST:
a) Request URI points to an existing resource that will be mutated by
the contents of the request entity.
b) Request URI points to an existing resource that will use the contents
of the request entity to create a new resource.
2) PUT:
a) Request URI points to an existing resource that will be entirely
replaced by the contents of the request entity (at least from the client's
perspective).
b) Request URI does not point to an existing resource, in which case the
server creates a new resource from the request entity that is pointed to by
the request URI.
Constrained Usage of POST and PUT:
1) POST:
a) Request URI points to an existing resource that will be mutated by
the contents of the request entity.
b) Request URI points to an existing resource that will use the contents
of the request entity to create a new resource. This is the *only* method
to create a new resource. If the client wants the new resource to be
created with a specific URI associated with it, this can be passed in the
entity itself (though I wonder about using the Location header in the
request).
2) PUT:
a) Request URI points to an existing resource that will be entirely
replace by the contents of the request entity (at least from the client's
perspective).
b) There is no option (b). PUT is never used to create a new resource.
And here is why I am taking this view: Using PUT to create a resource with
a request URI just doesn't make sense. In all other verbs (GET, POST, and
DELETE), the URI must be valid and point to a resource. This makes sense.
You are accessing a resource and you need a valid identifier to do it. But
for PUT, this is only required part of the time. In some cases, you can use
PUT with an *invalid* URI (i.e. does not identify a resource) as if it were
valid. By using the constrained view, resources can still be created while
simplifying the rules about URI usage at the same time.
So, is this a view you were expressing? Is this view more consistant with
REST (simplified interface)? Or is this just a personal preference and not
any more or less RESTful than the "traditional" usage of the verbs?
---
Seairth Jacobs
seairth@...
Seairth, Yeah ,I definitely think you should use POST to create resources and never PUT (though the RFC says differently). There are many reasons why you want to do this: 1) The client should be explicitly aware of resource creation. When the client PUTs a resource they have no way of actually knowing whether they're simply updating a resource or creating a brand new resource. These are two very different things and you should force the client to acknowledge the distinction using POST. 2) Because of the principle of URI opacity, it's in poor taste to let the client assign URIs to new resources. Only the server should know about URI construction. 3) 90%+ of the time when a new resource is created (eg a purchase order, user, document, order) you rely on the database to assign a unique ID of the resource. Then, the URL you assign to that resource includes the ID or a hash of the id (eg /purchase- orders/po321343, /users/hash(social-security-#), /orders/332-43- 43523) etc. If you use PUT you rarely can enforce this interface. 4) Load balancing. When new resources are created you might want to spread them out among many different servers particularly if these are temporary resources. If you use PUT you can't do this because the client decides which machine will contain the resource (or at least process the creation request). This is often a bad idea. 5) It is very easy to enforce security when POST is used against a single URI for resource creation. 6) I think the RFC is just being flexible. AFAIK, POST as always meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant WRITE. So, for hopefully the last time, I'd say use POST to mean resource creation and PUT to mean update. - itdp --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote: > First, excellent summary. There wasn't a single thing I found to disagree > with. :~) > > Second, you indicate something towards the end of the post that, if I > understand you correctly, mirrors a thought I have been having lately... > > From: "Paul Prescod" <paul@p...> > > > > [deleted] > > > > = Resource construction and mutation = > > > > [deleted] > > > > POST can handle any operation which changes client-side state in a > > manner that would be inappropriate for GET. But there are two operations > > that have pretty clear semantics that can be separated out from the mass > > of POST-based actions. Sometimes you have a URI and you want to > > overwrite its content. For instance you load a document into your word > > processor, make a few changes and want to save it back. Or you are > > maintaining a stock quote service and it is your job to udpdate the > > quotes as the most recently quoted price change. PUT allows these. The > > other operation is DELETE for destroying resources (i.e. making them > > into 404s). > > You mention using PUT to update a resource, but not to create one. In fact, > the only mention of creating a resource is by the use of POST. However, the > HTTP specs state the ability to create a resource with PUT. But I am > beginning to wonder if the use of PUT in this manner is less RESTful. I see > two scenarios when using POST and PUT, the first being the way HTTP allows > and the second being the artificially contstrained (but still perfectly > legal) way that I am beginning to lean towards. > > Standard HTTP Usage of POST and PUT: > > 1) POST: > a) Request URI points to an existing resource that will be mutated by > the contents of the request entity. > b) Request URI points to an existing resource that will use the contents > of the request entity to create a new resource. > 2) PUT: > a) Request URI points to an existing resource that will be entirely > replaced by the contents of the request entity (at least from the client's > perspective). > b) Request URI does not point to an existing resource, in which case the > server creates a new resource from the request entity that is pointed to by > the request URI. > > > Constrained Usage of POST and PUT: > > 1) POST: > a) Request URI points to an existing resource that will be mutated by > the contents of the request entity. > b) Request URI points to an existing resource that will use the contents > of the request entity to create a new resource. This is the *only* method > to create a new resource. If the client wants the new resource to be > created with a specific URI associated with it, this can be passed in the > entity itself (though I wonder about using the Location header in the > request). > 2) PUT: > a) Request URI points to an existing resource that will be entirely > replace by the contents of the request entity (at least from the client's > perspective). > b) There is no option (b). PUT is never used to create a new resource. > > > And here is why I am taking this view: Using PUT to create a resource with > a request URI just doesn't make sense. In all other verbs (GET, POST, and > DELETE), the URI must be valid and point to a resource. This makes sense. > You are accessing a resource and you need a valid identifier to do it. But > for PUT, this is only required part of the time. In some cases, you can use > PUT with an *invalid* URI (i.e. does not identify a resource) as if it were > valid. By using the constrained view, resources can still be created while > simplifying the rules about URI usage at the same time. > > So, is this a view you were expressing? Is this view more consistant with > REST (simplified interface)? Or is this just a personal preference and not > any more or less RESTful than the "traditional" usage of the verbs? > > --- > Seairth Jacobs > seairth@s...
----- Original Message ----- From: "inthedarkplace" <inthedarkplace@...> > > 1) The client should be explicitly aware of resource creation. When > the client PUTs a resource they have no way of actually knowing > whether they're simply updating a resource or creating a brand new > resource. These are two very different things and you should force > the client to acknowledge the distinction using POST. Why? If I only ever POST to uri1 to update the resource, isn't that the same as PUT to uri1, only obscured? > > 2) Because of the principle of URI opacity, it's in poor taste to > let the client assign URIs to new resources. I don't understand that reasoning. Opacity to me means that you can't examing a portion of a URI to infer its meaning or usage - there has to be some other out-of-band communication to do that. I don't see how it is related to which side generates the URI. > Only the server should know about URI construction. I strongly disagree. > > 3) 90%+ of the time when a new resource is created (eg a purchase > order, user, document, order) you rely on the database to assign a > unique ID of the resource. Not in my systems. I tend to go for longevity and scalability rather than trivially relying on database ids. If you need to map external ids to storage ids, then add a column for the 'public identifier'. That's why email addresses aren't numbers and haven't been since CompuServe went out of business. > Then, the URL you assign to that resource > includes the ID or a hash of the id (eg /purchase- > orders/po321343, /users/hash(social-security-#), /orders/332-43- > 43523) etc. If you use PUT you rarely can enforce this interface. And when you blow out your database and re-created it, all the IDs are regenerated... hmm... > > 4) Load balancing. When new resources are created you might want to > spread them out among many different servers particularly if these > are temporary resources. If you use PUT you can't do this because > the client decides which machine will contain the resource (or at > least process the creation request). This is often a bad idea. There are lots of ways to coordinate the client and server addressing to achieve this. You could just randomly respond with a redirect to a different machine and the client should re-try the request at the new location. > > 5) It is very easy to enforce security when POST is used against a > single URI for resource creation. > > 6) I think the RFC is just being flexible. AFAIK, POST as always > meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant > WRITE. > > So, for hopefully the last time, I'd say use POST to mean resource > creation and PUT to mean update. Ahh... you aren't saying /never/ use PUT, just use it for only updates...
The <part> child of <message> has types of W3C schema datatypes -- nothing about documents per se. Seems not very RESTful. Or would a GET request not fall into the category of a WSDL "message" and so the portType, binding, and service elements would define a RESTful web service? Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
From: "inthedarkplace" <inthedarkplace@...> > > Yeah ,I definitely think you should use POST to create resources and > never PUT (though the RFC says differently). There are many reasons > why you want to do this: > > 1) The client should be explicitly aware of resource creation. When > the client PUTs a resource they have no way of actually knowing > whether they're simply updating a resource or creating a brand new > resource. These are two very different things and you should force > the client to acknowledge the distinction using POST. Umm. I thought the difference between a 200 response for updating of an existing resource and a 201 response indicating the creation of a new resource dealt with that. I am not trying to argue for the use of PUT, mind you. I'm just not sure that your statement is true. > 2) Because of the principle of URI opacity, it's in poor taste to > let the client assign URIs to new resources. Only the server should > know about URI construction. With the exception of Query Strings, of course. Beyond that, I mostly agree... more on this in a separate post... > 6) I think the RFC is just being flexible. AFAIK, POST as always > meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant > WRITE. I think also that the RFC is carrying around some old "static hypertext document" baggage. In that context (and ignoring REST for the moment), it would make sense to have a verb that allowed easy maintenance of html files sitting on a remote server. The only reason PUT didn't catch was due to the existing, well established FTP network and tools. There was no incentive to switch to PUT, add security headaches to the HTTP server, etc. when FTP already provided that without changing a thing... > So, for hopefully the last time, I'd say use POST to mean resource > creation and PUT to mean update. Clarification... POST can also be used to update an existing resource. The difference(s) between a POST and PUT update are: 1) POST does not directly cause the resource to be updated, while PUT does. yes, I know that neither actually does it directly, bit we conceptually think of them being indirect and direct (respectively). 2) POST is meant to mutate, or partially update, a resource while PUT is meant to entirely replace the resource. yes, it would be possible for POST to effectively perform a replace as well. I have had some thoughts on this too... again, I'll elaborate in a follow-up message... --- Seairth Jacobs seairth@...
In a recent post [1], I was asking about performing resource creation with
POST only. My conclusion has been that this is a good thing. What's more,
as I was falling asleep last night, additional thoughts occurred to me that
I now feel the need to share with the list. Tell me what you think...
I contend that PUT does not fit well with the REST model. First, there is
the issue of resource creation. PUT is allowed to submit a "non-existing"
request-URI as if it did exist. This request-URI has no identity whatsoever
(not even with the request-entity that will become the new resource). From
my ever-evolving understanding of REST, allowing the usage of URIs in this
manner is just plain wrong. I absolutely agree with this regardless of
REST. As I recently mentioned [1], I feel that using POST to create all
resources is just as effective and keeps the URI rules simple.
Second, there is the issue of resource update. PUT is designed to only
replace an entire resource. It is not capable of updating only a part of
the resource. Not only is this very limited in terms of functionality, but
POST can do the same thing! So, why have a separate PUT verb when POST
would work as well? I can't think of a single good reason.
Suppose, when working within the REST model, we were to entirely ignore PUT.
When using HTTP, the only verbs that would be recognized would be:
GET : safe, idempotent retrieval of an existing resource
POST: update of existing resource / creation of new resource.
DELETE: deletion of existing resource.
GET is a no-brainer here. We all pretty much agree how it should and show
not be used.
POST is now taking on the responsibility that PUT provided (not any more
than it does now, really). To clarify POST "new"
responsibilities/capabilities:
1) POST may request the creation of a new resource. If you want POST to act
like PUT, all you need to do is pass the URI that you would like to have the
new resource located at. This could be done in the request-entity, but I
suggest instead using the "Location:" header (yes, I know it's a response
header in the spec [2:14.30]). This would allow a POST like the following:
POST existing-URI-path
Location: new-URI
<entity>
The server would be able to use the request-URI to appropriately act upon
the request, and it may then choose to honor the requested Location or not
just as it would with a PUT's request-URI. The difference here is that the
request-URI must *always* exist, which is not the case for PUT.
2) POST may request that a resource be updated. This could be done in a
couple different ways:
a) The request-URI is a resource responsible for updating other
resources, where the resource knows enough context from the request to
update the appropriate resource. This could include the use of the Location
request header as well.
b) The request-URI is the resource that is to be updated. This
particular method is most like PUT. However, unlike PUT it would still be
possible for the resource to be partially updated in this case.
DELETE still works like it does now. However, it should be noted that usage
of DELETE doesn't necessarily delete the actual resource. It definitely
invalidates the relationship between the request-URI and it's currently
associated resource (thereby making *appear* as if the resource is deleted
to the client), but whether the actual resource goes entirely away is up to
the server only. I am of the mind that DELETE should return the following:
200,202,204: If the URI was valid and the request is accepted (as stated in
the spec [2:9.7]).
404: If the URI is invalid and the server does not know if it used to point
at a resource.
410: If the URI is invalid and the server knows that it used to point at a
resource.
This does mean that DELETE would not be strictly idempotent, but the client
could still act as if it were (i.e. treat all responses as the same as 200).
Part of the reason for suggesting that PUT should be depricated when working
in the REST model is due to the REST model itself. REST specifically talks
of simple, uniform interfaces. As is evident from threads on this list,
having both a PUT and a POST is not a simple, uniform interface. As I see
it, within the context of REST, POST is necessary, while PUT is optional.
Getting rid of PUT provides a simple, uniform interface as REST mentions.
An objection that I have seen in recent posts that will undoubtedly be
brought back up due to my usage of POST above is the ability to POST an
update to the resource directly. To some, this may be considered a
violation of the proper use of POST, where the request-entity is considered
to be subordinate to the resource. To me, I see no conflict here. Take the
directory-file example mentioned in the spec [2:9.5]. If you were to POST a
"file" to a "directory", this would also update the directory itself (since
the file is part of the directory resource). Any resource update could be
viewed within the same light (update of a subordinate is update of itself as
well). And I don't see anything in the HTTP spec that says a subordinate
must be accessible independently of the parent resource.
Also, some (or maybe all) of you may be disagreeing with my usage of
"Location" above. However, this makes perfect sense to me. Usage of
Location in a POST request allows all of the functionality of PUT without
having to embed any additional data in the request-entity itself. Further,
by use Location instead of the request-URI to indicate a new URI, we ensure
that only existing URIs may be used for a request-URI. This also adresses
the ability for a client to be able to construct URIs. A client could
construct a new string that will become a URI and place it in the Location
header. The server could then act on it independent of the actual
request-URI. Therefore, the request-URI still stays opaque without losing
any capabilities from the client's POV.
[1] http://groups.yahoo.com/group/rest-discuss/message/2543
[2] http://www.ietf.org/rfc/rfc2616.txt
---
Seairth Jacobs
seairth@...
Searith, There's absolutely no reason to ignore PUT. PUT is very good at what it does and it makes little sense to overload POST to mean update. In fact, I'd say using POST to mean UPDATE is a violation of REST because it suggests that there are user-visible, side-effects to simple updates which 99.9% of the time there are not -- this is why PUT is idempotent and POST is not. Further, your suggestion to use POST for limited updates isn't the optimal solution 90% of the time. Coarse-grained messaging (which I think is one of the fundamentals of REST) has proven to be more scalable and it drastically simplifies the code that both the server and the client must deal with. Further it makes all types of things easier when you're dealing with whole resources. Also your suggestion that DELETE return 4xx codes doesn't really jive with the definition of DELETE. I think Fielding has commented on this, and also it just makes sense, but DELETE should always return a 2xx if the server can guarantee that no resource exists at the given URL at the time of request. It's perfectly fine to DELETE something that's already not there and this is partially why DELETE is idempotent: whether you DELETE something 1 time or a thousand times the resource is still not there at the end of the request sequence. - itdp --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote: > In a recent post [1], I was asking about performing resource creation with > POST only. My conclusion has been that this is a good thing. What's more, > as I was falling asleep last night, additional thoughts occurred to me that > I now feel the need to share with the list. Tell me what you think... > > > I contend that PUT does not fit well with the REST model. First, there is > the issue of resource creation. PUT is allowed to submit a "non- existing" > request-URI as if it did exist. This request-URI has no identity whatsoever > (not even with the request-entity that will become the new resource). From > my ever-evolving understanding of REST, allowing the usage of URIs in this > manner is just plain wrong. I absolutely agree with this regardless of > REST. As I recently mentioned [1], I feel that using POST to create all > resources is just as effective and keeps the URI rules simple. > > Second, there is the issue of resource update. PUT is designed to only > replace an entire resource. It is not capable of updating only a part of > the resource. Not only is this very limited in terms of functionality, but > POST can do the same thing! So, why have a separate PUT verb when POST > would work as well? I can't think of a single good reason. > > Suppose, when working within the REST model, we were to entirely ignore PUT. > When using HTTP, the only verbs that would be recognized would be: > > GET : safe, idempotent retrieval of an existing resource > POST: update of existing resource / creation of new resource. > DELETE: deletion of existing resource. > > GET is a no-brainer here. We all pretty much agree how it should and show > not be used. > > POST is now taking on the responsibility that PUT provided (not any more > than it does now, really). To clarify POST "new" > responsibilities/capabilities: > > 1) POST may request the creation of a new resource. If you want POST to act > like PUT, all you need to do is pass the URI that you would like to have the > new resource located at. This could be done in the request- entity, but I > suggest instead using the "Location:" header (yes, I know it's a response > header in the spec [2:14.30]). This would allow a POST like the following: > > POST existing-URI-path > Location: new-URI > > <entity> > > The server would be able to use the request-URI to appropriately act upon > the request, and it may then choose to honor the requested Location or not > just as it would with a PUT's request-URI. The difference here is that the > request-URI must *always* exist, which is not the case for PUT. > > 2) POST may request that a resource be updated. This could be done in a > couple different ways: > a) The request-URI is a resource responsible for updating other > resources, where the resource knows enough context from the request to > update the appropriate resource. This could include the use of the Location > request header as well. > b) The request-URI is the resource that is to be updated. This > particular method is most like PUT. However, unlike PUT it would still be > possible for the resource to be partially updated in this case. > > > > DELETE still works like it does now. However, it should be noted that usage > of DELETE doesn't necessarily delete the actual resource. It definitely > invalidates the relationship between the request-URI and it's currently > associated resource (thereby making *appear* as if the resource is deleted > to the client), but whether the actual resource goes entirely away is up to > the server only. I am of the mind that DELETE should return the following: > > 200,202,204: If the URI was valid and the request is accepted (as stated in > the spec [2:9.7]). > 404: If the URI is invalid and the server does not know if it used to point > at a resource. > 410: If the URI is invalid and the server knows that it used to point at a > resource. > > This does mean that DELETE would not be strictly idempotent, but the client > could still act as if it were (i.e. treat all responses as the same as 200). > > > > Part of the reason for suggesting that PUT should be depricated when working > in the REST model is due to the REST model itself. REST specifically talks > of simple, uniform interfaces. As is evident from threads on this list, > having both a PUT and a POST is not a simple, uniform interface. As I see > it, within the context of REST, POST is necessary, while PUT is optional. > Getting rid of PUT provides a simple, uniform interface as REST mentions. > > An objection that I have seen in recent posts that will undoubtedly be > brought back up due to my usage of POST above is the ability to POST an > update to the resource directly. To some, this may be considered a > violation of the proper use of POST, where the request-entity is considered > to be subordinate to the resource. To me, I see no conflict here. Take the > directory-file example mentioned in the spec [2:9.5]. If you were to POST a > "file" to a "directory", this would also update the directory itself (since > the file is part of the directory resource). Any resource update could be > viewed within the same light (update of a subordinate is update of itself as > well). And I don't see anything in the HTTP spec that says a subordinate > must be accessible independently of the parent resource. > > Also, some (or maybe all) of you may be disagreeing with my usage of > "Location" above. However, this makes perfect sense to me. Usage of > Location in a POST request allows all of the functionality of PUT without > having to embed any additional data in the request-entity itself. Further, > by use Location instead of the request-URI to indicate a new URI, we ensure > that only existing URIs may be used for a request-URI. This also adresses > the ability for a client to be able to construct URIs. A client could > construct a new string that will become a URI and place it in the Location > header. The server could then act on it independent of the actual > request-URI. Therefore, the request-URI still stays opaque without losing > any capabilities from the client's POV. > > > [1] http://groups.yahoo.com/group/rest-discuss/message/2543 > [2] http://www.ietf.org/rfc/rfc2616.txt > > > --- > Seairth Jacobs > seairth@s...
Well, I will join the general chorus of praise for this fine piece. There is one point that bothers me, though: On Thu, Sep 12, 2002 at 11:06:24AM -0700, Paul Prescod wrote: > quotes as the most recently quoted price change. PUT allows these. The > other operation is DELETE for destroying resources (i.e. making them > into 404s). Must they be 404s instead of, say, 302s? To me this is very unfriendly; there are already far too many URIs that have ceased to point to anything for no very good reason. Regardless of what Fielding or RFC2616 may say (though the latter is silent as far as I can tell), I'm with Jakob Nielsen on this: in principle, maintainers of web resources should never knowingly remove them (or allow them to be removed) without providing a reasonable redirect or substitute. -- Matt Gushee Englewood, Colorado, USA mgushee@... http://www.havenrock.com/
From: "inthedarkplace" <inthedarkplace@...> > > There's absolutely no reason to ignore PUT. PUT is very good at what > it does and it makes little sense to overload POST to mean update. > In fact, I'd say using POST to mean UPDATE is a violation of REST > because it suggests that there are user-visible, side-effects to > simple updates which 99.9% of the time there are not -- this is why > PUT is idempotent and POST is not. > > Further, your suggestion to use POST for limited updates isn't the > optimal solution 90% of the time. Coarse-grained messaging (which I > think is one of the fundamentals of REST) has proven to be more > scalable and it drastically simplifies the code that both the server > and the client must deal with. Further it makes all types of things > easier when you're dealing with whole resources. So POST should not be used to update a resource and PUT can only update a resource by replacing it, then how do you update only a part of a resource? --- Seairth Jacobs seairth@...
Seairth, I think the point is you shouldn't be doing partial updates of a resource. Partial updates is very non-RESTful. Even if a user just wants to update their email address they should still have to upload all their other information. Remember, you're transferring resources not resource fragments or resource parameters. Your idea of using POST for partial updates seems a bit too RPC-like and it'd only complicate most systems. Also in general you don't want to send fine- grained messages such as 'change my email address'. The SOAP people are just discovering this [see http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/] but it's one of the fundamental tenets of REST. Also the partial update problem isn't really a problem per se since most people aren't dealing with obscenely large resources. If a resource is obscenely large and there's a strong case for partial updates then there's nothing technically wrong with using POST to implement partial update. Also, as a last note, there's nothing that says the user has to upload the entire resource when using PUT or that the server is not allowed to perform processing on the PUT entity body. The server still has final say over what is actually PUT'ed to the URL. - itdp --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote: > From: "inthedarkplace" <inthedarkplace@y...> > > > > There's absolutely no reason to ignore PUT. PUT is very good at what > > it does and it makes little sense to overload POST to mean update. > > In fact, I'd say using POST to mean UPDATE is a violation of REST > > because it suggests that there are user-visible, side-effects to > > simple updates which 99.9% of the time there are not -- this is why > > PUT is idempotent and POST is not. > > > > Further, your suggestion to use POST for limited updates isn't the > > optimal solution 90% of the time. Coarse-grained messaging (which I > > think is one of the fundamentals of REST) has proven to be more > > scalable and it drastically simplifies the code that both the server > > and the client must deal with. Further it makes all types of things > > easier when you're dealing with whole resources. > > So POST should not be used to update a resource and PUT can only update a > resource by replacing it, then how do you update only a part of a resource? > > --- > Seairth Jacobs > seairth@s...
From: "inthedarkplace" <inthedarkplace@...>
>
> I think the point is you shouldn't be doing partial updates of a
> resource. Partial updates is very non-RESTful. Even if a user just
> wants to update their email address they should still have to upload
> all their other information. Remember, you're transferring resources
> not resource fragments or resource parameters. Your idea of using
> POST for partial updates seems a bit too RPC-like and it'd only
> complicate most systems. Also in general you don't want to send fine-
> grained messages such as 'change my email address'. The SOAP people
> are just discovering this [see
> http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/]
> but it's one of the fundamental tenets of REST.
Would it be acceptible to ask the server for a URI that represented the part
of the resource you want to update and treat it as if it's a true resource?
> Also, as a last note, there's nothing that says the user has to
> upload the entire resource when using PUT or that the server is not
> allowed to perform processing on the PUT entity body. The server
> still has final say over what is actually PUT'ed to the URL.
I'm not sure I agree with that. From the rfc:
"If the Request-URI refers to an already existing resource, the
enclosed entity SHOULD be considered as a modified version
of the one residing on the origin server."
Now, I realize that it says "SHOULD" and not "MUST". But that's still
saying that using PUT in any other way is strongly discouraged.
---
Seairth Jacobs
seairth@...
inthedarkplace wrote: > Searith, > > There's absolutely no reason to ignore PUT. I agree. > PUT is very good at what > it does and it makes little sense to overload POST to mean update. > In fact, I'd say using POST to mean UPDATE is a violation of REST > because it suggests that there are user-visible, side-effects to > simple updates which 99.9% of the time there are not -- this is why > PUT is idempotent and POST is not. Side-effects are one thing. Idempotency is another. I think that PUT will have side effects, but idempotent ones. For instance if I have a resource representing the list of titles of documents of pages on my site, PUT-ting to a document will change the list as a side-effect. But changing the resource over and over again will not have any different effect than doing it once. So it is idempotent. Paul Prescod
Sam Hunting wrote: > The <part> child of <message> has types of W3C schema datatypes -- nothing > about documents per se. Seems not very RESTful. > > Or would a GET request not fall into the category of a WSDL "message" and > so the portType, binding, and service elements would define a RESTful web > service? WSDL is not RESTful because it does not support hypertext as the engine of application space: * http://lists.w3.org/Archives/Public/www-tag/2002Sep/0086.html Paul Prescod
[paul prescod] > WSDL is not RESTful because it does not support hypertext as the engine > of application space: > > * http://lists.w3.org/Archives/Public/www-tag/2002Sep/0086.html Got it. Thanks. That's the closest to a one-line description of REST as I've heard ... Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
Seairth Jacobs wrote: >... > > I contend that PUT does not fit well with the REST model. First, there is > the issue of resource creation. PUT is allowed to submit a "non-existing" > request-URI as if it did exist. This request-URI has no identity whatsoever > (not even with the request-entity that will become the new resource). From > my ever-evolving understanding of REST, allowing the usage of URIs in this > manner is just plain wrong. I absolutely agree with this regardless of > REST. As I recently mentioned [1], I feel that using POST to create all > resources is just as effective and keeps the URI rules simple. It would simplify the rule that the client should never invent URIs except for query strings. But it would complicate content-management applications where the human end-user is choosing mmenonic URIs. > Second, there is the issue of resource update. PUT is designed to only > replace an entire resource. It is not capable of updating only a part of > the resource. There are two orthogonal issues here. One is "I want to save bandwidth and only send a diff of what's changed since yesterday." I think we could argue that both PUT and GET should allow this and in fact there is an unfinished proposal floating around. This is still appropriate for PUT because it is just an optimization of sending the whole resource. It's a conceptual overwrite that happens to be optimized. The second issue is: "I know I want to change a particular element. I don't know or care about the state of other surrounding elements." That's where you use POST because it is a conceptual mutation and optimization is irrelevant. > ... Not only is this very limited in terms of functionality, but > POST can do the same thing! So, why have a separate PUT verb when POST > would work as well? I can't think of a single good reason. I disagree. If anything, I would go in the opposite direction. I would say that POST has too many meanings (sometimes it mutates a resource, sometimes it totally overwrites it, sometimes it creates a resource, sometimes it even has no side-effects at all). It is better to split these out into independent methods so that you know exactly what is going to happen when you invoke a method on a server. PUT is a little like "copy" on a command line. You know that after you invoke it what you will end up with. POST is more like invoking a program. What happens depends on the program. Also, PUT's idempotency is important: * http://www.prescod.net/reliable_http.html > ... > Part of the reason for suggesting that PUT should be depricated when working > in the REST model is due to the REST model itself. REST specifically talks > of simple, uniform interfaces. As is evident from threads on this list, > having both a PUT and a POST is not a simple, uniform interface. As I see > it, within the context of REST, POST is necessary, while PUT is optional. > Getting rid of PUT provides a simple, uniform interface as REST mentions. Uniformity of interface is very important. Simplicity is much less important. I wouldn't mind an HTTP with 15 methods. As long as every HTTP client and server in the world understood those 15 methods, and every resource had a reasonable answer for every one of them, that would be a "uniform interface". The point is that clients and servers should not have to negotiate the meaning of the interfaces out of band. But we often DO have to negotiate the meaning of POST. So to me, more methods would do a better job of living up to the potential of REST, rather than fewer. (for instance I would love to see WATCH, NOTIFY, etc.) > Also, some (or maybe all) of you may be disagreeing with my usage of > "Location" above. However, this makes perfect sense to me. Usage of > Location in a POST request allows all of the functionality of PUT without > having to embed any additional data in the request-entity itself. Further, > by use Location instead of the request-URI to indicate a new URI, we ensure > that only existing URIs may be used for a request-URI. This also adresses > the ability for a client to be able to construct URIs. A client could > construct a new string that will become a URI and place it in the Location > header. The server could then act on it independent of the actual > request-URI. Therefore, the request-URI still stays opaque without losing > any capabilities from the client's POV. But what does the request-URI *mean*? What is its relationship to the Location URI? It seems irrelevant which points me back to PUT with its single URI. Paul Prescod
inthedarkplace wrote: > ... > Also in general you don't want to send fine- > grained messages such as 'change my email address'. I think you're both right. If you are going to change a bunch of values then you should do that in a batch rather than sending just the email address and then just the person's name and then, etc. But if ALL you want to do is change the email address, I see nothing wrong with doing that. > ... The SOAP people > are just discovering this [see > http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/] > but it's one of the fundamental tenets of REST. Thanks for sending this on. I just wrote about it on my intermittently maintained Weblog: http://www.blogstream.com/pauls/1032124150 > ... > Also, as a last note, there's nothing that says the user has to > upload the entire resource when using PUT or that the server is not > allowed to perform processing on the PUT entity body. The server > still has final say over what is actually PUT'ed to the URL. I believe there is some debate on this issue. It could stand clarification in a future version of HTTP or something like that. Paul Prescod
I gave a presentation last week to the WSAWG, basically comparing REST to some other architectural styles. http://www.markbaker.ca/2002/08/Rest/ MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Paul Prescod wrote: > Thanks for sending this on. I just wrote about it on my intermittently > maintained Weblog: > > http://www.blogstream.com/pauls/1032124150 Sorry, the article ID changed: http://www.blogstream.com/pauls/1032125477/index_html Paul Prescod
On Sun, 15 Sep 2002, Mark Baker wrote: > I gave a presentation last week to the WSAWG, basically comparing REST > to some other architectural styles. > > http://www.markbaker.ca/2002/08/Rest/ DO you see a strong overlap between applications or systems that would use these different architectural styles? For example if under REST "hypertext is the engine of application state", a tuple-space application's state might well be determined by URIs being put up into the tuple space, with documents being taken down from the tuple space and returned to the larger system. Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.goose-works.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
On Sun, Sep 15, 2002 at 06:04:17PM -0400, Sam Hunting wrote: > On Sun, 15 Sep 2002, Mark Baker wrote: > > > I gave a presentation last week to the WSAWG, basically comparing REST > > to some other architectural styles. > > > > http://www.markbaker.ca/2002/08/Rest/ > > DO you see a strong overlap between applications or systems that would use > these different architectural styles? There's some overlap, for sure. Between OO-RPC - which is basically the Web services style - and REST, there's definitely a *lot* of overlap. > For example if under REST "hypertext > is the engine of application state", a tuple-space application's state > might well be determined by URIs being put up into the tuple space, with > documents being taken down from the tuple space and returned to the larger > system. I don't think that's a great example, but I'm all for thinking about new constraints which could be added to REST to induce new useful properties, such as Rohit's work on ALIN. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> 2) Please don't use XML-based errors. It's very annoying to go > through all the trouble of parsing an XML document just to discover > it contains no useful information. HTTP has a rich set of built in > response codes you should use. mmm, I was debating this myself, in the end I opted for XML because I actually found it easier to work with than HTTP codes. I am coding from a PHP background, so maybe I'm missing some functionality that others are taking for granted, but it's actually a lot easier to parse a response document and check it for errors than it is to manipulate an HTTP header (although it does introduce some unfortunate overheads in the XML tags etc). Who do other people feel about this? Would people prefer to use HTTP headers to determine errors? > 2.2) Similarly, the behavior you expose tends to be made > redundant by HTTP. For example, your method doGetCachedPage simply > returns the HTML of the cached page straight from google. Rather than > doing this, I'd suggest issuing an HTTP Redirect to the client so > they can retrieve the cached page themselves. doGetCachedPage actually cleans up the document a little bit before sending it to the client. When returned directly from Google's cache, the page has the Google header on it (the same as if you view a cached page from Google.com), this is removed before sending the page back to the XooMLe client. > 3) This is trivial but I don't really see the need for the top- level > XML element 'doGoogleSearchResponse' since that's a bit verb-like. > Having 'GoogleSearchResult' as the root seems cleaner to me. Also, > since XML is case-sensitive and since ppl will be writing xslts to > handle Xoomle responses I'd suggest being consistent with your naming > convention. Since you're using camel-casing it seems > like 'GoogleSearchResult' should be 'googleSearchResult'. That one wasn't my personal choice. In developing the XML response document, what I have actually done is to just take the SOAP envelope that is returned, then strip it down to something simpler. I suppose I should have taken out that additional element (and I left their "case"ing as-was as well), but I left it in because that's what was there to start with, so the XML-version is a lightweight (but very similar structure-wise) version of the SOAP version. > 1) How do I pass the 'site:' restriction to Xoomle? Is this just > something the Google SOAP api forbids? you should be able to do this as normal - for example, go to http://www.dentedreality.com.au/xoomle/search/ and enter "site:dentedreality.com.au xoomle" and it will return pages containing "xoomle" from my domain only :) > 2) Is there any way to expose the directories offered by the Google > Directory? directory information is offered (where available) within each resultElement in the reponse document. i.e. Search for "information architecture" and in the first resultElement (doGoogleSearchResponse//GoogleSearchResult//resultElements//item [0]//directoryCategory//fullyViewableName) there is the value "Top/Reference/Knowledge_Management/Information_Architecture" which is used by Google to create a link to their Groups directory (They do a search and replace of "/" for " > " for the visible name of the link, and link to http://directory.google.com/<fullyViewableName>) > 3) Can you explain more about how max results work? maxResults is a restriction that Google uses to determine how many results to return on a particular query. i.e. you set maxResults=3 and it will only return 3 results (incidentally, if you set start=10&maxResults=3, it will give results 10-13 of the total result set). In the Google API, maxResults is limited to a maximum (maxMaxResults?? :P) of 10. XooMLe "cheats" this limit by allowing you to specify (for eaxmple) maxResults=30. The way it does this is by seeing that you want more than 10, it then gets the first 10, if the estimatedTotalResultsCount is over 10, then it gets the next 10 (and so on and so on) until it has the number of results you asked for. It then compiles these all into one response document, and sends it all back to you. BE AWARE that this counts as 3 queries (decrements your daily limit of 1000 by 3) even though from your end you only do one query, since XooMLe obviously has to do 3 queries on your behalf. As a side note, the searchTime element is summed based on the amount of time each query took, so it is still accurate, although will be higher than if Google allowed the larger single request obviously. > 4) What do the plain-text spelling suggestions response look like? > Are you sure you don't want to return an XML document instead? Try it out - http://www.dentedreality.com.au/xoomle/spell/ They just have the standard headers, then the plain text response. If you parse the source of the URL required to get a reponse, then it will have nothing but the suggestion in it. Ok, there we go, hope that answers some questions and indicates my intentions :) Thanks a lot for your feedback, I really appreciate it. This is a large learning experience for me, and I hope some other people are learning some things and finding something useful along the way as well :) Regards, Beau
I don't know if I mentioned this before, but I helped a guy develop an RDF/HTTP wrapper for the Google SOAP API; http://nutria.cs.tu-berlin.de/roodolf/ MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> There are two orthogonal issues here. One is "I want to save > bandwidth > and only send a diff of what's changed since yesterday." I think we > could argue that both PUT and GET should allow this and in > fact there is > an unfinished proposal floating around. This is still appropriate for > PUT because it is just an optimization of sending the whole resource. > It's a conceptual overwrite that happens to be optimized. > > The second issue is: "I know I want to change a particular element. I > don't know or care about the state of other surrounding elements." > That's where you use POST because it is a conceptual mutation and > optimization is irrelevant. Even squinting hard I just can't seem to find the difference between these. In both cases we are only concerned with a discrete subset of the resource's state, for whatever reason. I think your analysis below that says PUT is like COPY while POST is like invoking a program makes more sense. If I want to COPY over all or part of resource state, I use PUT (no matter what I think of this in terms of optimization), and if I want a program to take control of applying some new information to an old resource, then I use POST. Understood that the server will do as it please in either case, but in the COPY mode, the client is requesting a specific limited overlay behavior, while in the PROGRAM mode, it is saying "you decide what to do with this". > I disagree. If anything, I would go in the opposite > direction. I would > say that POST has too many meanings (sometimes it mutates a resource, > sometimes it totally overwrites it, sometimes it creates a resource, > sometimes it even has no side-effects at all). It is better to split > these out into independent methods so that you know exactly what is > going to happen when you invoke a method on a server. PUT is a little > like "copy" on a command line. You know that after you invoke it what > you will end up with. POST is more like invoking a program. > What happens > depends on the program. [snip] > Uniformity of interface is very important. Simplicity is much less > important. I wouldn't mind an HTTP with 15 methods. As long as every > HTTP client and server in the world understood those 15 methods, and > every resource had a reasonable answer for every one of them, > that would > be a "uniform interface". The point is that clients and > servers should > not have to negotiate the meaning of the interfaces out of > band. But we > often DO have to negotiate the meaning of POST. So to me, > more methods > would do a better job of living up to the potential of REST, > rather than > fewer. (for instance I would love to see WATCH, NOTIFY, etc.) I agree with this, and would like to echo from a paragraph or two above that methods that intend to create new resources would be a nice improvement. Right now, creation is implicit through both PUT and POST.* There is still the argument that the server knows best how to manage its information base, but that doesn't invalidate the idea that clients should be able to express the HINT that they would like resources created. * Creation is implicit on the request side, while it's supposed to be explicit on the result side, via 302 Created. Above, I'm talking about the request side. > >
Paul, In your "first principles" posting of last Friday, there was an interesting bit on queries and how the client can, by following instructions from the server, participate in the composition of query-extended URI. I want to ask a general question about how this should work, independent of HTML and current browser technology, where I understand its working well enough. Making no assumptions about the format of the entities, what can be said about a standard for providing (server) and following (client) instructions for extending URI with query parameters? Here's my real-life example from a current project. A Portfolio resource (let's say it's at URI: "/Portfolio") undergoes changes, but can be retrieved via "as of" snapshots. The client does not care exactly when the Portfolio changed; it only needs to know "what was my Portfolio as-of 2002-09-16 end-of-business?". The server may choose to impose the convention of appending a simple yyyymmdd encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916". How does it encode instructions for the client to do this in some standard way, barring HTML as a specific solution? Does Xforms address this problem? Would there be any particular reason to prefer "/Portfolio?asof=20020916" or some other encoding over the one above? Walden
Mathews, Walden wrote: > Paul, > > In your "first principles" posting of last Friday, there was > an interesting bit on queries and how the client can, by following > instructions from the server, participate in the composition of > query-extended URI. > > I want to ask a general question about how this should work, independent > of HTML and current browser technology, where I understand its > working well enough. > > Making no assumptions about the format of the entities, what can > be said about a standard for providing (server) and following (client) > instructions for extending URI with query parameters? WSDL and WRDL both have facilities to allow this. > Here's my real-life example from a current project. A Portfolio > resource (let's say it's at URI: "/Portfolio") undergoes changes, but > can be retrieved via "as of" snapshots. The client does not care > exactly when the Portfolio changed; it only needs to know "what was > my Portfolio as-of 2002-09-16 end-of-business?". The server may > choose to impose the convention of appending a simple yyyymmdd > encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916". > How does it encode instructions for the client to do this in some > standard way, barring HTML as a specific solution? Does Xforms > address this problem? Yes, XForms supports query construction. WSDL and WRDL are design-time standards. XForms is a runtime standard. So it depends on which you want. But if you are doing it at runtime, then consider using a hyperlink instead. It requires less client-side knowledge to navigate a hyperlink. > Would there be any particular reason to prefer > "/Portfolio?asof=20020916" or some other encoding over the one > above? There are two resources: /Portfolio /Portfolio/20020916 Common wisdom (Jeff Bone would say "dogma") in the Web architecture world is that the client should not construct the URI for latter from the former. Basically if you tell the client to do that, then you are committing to that exact naming scheme forever. For instance someone could make a hyperlink today to a document that will come into existence in 2003. On the other hand, if you put in a level of indirection between the resources then the client is told that you reserve the right to change your naming convention any time. Here's how you do that: --> GET /Portfolio?asof=20020916 <-- 200 OK <resource asof="20020916" href="/Portfolio/20020916"/> Then client applications dereference through that query to get at the concrete resource associated with a particular date. The query language could be arbitrarily complex. As in: --> GET /Portfolio?from=20020913;to=20020918 <-- 200 OK <resources> <resource asof="20020913" href="/Portfolio/20020913"/> <resource asof="20020914" href="/Portfolio/20020914"/> <resource asof="20020914" href="/Portfolio/20020915"/> <resource asof="20020914" href="/Portfolio/20020916"/> </resources> Admittedly the indirection has costs. But essentially your "contract" is now only to maintain the indirection service, not to keep the same URI naming scheme forever. Your successor might appreciate the freedom. The same might go for anyone implementing duplicates of your service elsewhere in the world. Maybe they want to serve portfolio snapshots through ftp: or from a seperate server @.... That said, you can achieve a similar effect using redirect status codes. I think that the difference is in the contract you are signing up for. Paul Prescod
> > On Sun, 15 Sep 2002, Mark Baker wrote:
> >
> > > I gave a presentation last week to the WSAWG, basically comparing REST
> > > to some other architectural styles.
> > >
> > > http://www.markbaker.ca/2002/08/Rest/
> >
> > DO you see a strong overlap between applications or systems that would use
> > these different architectural styles?
>
> There's some overlap, for sure. Between OO-RPC - which is basically the Web
> services style - and REST, there's definitely a *lot* of overlap.
>
> > For example if under REST "hypertext
> > is the engine of application state", a tuple-space application's state
> > might well be determined by URIs being put up into the tuple space, with
> > documents being taken down from the tuple space and returned to the larger
> > system.
>
> I don't think that's a great example, but I'm all for thinking about
> new constraints which could be added to REST to induce new useful
> properties, such as Rohit's work on ALIN.
One might wish to gain the benefits distributed processing (eg, through
tuple space), and even of the http protocol, without necessarity using
http VERBs -- particularly where the process is "atomic." See Jeff Bone's
"Dining Philosophers" discussion at
http://www.xent.com/pipermail/fork/2001-August/002923.html
<quote>
The lesson is pretty clear: it's always a bad idea to manage
transactions (i.e., attempt to guarantee atomicity of a sequence of
actions, *even if this is made possible by the underlying communication
model*) non-locally. Whenever possible --- and it's always possible ---
atomic sequences of interactions should be managed by intermediate objects
local to the resources being locked and manipulated; it's trivial to
encapsulate transactions into a single atomic exchange, and exposing those
encapsulations as first class entities is generally a pretty good idea.
And it certainly fits with the REST model of the world. MUCH more so, in
fact, than RPC
</quote>
So the set of tasks that REST *should* do is a subset of the tasks that
REST *can* do.
So my example may or may not be "great", but I'm not sure whether you mean
its lack of greatness lies in being a poor illustration of REST
principles, or whether you think it's just one more bad idea. Can you
elucidate? Thanks.
Sam Hunting
eTopicality, Inc.
---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)
Topic map consulting and training: www.etopicality.com
Free open source topic map tools: www.goose-works.org
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------
From: "Paul Prescod" <paul@...> > > There are two resources: > > /Portfolio > /Portfolio/20020916 > > Common wisdom (Jeff Bone would say "dogma") in the Web architecture > world is that the client should not construct the URI for latter from > the former. Basically if you tell the client to do that, then you are > committing to that exact naming scheme forever. For instance someone > could make a hyperlink today to a document that will come into existence > in 2003. On the other hand, if you put in a level of indirection between > the resources then the client is told that you reserve the right to > change your naming convention any time. Here's how you do that: > > --> > GET /Portfolio?asof=20020916 > > <-- > 200 OK > <resource asof="20020916" href="/Portfolio/20020916"/> > > Then client applications dereference through that query to get at the > concrete resource associated with a particular date. I recently noticed the Content-Location header in the HTTP. Could this be used for such a purpose? Instead of requiring redirection (which means additional network traffic), you could return the expected response pluse the header: --> GET /Portfolio?asof=20020916 <-- 200 OK Content-Location: /Protfolio/20020916 <response-entity here> I know this would not work for the complex query example you gave, but in the case where you are querying for a single resource... maybe? --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Paul Prescod" <paul@...> > --> > GET /Portfolio?from=20020913;to=20020918 > > <-- > 200 OK > <resources> > <resource asof="20020913" href="/Portfolio/20020913"/> > <resource asof="20020914" href="/Portfolio/20020914"/> > <resource asof="20020914" href="/Portfolio/20020915"/> > <resource asof="20020914" href="/Portfolio/20020916"/> > </resources> > Wouldn't the client need to know as much information to /deconstruct/ the data as it would to /construct/ the URIs? Both have 'asof' as a nifty name, and both have '20020914',etc as the syntax and value space for that name.
Paul Prescod wrote: > But if you are doing it at runtime, then consider using a > hyperlink instead. It requires less client-side knowledge to > navigate a hyperlink. That would have been my first choice, but there seem to be infinitely many of them, as in your description before of resources so large they can only be addressed reasonably through search parameters. I think this is the same, because 'as of' is not constrained to any particular time segment or time granularity (even though I indicated business-day granularity before). Maybe I don't understand what you mean by "consider using a hyperlink instead." > Common wisdom (Jeff Bone would say "dogma") in the Web architecture > world is that the client should not construct the URI for latter from > the former. Basically if you tell the client to do that, then you are > committing to that exact naming scheme forever. What if the client is following a set of (dynamic) instructions from the server on how to construct such a URL? If the naming scheme changes, then so does the instructions. > For instance someone > could make a hyperlink today to a document that will come > into existence > in 2003. On the other hand, if you put in a level of > indirection between > the resources then the client is told that you reserve the right to > change your naming convention any time. Here's how you do that: > > --> > GET /Portfolio?asof=20020916 > > <-- > 200 OK > <resource asof="20020916" href="/Portfolio/20020916"/> Okay, I get the indirection bit, but along the way I wondered how the client knew how to do that GET. Did I tell her how to format that? > > Then client applications dereference through that query to get at the > concrete resource associated with a particular date. The > query language > could be arbitrarily complex. As in: > > --> > GET /Portfolio?from=20020913;to=20020918 > > <-- > 200 OK > <resources> > <resource asof="20020913" href="/Portfolio/20020913"/> > <resource asof="20020914" href="/Portfolio/20020914"/> > <resource asof="20020914" href="/Portfolio/20020915"/> > <resource asof="20020914" href="/Portfolio/20020916"/> > </resources> > > Admittedly the indirection has costs. But essentially your > "contract" is > now only to maintain the indirection service, not to keep the > same URI > naming scheme forever. Your successor might appreciate the > freedom. The > same might go for anyone implementing duplicates of your service > elsewhere in the world. Maybe they want to serve portfolio snapshots > through ftp: or from a seperate server @.... Hmmm. I think you're still assuming that there is a finite number of these resources and that given the right question, the server can dish up a finite set of references for getting at them. Time ain't like that. While asking the original question, I realized that a better application design on the server side keeps a versioning history and so could offer a list of versions as you have above. Unfortunately, the legacy app hiding behind my web service wasn't that smart. 8-( Walden
S. Mike Dierken wrote: > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > >>--> >>GET /Portfolio?from=20020913;to=20020918 >> >><-- >>200 OK >><resources> >><resource asof="20020913" href="/Portfolio/20020913"/> >><resource asof="20020914" href="/Portfolio/20020914"/> >><resource asof="20020914" href="/Portfolio/20020915"/> >><resource asof="20020914" href="/Portfolio/20020916"/> >></resources> >> > Wouldn't the client need to know as much information to /deconstruct/ the > data as it would to /construct/ the URIs? Both have 'asof' as a nifty name, > and both have '20020914',etc as the syntax and value space for that name. There are two reasons I think not. First, there are some clients that don't care about the meaning of asof and will just blindly chase down all of the links. Great: we've enabled a different kind of application to do something useful. Whereas constructing URIs requires the knowledge that you shouldn't try to construct URIs into the future or the distant past. Second, I think that between the client that understands none of the semantics except hyperlinking (e.g. Google) and the client that understands everything there can be clients that use semantic technologies to understand *some things*. For instance maybe I don't know what a portfolio is but I know what a "date-versioned document" is and I know how to retreive and organize "date-versioned documents". It's pretty easy in the semweb technologies to define the type "data-versioned document" and subtype it to get to "date-versioned portfolio." I don't know how to do that with query construction technologies. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > There are two reasons I think not. First, there are some clients that > don't care about the meaning of asof and will just blindly chase down > all of the links. Great: we've enabled a different kind of application > to do something useful. But I don't get paid to deliver a different kind of application. (Okay... right now I don't get paid at all...) Explicit links are fine - and they do have the nice property of opaque/low-intelligence retrievals. But for the main use-case of getting a particular portfolio, the client still needs to know which link is the right link. And that requires knowing (in your example) the name 'asof' and the value '20020914'. The client pops these two data items into a function and out pops a URI. Either algorithmically constructed or retrieved via a lookup - not much difference, except that transferring lookup tables isn't all that scalable and doesn't reduce coupling. > Whereas constructing URIs requires the knowledge > that you shouldn't try to construct URIs into the future or the distant > past. That is a 'nice-to-have' not a 'need-to-have'. > > Second, I think that between the client that understands none of the > semantics except hyperlinking (e.g. Google) and the client that > understands everything there can be clients that use semantic > technologies to understand *some things*. For instance maybe I don't > know what a portfolio is but I know what a "date-versioned document" is > and I know how to retreive and organize "date-versioned documents". How would the client "know how to retrieve 'date-versioned documents'"? Isn't that what we are talking about? > It's pretty easy in the semweb technologies to define the type > "data-versioned document" and subtype it to get to "date-versioned > portfolio." I don't know how to do that with query construction > technologies. Knowing the type/meaning is not the same as knowing how to retrieve the information. The 'query contruction technologies' is the 'how to retrieve' part. The semweb technologies you mentioned don't talk about it. You just essentially said 'assume I know how to retrieve one'...
Walden, The way I usually solve this problem is to do as paul says except: - Use the HTTP 302 Found status code to redirect the client. In other words, the client queries the portfolio resource by saying GET /Portfolio/?asof=2343232 and the server responds with HTTP 302 Found and in the Location header put the URL of the resource. If you have multiple resources that might be returned then do the same thing with the vanillar 200 OK. - itdp --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > Mathews, Walden wrote: > > Paul, > > > > In your "first principles" posting of last Friday, there was > > an interesting bit on queries and how the client can, by following > > instructions from the server, participate in the composition of > > query-extended URI. > > > > I want to ask a general question about how this should work, independent > > of HTML and current browser technology, where I understand its > > working well enough. > > > > Making no assumptions about the format of the entities, what can > > be said about a standard for providing (server) and following (client) > > instructions for extending URI with query parameters? > > WSDL and WRDL both have facilities to allow this. > > > Here's my real-life example from a current project. A Portfolio > > resource (let's say it's at URI: "/Portfolio") undergoes changes, but > > can be retrieved via "as of" snapshots. The client does not care > > exactly when the Portfolio changed; it only needs to know "what was > > my Portfolio as-of 2002-09-16 end-of-business?". The server may > > choose to impose the convention of appending a simple yyyymmdd > > encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916". > > How does it encode instructions for the client to do this in some > > standard way, barring HTML as a specific solution? Does Xforms > > address this problem? > > Yes, XForms supports query construction. WSDL and WRDL are design- time > standards. XForms is a runtime standard. So it depends on which you > want. But if you are doing it at runtime, then consider using a > hyperlink instead. It requires less client-side knowledge to navigate a > hyperlink. > > > Would there be any particular reason to prefer > > "/Portfolio?asof=20020916" or some other encoding over the one > > above? > > There are two resources: > > /Portfolio > /Portfolio/20020916 > > Common wisdom (Jeff Bone would say "dogma") in the Web architecture > world is that the client should not construct the URI for latter from > the former. Basically if you tell the client to do that, then you are > committing to that exact naming scheme forever. For instance someone > could make a hyperlink today to a document that will come into existence > in 2003. On the other hand, if you put in a level of indirection between > the resources then the client is told that you reserve the right to > change your naming convention any time. Here's how you do that: > > --> > GET /Portfolio?asof=20020916 > > <-- > 200 OK > <resource asof="20020916" href="/Portfolio/20020916"/> > > Then client applications dereference through that query to get at the > concrete resource associated with a particular date. The query language > could be arbitrarily complex. As in: > > --> > GET /Portfolio?from=20020913;to=20020918 > > <-- > 200 OK > <resources> > <resource asof="20020913" href="/Portfolio/20020913"/> > <resource asof="20020914" href="/Portfolio/20020914"/> > <resource asof="20020914" href="/Portfolio/20020915"/> > <resource asof="20020914" href="/Portfolio/20020916"/> > </resources> > > Admittedly the indirection has costs. But essentially your "contract" is > now only to maintain the indirection service, not to keep the same URI > naming scheme forever. Your successor might appreciate the freedom. The > same might go for anyone implementing duplicates of your service > elsewhere in the world. Maybe they want to serve portfolio snapshots > through ftp: or from a seperate server @.... > > That said, you can achieve a similar effect using redirect status codes. > I think that the difference is in the contract you are signing up for. > > Paul Prescod
S. Mike Dierken wrote: >... > > But I don't get paid to deliver a different kind of application. (Okay... > right now I don't get paid at all...) > Explicit links are fine - and they do have the nice property of > opaque/low-intelligence retrievals. To me, one of the central goals of REST is to allow new applications to be created later that I didn't foresee in the beginning. That's a big part of my definition of "loose coupling". > But for the main use-case of getting a particular portfolio, the client > still needs to know which link is the right link. And that requires knowing > (in your example) the name 'asof' and the value '20020914'. Yes, in the most tightly bound scenario where the client knows everything interesting about the server and is specifically coded to work with that particular type of server and its datatyhpes, there is no difference. But then in that case I could also just as easily use SOAP, CORBA or ASN.1. It's allowing the other applications that is of interest to me and where I think REST can contribute. > .... The client pops > these two data items into a function and out pops a URI. Either > algorithmically constructed or retrieved via a lookup - not much difference, > except that transferring lookup tables isn't all that scalable and doesn't > reduce coupling. Obviously I disagree on the latter point. >>Whereas constructing URIs requires the knowledge >>that you shouldn't try to construct URIs into the future or the distant >>past. > > That is a 'nice-to-have' not a 'need-to-have'. If it prevents your client from hanging indefinately, it is a "need-to-have". Basically the list version gives the client more information than the query version. It says not only "you can try to get data at this URI" but also: "Here are URIs that are guaranteed to work and URIs that you don't see here are likely not to work." My philosophy is for the server to always give as much extra information to the client as is reasonably possible. To me that loosens binding. >... > How would the client "know how to retrieve 'date-versioned documents'"? > Isn't that what we are talking about? No, we're talking about specifically date-versioned portfolios not the more generic concept of date-versioned resources. I'm trying to introduce the notion of subtyping. Subtyping on the Web is well-defined for graphs of links, but not for queries (though that is perhaps doable -- nobody has thought it through). >... > > Knowing the type/meaning is not the same as knowing how to retrieve the > information. The 'query contruction technologies' is the 'how to retrieve' > part. The semweb technologies you mentioned don't talk about it. You just > essentially said 'assume I know how to retrieve one'... Basically you see a URI, you invoke GET. The question is how do I filter to certain dates. I already pretty much know how to do that right now using the N3 implementation CWM (presuming the data is somehow interperable as RDF). Of course saving the documents to the local hard disk is a side-effect that is outside the scope of N3. But anyhow, the part I could do in N3 is: "Start with this URI which is a list of 'date-versioned resources'. By definition each one has a date. Get the ones that are less than 5 days old (some hand waving around date functions here...). Then dereference each of them and parse them as RDF. Then look for a 'VersionType' property and return me the set where the 'VersionType' is "Major", not "Minor".' Although it sounds like I am telling it the order of operations of course I wouldn't really. It could do a depth-first search for relevant data or get them all and then filter, based on its own best judgement. The N3 "query" will automatically work with any subtype of "date-versioned-resource" including "date-versioned purchase order" or "date-versioned home page" or "date-versioned portfolio." It will also work with any resource that N3 knows how to interpret *as* a date-versioned resource using some inferencing rules that may rename or compute properties. As in object oriented programming, subtyping is usually only valuable in the long run, not for the very first project you apply it to. It's when you end up with many subtypes of the same thing that you get economies of scale. Paul Prescod
Mathews, Walden wrote: >... > What if the client is following a set of (dynamic) instructions > from the server on how to construct such a URL? If the naming > scheme changes, then so does the instructions. Then you have to rename all of your old resources to follow the scheme, right? My point is that the naming convention for your new resources should not be constrained by history nor vice versa. And anyhow, except for web browsers, most web app client software is not really written to discover parameters at runtime. >... > Okay, I get the indirection bit, but along the way I wondered > how the client knew how to do that GET. Did I tell her how to > format that? Yes, using something like WSDL or WRDL or XForms. In retrospect I was wrong to say that XForms MUST be used at runtime. There's no reason it isn't also useful at design time. I'll have to think about this aspect of XForms more... >... > Hmmm. I think you're still assuming that there is a finite > number of these resources and that given the right question, > the server can dish up a finite set of references for getting > at them. Time ain't like that. Surely your app is not interested in all of eternity. There are a finite number of changes that happen. > While asking the original question, I realized that a better > application design on the server side keeps a versioning history > and so could offer a list of versions as you have above. > Unfortunately, the legacy app hiding behind my web service > wasn't that smart. 8-( It must have a version history internally or how can it answer the question of "what was the value on this date?" But if you say that the version history is externally unavailable then I believe you. That's too bad: it constrains your design. Anyhow, it doesn't change the point about how to deine query interfaces. If you want to adhere closely to Web architecture, you should do some kind of indirect/redirect through the query so that the resource relationships are not name-based. It might be a valid engineering choice to short-circuit the query-redirect for simplicity or performance reasons. If so, I'd suggest still to use query params rather than slashes for compatibility with today's Web and with languages like HTML, WRDL and XForms. Paul Prescod
----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> > But for the main use-case of getting a particular portfolio, the client
> > still needs to know which link is the right link. And that requires
> knowing
> > (in your example) the name 'asof' and the value '20020914'.
>
> Yes, in the most tightly bound scenario where the client knows
> everything interesting about the server and is specifically coded to
> work with that particular type of server and its datatyhpes, there is no
> difference.
Nobody but you said the client knows everything interesting about the
server.
All I'm pointing out is that the client needs to know the same amount of
information in both approaches.
A client that generates a URI via an algorithm knows only as much as a
date-versioned aware client.
Since the algorithmic approach has no innate bounds (in this example) you
may want to surface them and make them explicit - but that is not my point
and I don't care one way or the other at this time. The lookup based
approach has no need for this, but it also does not provide or have access
to that semantic information (of the allowable/exising bounds) either.
> But then in that case I could also just as easily use SOAP,
> CORBA or ASN.1. It's allowing the other applications that is of interest
> to me and where I think REST can contribute.
>
> > .... The client pops
> > these two data items into a function and out pops a URI. Either
> > algorithmically constructed or retrieved via a lookup - not much
> difference,
> > except that transferring lookup tables isn't all that scalable and
> doesn't
> > reduce coupling.
>
> Obviously I disagree on the latter point.
If both approaches have a dependency on exactly the same information then
the coupling is exactly the same.
>
> >>Whereas constructing URIs requires the knowledge
> >>that you shouldn't try to construct URIs into the future or the distant
> >>past.
> >
> > That is a 'nice-to-have' not a 'need-to-have'.
>
> If it prevents your client from hanging indefinately, it is a
> "need-to-have".
If the resources have nearly infinite granularity then the lookup table will
hang the client and avoiding a hyperlinking approach is also required.
Looks like we are stuck. Can't get there from here.
> Basically the list version gives the client more
> information than the query version. It says not only "you can try to get
> data at this URI" but also: "Here are URIs that are guaranteed to work
> and URIs that you don't see here are likely not to work."
A list does not say the second part. If it did, then the list would have to
be a full and not partial list. Which isn't scalable in my opinion - very
large data sets would choke even the copious bandwidth we have today.
> My philosophy
> is for the server to always give as much extra information to the client
> as is reasonably possible. To me that loosens binding.
Earlier you said that the algorithmic approach would need to know the
constraints (boundary, past/future, etc.) Since this is extra information
that is provided to the client, isn't this an example of what you consider
'loosened coupling'?
>
> >...
> > How would the client "know how to retrieve 'date-versioned documents'"?
> > Isn't that what we are talking about?
>
> No, we're talking about specifically date-versioned portfolios not the
> more generic concept of date-versioned resources. I'm trying to
> introduce the notion of subtyping. Subtyping on the Web is well-defined
> for graphs of links, but not for queries (though that is perhaps doable
> -- nobody has thought it through).
>
> >...
> >
> > Knowing the type/meaning is not the same as knowing how to retrieve the
> > information. The 'query contruction technologies' is the 'how to
> retrieve'
> > part. The semweb technologies you mentioned don't talk about it. You
just
> > essentially said 'assume I know how to retrieve one'...
>
> Basically you see a URI, you invoke GET. The question is how do I filter
> to certain dates. I already pretty much know how to do that right now
> using the N3 implementation CWM (presuming the data is somehow
> interperable as RDF). Of course saving the documents to the local hard
> disk is a side-effect that is outside the scope of N3.
Sorry... too many acronyms. Can you provide an example?
Sounds like you are advocating retrieving a (possibly very large) lookup
table and doing local queries. The 'filter to certain dates' is an operation
upon that local data - and that filter would need the same input data as a
client-composed URI (namely 'asof' and the date
syntax/value-space/meaning/whatever).
>
> But anyhow, the part I could do in N3 is: "Start with this URI which is
> a list of 'date-versioned resources'. By definition each one has a date.
> Get the ones that are less than 5 days old (some hand waving around date
> functions here...).
I think I'm beginning to glimpse what you are getting at. The same
information ('asof' and dates) is used to crawl local content (retrieved
from a generic uri), rather than to directly address a remote resource... is
that correct?
> Then dereference each of them and parse them as RDF.
> Then look for a 'VersionType' property and return me the set where the
> 'VersionType' is "Major", not "Minor".'
>
> Although it sounds like I am telling it the order of operations of
> course I wouldn't really. It could do a depth-first search for relevant
> data or get them all and then filter, based on its own best judgement.
>
> The N3 "query" will automatically work with any subtype of
> "date-versioned-resource" including "date-versioned purchase order" or
> "date-versioned home page" or "date-versioned portfolio." It will also
> work with any resource that N3 knows how to interpret *as* a
> date-versioned resource using some inferencing rules that may rename or
> compute properties.
Queries (which is a form of addressing) performed upon local content
content, rather than queries turned into addresses and remote content
accessed directly.
>
> As in object oriented programming, subtyping is usually only valuable in
> the long run, not for the very first project you apply it to. It's when
> you end up with many subtypes of the same thing that you get economies
> of scale.
The same re-application probably would not work with composed URIs out of
the box. But if you've got content-manipulation approaches (arch forms, name
mapping, etc.) executed on the client, then I supposed that same slot could
be filled with mappings of the declarative rules for generating URIs also.
----- Original Message ----- From: "Paul Prescod" <paul@...> > > Anyhow, it doesn't change the point about how to deine query interfaces. > If you want to adhere closely to Web architecture, you should do some > kind of indirect/redirect through the query so that the resource > relationships are not name-based. Does this mean converting query based URIs into path-based URI? If URI are opaque, what does it matter?
Just some thoughts on PUT/POST and query strings Seairth mentioned the baggage of FTP in the HTTP RFC. I tend to agree that PUT looks suspiciously to me like PUT <file>. Harkening back to FTP, a server administrator can easily set up an area (let's call it /incoming/) where users can dump files without security clearance. If one user PUTs a file called "my_worm.exe", there is nothing stopping another user PUTting a different file with exactly the same name, overwriting the first. The FTP server will not complain, because it's a non-privileged area. PUT is idempotent in this case: great. Point 1: I can't see how this can work on an HTTP server. You need to set up that non-privileged area to protect /your/ documents from being overwritten. If you are setting up a non-privileged area, that implies that all of your other areas a privileged, which is almost never the case. PUT (in this simple and I believe originally intended FTP sense) in this instance creates a really massive overhead of creating authentication schemes for everywhere but some public space. You don't have any of your own processors working behind the scenes here, so you've got to rely on your server software's authentication schemes, which may or may not allow you to restrict a PUT operation while allowing GETs (couldn't find such a thing with Apache, for instance) on any particular area. Point 2: Then again, GET on its own isn't particularly useful for Web services until you start adding query strings onto the end of it. If PUT is in some senses the 'reverse' operation of GET, why haven't I seen anyone mention the possibility of PUT http://www.server.org/processor?name=Babs+Jensen&phone=88889999 HTTP/1.1 Doesn't this make PUT an idempotent operation? When I do GET http://www.server.org/processor?name=Babs+Jensen&phone=88889999 HTTP/1.1 I should get 200 OK name=Babs Jensen phone=88889999 If I am to expect PUT/GET symmetry as Paul would have it. Though I don't think he would disagree with making GET http://www.server.org/processor?name=Babs+Jensen HTTP/1.1 200 OK name=Babs Jensen phone=88889999 also available, as a different representation of the state of Babs (because the first GET isn't particularly useful to me as a client). Incidentally, I should expect that POST in this situation: POST http://www.server.org/processor HTTP/1.1 Content-type: text/plain Content-length: 30 name=Babs Jensen phone=88889999 Would result in subsequest GETs producing 200 OK name=Babs Jensen phone=88889999 name=Babs Jensen phone=88889999 or something of the sort, as it's not idempotent. The crux: To take yourself beyond the capabilities of your vanilla web server installation, you need URIs with the query string for GETs and PUTs. Furthermore, the presence of "?" in your URI implies the use of extra processing that will require discovery for usage. POST always implies the presence of such a processor. I can see why PUT hasn't really caught on, considering the security problems it seems to present. But by using the query string with PUT, I believe I have solved my problem of non-privileged areas: now the Web server can trivially identify the difference between copying a file (generally a no-no without explicitly saying its OK) and passing some parameters to an add-on processor (which should know what it's doing). Of course, I can envision one nasty problem with this: the limitation on the length of query strings. It would require that your processor would never allow its parameter name-value pairs to exceed that limit, although this may encourage more modular designs. Is this a useful way of looking at it? Can I also not use a 201 Created response for PUT <file> and a 205 Reset Content for PUT <processor with query string>? (OK, so it looks like 205 wasn't really intended for such a thing, but it still implies modification over creation).
----- Original Message ----- From: "firepipe_au" <michael@...> > If PUT is > in some senses the 'reverse' operation of GET, why haven't I seen > anyone mention the possibility of > > PUT http://www.server.org/processor?name=Babs+Jensen&phone=88889999 > HTTP/1.1 > > Doesn't this make PUT an idempotent operation? PUT is already idempotent. Multiple requests result in the same thing as a single request. > When I do > > GET http://www.server.org/processor?name=Babs+Jensen&phone=88889999 > HTTP/1.1 > > I should get > > 200 OK > name=Babs Jensen > phone=88889999 Depends on what was PUT in the first request... was there supposed to be an entity body there? Is there some point to putting the data in query strings rather than in the body? > > If I am to expect PUT/GET symmetry as Paul would have it. Though I > don't think he would disagree with making > > GET http://www.server.org/processor?name=Babs+Jensen HTTP/1.1 > > 200 OK > name=Babs Jensen > phone=88889999 > > also available, as a different representation of the state of Babs > (because the first GET isn't particularly useful to me as a client). > > Incidentally, I should expect that POST in this situation: > > POST http://www.server.org/processor HTTP/1.1 > Content-type: text/plain > Content-length: 30 > > name=Babs Jensen > phone=88889999 > > Would result in subsequest GETs producing > > 200 OK > name=Babs Jensen > phone=88889999 > name=Babs Jensen > phone=88889999 > > or something of the sort, as it's not idempotent. Depends on how the server implements it.
> From: Seairth Jacobs [mailto:seairth@...] > Sent: Saturday, September 14, 2002 9:01 PM > To: rest-discuss > Subject: [rest-discuss] REST without PUT and other things... > > > In a recent post [1], I was asking about performing resource creation with > POST only. My conclusion has been that this is a good thing. > What's more, > as I was falling asleep last night, additional thoughts occurred > to me that > I now feel the need to share with the list. Tell me what you think... > > > I contend that PUT does not fit well with the REST model. First, there is > the issue of resource creation. PUT is allowed to submit a "non-existing" > request-URI as if it did exist. This request-URI has no identity > whatsoever > (not even with the request-entity that will become the new > resource). From > my ever-evolving understanding of REST, allowing the usage of URIs in this > manner is just plain wrong. I absolutely agree with this regardless of > REST. As I recently mentioned [1], I feel that using POST to create all > resources is just as effective and keeps the URI rules simple. IMHO, the URI exists all the time. It just isn't mapped to a particular resource. Keep in mind that *one* usage of HTTP is *authoring* of web sites, and that's where PUT is already heavy usage (through WebDAV/Microsoft Webfolders/IIS/Apache moddav), and I don't see any problem with that (a part from how to handle authoring of varying resources, as recently discussed on the URI mailing list). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>... > > What if the client is following a set of (dynamic) instructions > > from the server on how to construct such a URL? If the naming > > scheme changes, then so does the instructions. > > Then you have to rename all of your old resources to follow > the scheme, > right? My point is that the naming convention for your new resources > should not be constrained by history nor vice versa. And > anyhow, except > for web browsers, most web app client software is not really > written to > discover parameters at runtime. Yes, and it clarifies that part of your "first principles" essay in that instructions for formatting query URI is not enough to keep query stuff extensible. Indirection is needed. Is that a second principle? > > >... > > Okay, I get the indirection bit, but along the way I wondered > > how the client knew how to do that GET. Did I tell her how to > > format that? > > Yes, using something like WSDL or WRDL or XForms. In retrospect I was > wrong to say that XForms MUST be used at runtime. There's no > reason it > isn't also useful at design time. I'll have to think about > this aspect > of XForms more... Here's what I want to happen. Client does GET on /Portfolios/123 and gets back two things (1) default representation (as of now) of portfolio 123 (2) Xforms form for requesting other version of portfolio 123 By filling in a date field in the form and following (or invoking) standard Xforms protocol, a search URI is synthesized according to server sytax rules and a GET performed on that... Sounds reasonable? > >... > > Hmmm. I think you're still assuming that there is a finite > > number of these resources and that given the right question, > > the server can dish up a finite set of references for getting > > at them. Time ain't like that. > > Surely your app is not interested in all of eternity. There > are a finite > number of changes that happen. If you saw this app, you'd understand that it's interested in all of eternity. It's the one I referred to somewhere as choking on its own transaction excreta. But no, it's not interested in a timeline that extends infinitely in both directions, but it is interested in a time segment that has infinitely many moments on it. That's because it maintains big bags of transactions, but no versions, so to find the 'as of' state, it has to go back to genesis and run history forward. This has been a worthwhile exchange for me. I was thinking last week of writing a proposal for "Versioned Portfolio" design enhancement. This adds fuel to the fire. If Portfolio were adequagely versioned, the query stuff would fall away entirely. > It might be a valid engineering choice to short-circuit the > query-redirect for simplicity or performance reasons. If so, > I'd suggest > still to use query params rather than slashes for compatibility with > today's Web and with languages like HTML, WRDL and XForms. OK. Walden
On Mon, Sep 16, 2002 at 01:13:42PM -0400, Sam Hunting wrote: > So my example may or may not be "great", but I'm not sure whether you mean > its lack of greatness lies in being a poor illustration of REST > principles, or whether you think it's just one more bad idea. Can you > elucidate? Thanks. The latter. At least that's my first impression. I *do* believe there's new and useful systems yet to be developed that improve upon REST. But I believe that they will happen primarily as extensions, i.e. with *additional* constraints added, not existing constraints relaxed or removed. I believe that the Web has changed the way we look at all forms of distributed computing, and has done it for all time - at least until something else as disruptive comes along. But that won't be for quite a while, since it itself still has many more years of room for innovation left in it. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
> -----Original Message----- > From: inthedarkplace [mailto:inthedarkplace@...] > Sent: Monday, September 16, 2002 5:56 PM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Re: Client-composed URI > > > Walden, > > The way I usually solve this problem is to do as paul says except: > > - Use the HTTP 302 Found status code to redirect the client. In > other words, the client queries the portfolio resource by saying > GET /Portfolio/?asof=2343232 and the server responds with HTTP 302 > Found and in the Location header put the URL of the resource. If you > have multiple resources that might be returned then do the same > thing with the vanillar 200 OK. > > - itdp Don't you mean "verniller"? And doesn't 302 mean kind of the reverse of what you're using it for here? Thanks, Walden
On Fri, Sep 13, 2002 at 12:35:06PM -0400, Seairth Jacobs wrote: > What/which model are we talking about here? Can someone list a few aspects > of what this model is about? I'm always interested in helping in this sort > of thing, but I am having trouble figuring out what the model is in the > first place. Stuff like the existential details of resources and the relationship to its representations. Then we could take that, and build a set of methods that would be slightly more general than PUT/DELETE (I've said that I believe GET is axiomatic, and likely POST too). PUT/DELETE, as defined in 2616, seem to be optimized for the "web authoring" use case, which while mappable to the kinds of things we talk about doing with REST, have some quirks that make some things awkward. As an example, SOAP can't use PUT because of the assumption of PUT that the body is data-to-be-stored rather than a representation-to-be-set. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
From: "Julian Reschke" <julian.reschke@...>
>
> IMHO,
>
> the URI exists all the time. It just isn't mapped to a particular
resource.
I have a hard time agreeing to this statement. Sure, if you want to get
philosophical about the existence of URIs, one could argue that there is an
infinite number of URIs in existence. But in practice, this view just does
not work (at least for me). To illustrate, think of written language. If
you were to encounter the following word:
vocabulary
you would know what it meant. You recognize this as a word. You can map
the word to its meaning (the resource). In fact, I can give you any word
and you can come up with its meaning because they *all* have mappings to a
meaning.
However, if you were to encounter:
twipperty
what would you say it is? It has no meaning (no mapping to a resource). Is
it a word? Of course not! Will it eventually be a word? Maybe. But that
does not make it a word right now.
In the same way, just because you encounter something that *looks* like a
URI does not mean it's a URI. Does that mean that examples where we see:
http://example.com/
are not URIs? No, these *are* URIs because they are mapped to examples in
the message. Sure, you cannot resolve it with HTTP, but that doesn't make
it any less of a URI. In fact, most of the time we encounter URIs in mail,
news, etc. messages, they *are* URIs because of their conceptual mappings.
But then we get to HTTP. In HTTP, a string that looks like a URI should
never be considered an actual URI until it is mapped to a resource (just as
you would not consider "twipperty" a word until it was mapped to a meaning).
HTTP follows that rule everywhere except in *one* place: PUT. In all other
instances, if a given URI-like string does not map to a resource, the server
returns an error telling you so. But when you use PUT, you can actually
pass a URI-like string that might be accepted and treated like a URI by the
server.
For instance, suppose the following sequence:
GET /twipperty
PUT /twipperty
In the above example, "/twipperty" is a URI-like string, not an actual URI.
As a result, the server returns a 404 (as expected) to the first request and
a 200 (as expected) to the second request. But if PUT was treating
"/twipperty" like an actual URI in the second request, why didn't it treat
it like one in the first request? Simply put, because it wasn't a URI in
the first request. It looked like one, but that didn't automatically make
it one.
Now, I am not trying to argue here that PUT is bad. In light of other
conversations, I am still debating the value of PUT, though I do see what
Paul Prescod, et al. are saying about it. All I am saying here is that I
think it a bad idea to act as if anything that looks like a URI actually
*is* a URI (as is evident from the ever ongoing debates over the XML
Namespace rec). Using PUT to make a non-URI into a URI by treating it as if
it were a URI already just causes confusion.
I much more like the idea of using POST to request that a URI-like string be
made into an actual URI and associated to a resource. PUT can still be used
to update the resource through the URI, but only once the mapping exists
(and therefore the URI exists as well). Actually, as Paul points out, POST
is a bit overloaded here. I wouldn't mind instead a CREATE verb or
something like it that would do what I suggest with the POST. For instance:
-->
CREATE /existingpath
Location: /existingpath/twipperty
<--
201 Created
Location: /existingpath/twipperty
This way, URIs do not exist until they have a mapping. Period.
You can have strings that look like URIs that aren't, but you can also have
strings that look like words that aren't as well. My four year old daughter
has no problem with understanding when something isn't a word. Why should
URIs be any different?
---
Seairth Jacobs
seairth@...
Searth, I really have problems following your argumentation. RFC2616 clearly says that 1) PUT can be applied to existing resources or used to create new resources, 2) POST can only be applied to existing resources (yes, creation of a new resource can be a side effect, but the request resource for OST must exist in the first place), and that 3) 404 means "The server has not found anything matching the Request-URI.". Do you really want to change all this? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
S. Mike Dierken wrote:
>...
> Nobody but you said the client knows everything interesting about the
> server.
> All I'm pointing out is that the client needs to know the same amount of
> information in both approaches.
No. *One kind* of client needs to know the same amount of information in
both approaches. *Other kinds of clients* will be enabled by an approach
that gives more information (like "here's the list of entities
available") rather than less information (like "guess an entity and I'll
tell you if it is available"). The first approach enables things like
Google to exist and the latter prevents them.
>...
> If both approaches have a dependency on exactly the same information then
> the coupling is exactly the same.
But they don't. See above.
>...
> If the resources have nearly infinite granularity then the lookup table will
> hang the client and avoiding a hyperlinking approach is also required.
> Looks like we are stuck. Can't get there from here.
As the question was originally posed, there was per-day granularity.
>...
> A list does not say the second part. If it did, then the list would have to
> be a full and not partial list. Which isn't scalable in my opinion - very
> large data sets would choke even the copious bandwidth we have today.
Paul says:
> Sometimes the information provider has such a large database of
> information that it is not practically (or economically) feasible for it
> to deliver to the requestor in total or even to segment into many
> hypermedia documents. The requestor needs to specify some reasonable
> filter. This is a fallback position because it becomes difficult or
> impossible for the requestor to enumerate all of the information items
> even if this might be useful or important. Nevertheless, reality
> requires that sometimes filtering happen on the server side and the
> Web allows this through HTTP URI "query parameters".
http://groups.yahoo.com/group/rest-discuss/message/2540
> ...
> Earlier you said that the algorithmic approach would need to know the
> constraints (boundary, past/future, etc.) Since this is extra information
> that is provided to the client, isn't this an example of what you consider
> 'loosened coupling'?
Providing extra information at runtime loosens coupling by making the
service more discoverable for clients that were not designed
specifically to work with the data. Providing extra information at
design time makes it easier to use the service but doesn't loosen
coupling. If you have a way of presenting the boundary information at
runtime, in a way that can be handled by a domain-insensitive client
like Google, then sure, throw it in. But I don't really have such a
description language available.
>...
> Sounds like you are advocating retrieving a (possibly very large) lookup
> table and doing local queries.
I think you need to choose between the approach of having the server do
the filtering or having the client doing the filtering based on a
variety of factors including size of data sets and extent to which the
client is under your control. If the data size is reasonable and the
client is NOT under your control then the list-version is strongly
superior to the query version. In other parts of the quadrant you might
want to pair the list version WITH the query version (and let the client
choose the most appropriate for them)
> ... The 'filter to certain dates' is an operation
> upon that local data - and that filter would need the same input data as a
> client-composed URI (namely 'asof' and the date
> syntax/value-space/meaning/whatever).
But
a) the filter allows subtyping and remapping so that can be extended
in a purely declarative way to handle sites that rename their "asof" to
"asofdate". If those sites publish the renaming as RDF, I won't have to
touch my client application to have it work with this new data
representation.
b) the filter knows the complete scope of the information available to
it. That's "extra information" that you don't get when all you can do is
guess and query.
>>But anyhow, the part I could do in N3 is: "Start with this URI which is
>>a list of 'date-versioned resources'. By definition each one has a date.
>>Get the ones that are less than 5 days old (some hand waving around date
>>functions here...).
>
> I think I'm beginning to glimpse what you are getting at. The same
> information ('asof' and dates) is used to crawl local content (retrieved
> from a generic uri), rather than to directly address a remote resource... is
> that correct?
I don't think of it as local versus remote. I think of it as having an
agent filter the information based on declarative expressions (probably
locally, for implementation reasons) versus having a black box with a
predefined query and no way to get information that is not available
through that query (like "how often did this information change"). The
content is not local in the sense that I don't do a big recursive "wget"
before I start applying the filter. Rather I point the filter at a URI
and it gets what it needs and hopefully never bothers to download things
that are obviously NOT what it needs. (which suggests that you want to
carefully consider the design of the index document)
>...
> The same re-application probably would not work with composed URIs out of
> the box. But if you've got content-manipulation approaches (arch forms, name
> mapping, etc.) executed on the client, then I supposed that same slot could
> be filled with mappings of the declarative rules for generating URIs also.
Maybe. Nevertheless, if the resource you provide are enumerable then a
legitimate question for a client application to ask is "how do I
enumerate them." You can't predict whether this will be important to
some client or not. So I advise that if the resources are enumerable and
if you have the development where-with-all, you should expose an
interface that allows enumeration perhaps alongside one that allows
queries as an optimization.
Paul Prescod
From: "Julian Reschke" <julian.reschke@...> > > I really have problems following your argumentation. > > RFC2616 clearly says that > > 1) PUT can be applied to existing resources or used to create new resources, > > 2) POST can only be applied to existing resources (yes, creation of a new > resource can be a side effect, but the request resource for OST must exist > in the first place), and that > > 3) 404 means "The server has not found anything matching the Request-URI.". > > Do you really want to change all this? I am not changing anything (though I wouldn't mind change for the better). I am saying not to use PUT to create mappings between URIs and resources. I think it's perfectly valid to use POST to create a resource. I think it's perfectly valid to treat 404 as "this is not a valid URI." I think it's perfectly valid to use PUT to update a resource using a valid URI (one that already has a mapping to the resource being updated). I just don't think that PUT is consistent with the way the rest of the verbs work when one is attempting to create a mapping with it. That's all. Oh, and taking the view I expressed in the prior post also allows URIs to be thought of more simply (at least for me). --- Seairth Jacobs seairth@...
> From: Seairth Jacobs [mailto:seairth@...] > Sent: Tuesday, September 17, 2002 4:41 PM > To: rest-discuss > Subject: Re: [rest-discuss] Existance of URIs (was Re: REST without PUT > and other things...) > ... > already has a mapping to the resource being updated). I just don't think > that PUT is consistent with the way the rest of the verbs work when one is > attempting to create a mapping with it. That's all. > .. I have trouble seeing how WebDAV is supposed to work if I can't use PUT to create a new resource. I think WebDAV (metadata aside) is a very good example for a REST-ful HTTP extension, it's deployed and it works. How would you do authoring of new resources just with POST? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> From: Mark Baker [mailto:distobj@...] > > It seems there's quite a disconnect between the WebDAV "resource= > representation" view of things, which PUT - and now DELETE - appear to > be intended to support, versus the uniform interface approach of REST. Mark, Sure there is, but you can't lay blame at WebDAV's door; HTTP 1.1 has this view simply because it has this method. In a world where resources are synonymous with documents (or files or records or any entity in computer accessible storage), DELETE makes sense. In a world where resources can reside outside computers and their storage, DELETE doesn't make much sense, at least not until Stephen King writes a story called Web Browser of the Gods. So, as strawman text, appended onto 9.7: The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. **In cases where the resource in question can not sensibly be deleted (for example the resource is in fact a physical object) the origin server should return 501, not implemented (see section 10.5.4).** where 501 is the server error used to indicate it is incapable of performing the request. Creating a new error code for this case is about as useful as dividing the resources in two. Bill de hra -- Propylon www.propylon.com
On Tue, Sep 17, 2002 at 04:00:03PM +0100, Bill de h�ra wrote: > > It seems there's quite a disconnect between the WebDAV "resource= > > representation" view of things, which PUT - and now DELETE - appear to > > > be intended to support, versus the uniform interface approach of REST. > > Mark, > > Sure there is, but you can't lay blame at WebDAV's door; I'm not laying blame. WebDAV had a problem to solve, and it solved it pretty darn well ... modulo "dav:", and PROPFIND. I'm just saying that we could use some HTTP and WebDAV like features that didn't have the builtin resource=representation assumption in them. That doesn't mean that having tools that do make that assumption is bad, though when we have the new tools it might be nice to recast the old stuff in those terms. For example, when we figure out the details of the "SET" method, we can define an extension such that it can be used for doing operations semantically equivalent to PUT. > HTTP 1.1 has > this view simply because it has this method. In a world where resources > are synonymous with documents (or files or records or any entity in > computer accessible storage), DELETE makes sense. In a world where > resources can reside outside computers and their storage, DELETE doesn't > make much sense, at least not until Stephen King writes a story called > Web Browser of the Gods. You can ask to DELETE a person if you want. The issue is, are you allowed? I suggest that 403 is the best response to such a request, rather than 501. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
From: "Julian Reschke" <julian.reschke@...> > > I have trouble seeing how WebDAV is supposed to work if I can't use PUT to > create a new resource. I think WebDAV (metadata aside) is a very good > example for a REST-ful HTTP extension, it's deployed and it works. I do not know enough about WebDAV to argue one way or another on its usage of PUT in this manner. Because existing applications do use PUT in this manner does not change my mind about it. > How would you do authoring of new resources just with POST? POST to the resource's container. There is *always* a container. Of course, the feature that is lost (at the HTTP) level by using POST instead of PUT is the ability to specify what you want the new URI to be once the resource is created. As I have suggested, using the "Location" header would allow the same functionality. However, since Location (as a response header) points to valid URIs, it may be more appropriate to use a different (probably new) header to provide the same functionality. Of course, I would prefer to have a CREATE verb that was responsible for resource creation instead of overloading POST (though this isn't strictly adding any more functionality to POST than already exists). But that isn't going to happen any time soon. :) --- Seairth Jacobs seairth@...
> From: Seairth Jacobs [mailto:seairth@...] > Sent: Tuesday, September 17, 2002 5:31 PM > To: rest-discuss > Subject: Re: [rest-discuss] Existance of URIs > .. > Of course, I would prefer to have a CREATE verb that was responsible for > resource creation instead of overloading POST (though this isn't strictly > adding any more functionality to POST than already exists). But > that isn't > going to happen any time soon. :) I really have trouble following you. How would CREATE be different from what PUT does now? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
From: "Mark Baker" <distobj@...> > > On Tue, Sep 17, 2002 at 04:00:03PM +0100, Bill de h�ra wrote: > > > HTTP 1.1 has > > this view simply because it has this method. In a world where resources > > are synonymous with documents (or files or records or any entity in > > computer accessible storage), DELETE makes sense. In a world where > > resources can reside outside computers and their storage, DELETE doesn't > > make much sense, at least not until Stephen King writes a story called > > Web Browser of the Gods. > > You can ask to DELETE a person if you want. The issue is, are you > allowed? I suggest that 403 is the best response to such a request, > rather than 501. On the other hand, if you were to treat DELETE as a method to invalidate the mapping of a URI to its resource, then this would not be as much an issue. For instance, I have two names I answer to: Seairth and Jake (old college nickname). If I were to DELETE "Jake", I am not deleting myself. All I am doing is invalidating the mapping between "Jake" and myself. If there were people in the world who only knew me as Jake and only knew how to find by by that name, I would effectively be deleted to those people. In reality, I live on as Seairth only. Were it possible to DELETE *all* names I have (Proper name, SSN, Resident @ address, etc.), then I would effectively cease to exist to everyone (since no one was capable of finding me anymore). I think that DELETE can work in all circumstances as only as we change our focus on what we are really deleting. This view should not change the way things work, but it should allow us to understand and accept DELETE in a more universal manner... I think... :) --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Paul Prescod" <paul@...> > Paul says: > > > Sometimes the information provider has such a large database of > > information that it is not practically (or economically) feasible for it > > to deliver to the requestor in total or even to segment into many > > hypermedia documents. The requestor needs to specify some reasonable > > filter. This is a fallback position because it becomes difficult or > > impossible for the requestor to enumerate all of the information items > > even if this might be useful or important. Nevertheless, reality > > requires that sometimes filtering happen on the server side and the > > Web allows this through HTTP URI "query parameters". > > http://groups.yahoo.com/group/rest-discuss/message/2540 Okay, great. So I shouldn't construct a URI using query parameters, unless the data is large and then the workaround is to construct a URI using query parameters. Got it.
>>How would you do authoring of new resources just with POST? > > > POST to the resource's container. There is *always* a container. Of > course, the feature that is lost (at the HTTP) level by using POST instead That's the approach we've taken. It was too hard to design security policies around objects (resources) that didn't exist yet. So instead of using PUT, we chose POST into an existing collection resource. Works great for us. Seth
> > > ... The 'filter to certain dates' is an operation > > upon that local data - and that filter would need the same input data as a > > client-composed URI (namely 'asof' and the date > > syntax/value-space/meaning/whatever). > > But > > a) the filter allows subtyping and remapping so that can be extended > in a purely declarative way to handle sites that rename their "asof" to > "asofdate". If those sites publish the renaming as RDF, I won't have to > touch my client application to have it work with this new data > representation. If the filtering algorithm has access to subtyping and remapping, then a declarative format for creating the URI with query parameters can also have access to the same sort of functionality. The site publishes the renaming and the client doesn't have to be adjusted. > > b) the filter knows the complete scope of the information available to > it. That's "extra information" that you don't get when all you can do is > guess and query. If the data set is reasonably large, it will probably be chunked & so it doesn't know the complete scope of information. That scope is implied and not explicit. Unless the representation of that resource says 'this is a portion of available information and there are more bits here and here'. > >... > > The same re-application probably would not work with composed URIs out of > > the box. But if you've got content-manipulation approaches (arch forms, name > > mapping, etc.) executed on the client, then I supposed that same slot could > > be filled with mappings of the declarative rules for generating URIs also. > > Maybe. Nevertheless, if the resource you provide are enumerable then a > legitimate question for a client application to ask is "how do I > enumerate them." You can't predict whether this will be important to > some client or not. So I advise that if the resources are enumerable and > if you have the development where-with-all, you should expose an > interface that allows enumeration perhaps alongside one that allows > queries as an optimization. Now we're talking... I'm all for discovery via enumeration, but I want to explore what reasonable approaches are when enumeration is not practical.
> No. *One kind* of client needs to know the same amount of information in > both approaches. *Other kinds of clients* will be enabled by an approach > that gives more information (like "here's the list of entities > available") rather than less information (like "guess an entity and I'll > tell you if it is available"). The first approach enables things like > Google to exist and the latter prevents them. But if the first approach /prevents/ the main application from working, it isn't a solution at all.
(note: this may work into the "Formalizing a model" thread)
From: "Julian Reschke" <julian.reschke@...>
>
> I really have trouble following you.
>
> How would CREATE be different from what PUT does now?
I come from a database programming background. Strictly speaking, I started
off with "local" relational database technologies. But over the years I
have broadened my conceptual view of databases to be any group of resources
that are retrievable by an identifier. This could be a key value in a RDBMS
table or an HTTP URL on the web. It's all the same to me...
To me there are four basic operations (verbs) that can occur against a
database:
ADD (e.g. SQL INSERT)
EDIT (e.g. SQL UPDATE)
DELETE (e.g. SQL DELETE)
GET (e.g. SQL SELECT)
Until working with REST, I had still conceptualized the above verbs as doing
physical things to the resources themselves. The identifiers were
second-hand citizens to the data, being nothing more than a convenient way
to access a resource. However, as I begin to understand REST more and more,
I have started seeing these verbs in a different light.
Instead of verbs that act on a resource, I see them as verbs that act on
whatever the identifier is mapped to (which we tend to conceptualize as a
resource). When I say ADD, what I would have been saying in the past (from
my rdbms pov):
Take this data and make a record/resource which is identifiable by it's
key.
Now I would say:
Take the key and map the data to it.
Likewise, EDIT would be the same:
Take the key and update the data that is mapped to it.
DELETE would be:
Take the key and remove the mapping to the data.
GET would be:
Take the key and return the data that is mapped to it.
In RDBMS, these are still perfectly valid statements, if not a bit "oddly
worded". When I turn around and look at URIs and Resources (as discussed on
this list), it still makes perfect sense to use the above verbs. The URI is
the key and the Resource is the data.
If you want to map them to HTTP verbs, you might end up with something like
the following:
ADD -> POST
EDIT -> PUT
DELETE -> DELETE
GET -> GET
Of course, these are not perfect matches. As we know, POST can do more than
just create a new URI<->Resource mapping. We also know that PUT do more
than just an EDIT. At the same time, EDIT in RDBMS systems allows a partial
edit, which PUT does not (put any arguments to this statement in a different
thread, please). DELETE and GET are about the only things that actually work
more or less the same.
So does this mean that the ADD, EDIT, DELETE, GET model is wrong? I don't
think so. I think that the HTTP POST, PUT, DELETE, GET model is ambiguous
and could be improved to adopt the other model. This is where CREATE came
in. In this case, CREATE is identical to ADD. So, suppose we had this
model instead:
ADD -> CREATE
EDIT -> PUT
DELETE -> DELETE
GET -> GET
Now, we are a bit closer. But this leaves out POST. Sort of. POST can be
used for all sorts of things. However, if we were to relax PUTs
course-grained update requirements, POST would not have to be used for that.
Since CREATE is dedicated to the creation of the URI<->Resource mappings,
POST would not have to be used for that either. In the end, POST becomes
nothing more than a generic RPC mechanism. Interestingly, some SQL servers
actually have the same thing: EXEC. When you need to submit data to a
server and there is no visible side effect (i.e. none of the four other
verbs are happening), that's when you use POST.
So, let's add one more verb to the mix:
ADD -> CREATE
EDIT -> PUT
DELETE -> DELETE
GET -> GET
EXEC -> POST
In the end, I see this as a cleaner, less ambiguous set of verbs than the
current HTTP verbs. I am sure you will disagree with me. :) But that's
fine. There are certainly questions that need answering such as how these
new (variations) verbs deal with "safety", "idempotency", caching, etc. But
I would be willing to tackle those issues if I knew that there were others
that saw this as I did (or at least were open to the possibility). :)
---
Seairth Jacobs
seairth@...
S. Mike Dierken wrote: >>No. *One kind* of client needs to know the same amount of information in >>both approaches. *Other kinds of clients* will be enabled by an approach >>that gives more information (like "here's the list of entities >>available") rather than less information (like "guess an entity and I'll >>tell you if it is available"). The first approach enables things like >>Google to exist and the latter prevents them. > > > But if the first approach /prevents/ the main application from working, it > isn't a solution at all. Obviously. As I understood the problem originally (daily snapshots of information resources) a listing would work. As I understand it now, infinitely divisible time-based snapshots, the listing would not work. Paul Prescod
S. Mike Dierken wrote: >... > > If the filtering algorithm has access to subtyping and remapping, then a > declarative format for creating the URI with query parameters can also have > access to the same sort of functionality. The site publishes the renaming > and the client doesn't have to be adjusted. There isn't a filtering algorithm. There is a declarative "filter" like a SQL select statement but expressed in terms of semantic web technologies, resolved through web dereferences and typically executed on the client side. Maybe the semantic web technologies could be extended to support query parameter renaming and subtyping: I don't personally know whether the concept fits naturally into the formalisms underlying the semantic web or not. I only know what exists now. I know how to do property renaming and subtyping. I don't know how to do parameter renaming or even parameter construction -- except as standard string manipulation. >... > If the data set is reasonably large, it will probably be chunked & so it > doesn't know the complete scope of information. That scope is implied and > not explicit. Unless the representation of that resource says 'this is a > portion of available information and there are more bits here and here'. Sounds like a good use for hypertext! > Now we're talking... I'm all for discovery via enumeration, but I want to > explore what reasonable approaches are when enumeration is not practical. Query parameters! Nobody ever said that enumeration is always practical. That's why query parameters exist. Paul Prescod
S. Mike Dierken wrote: > ----- Original Message ----- >... > > > Okay, great. So I shouldn't construct a URI using query parameters, unless > the data is large and then the workaround is to construct a URI using query > parameters. Got it. That's basically my position although someday it might be worth drilling down more into what it means for the data to be large. Arbitrarily large data sets can be broken down into bite-sized fractions but then you get into latency issues (like trying to navigate YahooGroups, 10 messages per page). Plus you can get into situations where the server can answer a question in O(X) time but the client can only answer in O(Y) where Y is greater than X. For instance asking Google to find the intersection "Mike" and "Dierken" is going to be much faster than doing it on the client even if bandwidth and latency were free because Google's indexes are set up that way. Still, given infinte development resources, I think that people out there could make good use of a Google service that listed all words that co-occur with some particular word. Linguists would love it! Also, as a purely theoretical, rather than practical point, I will mention that it is possible to design a hypertext interface even to a nano-second indexed data set. At the top level you could list all milleniums that data is available for. At the level below you could list all centuries. At the level below you could list all decades. And on down to nanoseconds. Ideally you would filter out "uninteresting" time periods where nothing happened. The latency on such a data representation would probably be killer, however. Paul Prescod
Searth, as far as I understand, you don't like the fact that PUThttp maps both to INSERTsql and UPDATEsql. That's a fact of how HTTP is designed. Could you please explain why this is an *actual* problem (besides the fact that we don't have a one-to-one mapping from HTTP verbs to database operations)? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Tuesday, September 17, 2002 7:32 PM > To: rest-discuss > Subject: [rest-discuss] Basic Verbs (was Re: Existance of URIs) > > > (note: this may work into the "Formalizing a model" thread) > > From: "Julian Reschke" <julian.reschke@...> > > > > I really have trouble following you. > > > > How would CREATE be different from what PUT does now? > > I come from a database programming background. Strictly > speaking, I started > off with "local" relational database technologies. But over the years I > have broadened my conceptual view of databases to be any group of > resources > that are retrievable by an identifier. This could be a key value > in a RDBMS > table or an HTTP URL on the web. It's all the same to me... > > To me there are four basic operations (verbs) that can occur against a > database: > > ADD (e.g. SQL INSERT) > EDIT (e.g. SQL UPDATE) > DELETE (e.g. SQL DELETE) > GET (e.g. SQL SELECT) > > Until working with REST, I had still conceptualized the above > verbs as doing > physical things to the resources themselves. The identifiers were > second-hand citizens to the data, being nothing more than a convenient way > to access a resource. However, as I begin to understand REST > more and more, > I have started seeing these verbs in a different light. > > Instead of verbs that act on a resource, I see them as verbs that act on > whatever the identifier is mapped to (which we tend to conceptualize as a > resource). When I say ADD, what I would have been saying in the > past (from > my rdbms pov): > > Take this data and make a record/resource which is > identifiable by it's > key. > > Now I would say: > > Take the key and map the data to it. > > Likewise, EDIT would be the same: > > Take the key and update the data that is mapped to it. > > DELETE would be: > > Take the key and remove the mapping to the data. > > GET would be: > > Take the key and return the data that is mapped to it. > > > In RDBMS, these are still perfectly valid statements, if not a bit "oddly > worded". When I turn around and look at URIs and Resources (as > discussed on > this list), it still makes perfect sense to use the above verbs. > The URI is > the key and the Resource is the data. > > > If you want to map them to HTTP verbs, you might end up with > something like > the following: > > ADD -> POST > EDIT -> PUT > DELETE -> DELETE > GET -> GET > > Of course, these are not perfect matches. As we know, POST can > do more than > just create a new URI<->Resource mapping. We also know that PUT do more > than just an EDIT. At the same time, EDIT in RDBMS systems > allows a partial > edit, which PUT does not (put any arguments to this statement in > a different > thread, please). DELETE and GET are about the only things that > actually work > more or less the same. > > So does this mean that the ADD, EDIT, DELETE, GET model is wrong? I don't > think so. I think that the HTTP POST, PUT, DELETE, GET model is ambiguous > and could be improved to adopt the other model. This is where CREATE came > in. In this case, CREATE is identical to ADD. So, suppose we had this > model instead: > > ADD -> CREATE > EDIT -> PUT > DELETE -> DELETE > GET -> GET > > Now, we are a bit closer. But this leaves out POST. Sort of. > POST can be > used for all sorts of things. However, if we were to relax PUTs > course-grained update requirements, POST would not have to be > used for that. > Since CREATE is dedicated to the creation of the URI<->Resource mappings, > POST would not have to be used for that either. In the end, POST becomes > nothing more than a generic RPC mechanism. Interestingly, some > SQL servers > actually have the same thing: EXEC. When you need to submit data to a > server and there is no visible side effect (i.e. none of the four other > verbs are happening), that's when you use POST. > > So, let's add one more verb to the mix: > > ADD -> CREATE > EDIT -> PUT > DELETE -> DELETE > GET -> GET > EXEC -> POST > > In the end, I see this as a cleaner, less ambiguous set of verbs than the > current HTTP verbs. I am sure you will disagree with me. :) But that's > fine. There are certainly questions that need answering such as how these > new (variations) verbs deal with "safety", "idempotency", > caching, etc. But > I would be willing to tackle those issues if I knew that there were others > that saw this as I did (or at least were open to the possibility). :) > > --- > Seairth Jacobs > seairth@... > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
I've seen just about an equal number of cases while programming applications in which a) the application cares about the existence of an object, but doesn't care whether it existed before or has to be created. For languages with explicit creation, you end up coding like object = find() if (!object) object = new object() ... object.dothings(); b) the application only cares about having a new instance of something, even if an old copy exists with similar or identical values. For languages with implicit creation (HTTP), you end up coding like POST /Container HTTP/1.1 <object>...</object> if response.code != CREATED throw up hands in despair Each has its moments, though. Walden ;-) > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@...] > Sent: Tuesday, September 17, 2002 2:21 PM > To: Seairth Jacobs; rest-discuss > Subject: RE: [rest-discuss] Basic Verbs (was Re: Existance of URIs) > > > Searth, > > as far as I understand, you don't like the fact that PUThttp > maps both to > INSERTsql and UPDATEsql. That's a fact of how HTTP is designed. > > Could you please explain why this is an *actual* problem > (besides the fact > that we don't have a one-to-one mapping from HTTP verbs to database > operations)? > > Julian > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: Seairth Jacobs [mailto:seairth@...] > > Sent: Tuesday, September 17, 2002 7:32 PM > > To: rest-discuss > > Subject: [rest-discuss] Basic Verbs (was Re: Existance of URIs) > > > > > > (note: this may work into the "Formalizing a model" thread) > > > > From: "Julian Reschke" <julian.reschke@...> > > > > > > I really have trouble following you. > > > > > > How would CREATE be different from what PUT does now? > > > > I come from a database programming background. Strictly > > speaking, I started > > off with "local" relational database technologies. But > over the years I > > have broadened my conceptual view of databases to be any group of > > resources > > that are retrievable by an identifier. This could be a key value > > in a RDBMS > > table or an HTTP URL on the web. It's all the same to me... > > > > To me there are four basic operations (verbs) that can > occur against a > > database: > > > > ADD (e.g. SQL INSERT) > > EDIT (e.g. SQL UPDATE) > > DELETE (e.g. SQL DELETE) > > GET (e.g. SQL SELECT) > > > > Until working with REST, I had still conceptualized the above > > verbs as doing > > physical things to the resources themselves. The identifiers were > > second-hand citizens to the data, being nothing more than a > convenient way > > to access a resource. However, as I begin to understand REST > > more and more, > > I have started seeing these verbs in a different light. > > > > Instead of verbs that act on a resource, I see them as > verbs that act on > > whatever the identifier is mapped to (which we tend to > conceptualize as a > > resource). When I say ADD, what I would have been saying in the > > past (from > > my rdbms pov): > > > > Take this data and make a record/resource which is > > identifiable by it's > > key. > > > > Now I would say: > > > > Take the key and map the data to it. > > > > Likewise, EDIT would be the same: > > > > Take the key and update the data that is mapped to it. > > > > DELETE would be: > > > > Take the key and remove the mapping to the data. > > > > GET would be: > > > > Take the key and return the data that is mapped to it. > > > > > > In RDBMS, these are still perfectly valid statements, if > not a bit "oddly > > worded". When I turn around and look at URIs and Resources (as > > discussed on > > this list), it still makes perfect sense to use the above verbs. > > The URI is > > the key and the Resource is the data. > > > > > > If you want to map them to HTTP verbs, you might end up with > > something like > > the following: > > > > ADD -> POST > > EDIT -> PUT > > DELETE -> DELETE > > GET -> GET > > > > Of course, these are not perfect matches. As we know, POST can > > do more than > > just create a new URI<->Resource mapping. We also know > that PUT do more > > than just an EDIT. At the same time, EDIT in RDBMS systems > > allows a partial > > edit, which PUT does not (put any arguments to this statement in > > a different > > thread, please). DELETE and GET are about the only things that > > actually work > > more or less the same. > > > > So does this mean that the ADD, EDIT, DELETE, GET model is > wrong? I don't > > think so. I think that the HTTP POST, PUT, DELETE, GET > model is ambiguous > > and could be improved to adopt the other model. This is > where CREATE came > > in. In this case, CREATE is identical to ADD. So, suppose > we had this > > model instead: > > > > ADD -> CREATE > > EDIT -> PUT > > DELETE -> DELETE > > GET -> GET > > > > Now, we are a bit closer. But this leaves out POST. Sort of. > > POST can be > > used for all sorts of things. However, if we were to relax PUTs > > course-grained update requirements, POST would not have to be > > used for that. > > Since CREATE is dedicated to the creation of the > URI<->Resource mappings, > > POST would not have to be used for that either. In the > end, POST becomes > > nothing more than a generic RPC mechanism. Interestingly, some > > SQL servers > > actually have the same thing: EXEC. When you need to > submit data to a > > server and there is no visible side effect (i.e. none of > the four other > > verbs are happening), that's when you use POST. > > > > So, let's add one more verb to the mix: > > > > ADD -> CREATE > > EDIT -> PUT > > DELETE -> DELETE > > GET -> GET > > EXEC -> POST > > > > In the end, I see this as a cleaner, less ambiguous set of > verbs than the > > current HTTP verbs. I am sure you will disagree with me. > :) But that's > > fine. There are certainly questions that need answering > such as how these > > new (variations) verbs deal with "safety", "idempotency", > > caching, etc. But > > I would be willing to tackle those issues if I knew that > there were others > > that saw this as I did (or at least were open to the > possibility). :) > > > > --- > > Seairth Jacobs > > seairth@... > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
----- Original Message ----- From: "Paul Prescod" <paul@...> > I don't know how to do parameter renaming or even > parameter construction -- except as standard string manipulation. Define the HTTP URI as a grove, create links to portions of this graph (the named query terms), apply a transform that injects input data into the grove, then serialize this into slash and question mark format rather than angle bracket format. A URI is a very compact serialization of a fairly complex data structure.
S. Mike Dierken wrote: > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > >>If you DELETE something twice, you usually expect an error message or a >>core dump. > > Do you mean 'delete' in the classic programming language sense (releasing > system memory, calling destructors, etc.) or do you mean the HTTP concept of > DELETE? The fact that there is potentially a divergence there is exactly my point. It's okay for HTTP to diverge but if the spec doesn't say clearly one way or another, then people will just guess. HTTP says basically "DELETE means you should delete." Roy describes a very mathematical mode for HTTP (resource is a mapping etc.) and if the HTTP methods were described in those terms it would be much easier to build interoperable software. There are hints that it was politics that prevented this from happening the first time around, but what should we do about it now? Just transmit the true meanings of the methods through mailing lists? Increment HTTP? Write an RFC clarifying? Wait for Roy's new protocol? I'm being serious here: I think that there is a problem and a variety of solutions and am soliciting opinions on both issues. Paul Prescod
Paul, If it hasn't already been done, I think it would be useful to at least formalize the possible interpretations of things like DELETE and anything else people find ambiguity in, separate from attempting to make any judgments about which interpretations are good and which are not. I keep threatening to build some Alloy models of parts of HTTP, and I'm getting very close to actually doing that. One thing is that I don't want to do it in isolation, so if you're interested in this approach, I say we just start with some informal language. Unfortunately, the message below is too ambiguous about the ambiguity in DELETE for me to get my teeth in. What do others think about this approach? I think Mark Baker proposed something like this, offering to author some new methods once we had a clear model. Let's do it, unless it's already been done and we'd be duplicating effort. I can pledge a genuine interest and *some* time, but can't commit to any schedule, unfortunately. Walden PS - shall I publish a simple Alloy model to this list tommorow to drive a stake into the ground? > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Wednesday, September 18, 2002 4:31 PM > To: S. Mike Dierken > Cc: Roy T. Fielding; rest-discuss > Subject: [rest-discuss] Re: Resources always exist > > > S. Mike Dierken wrote: > > ----- Original Message ----- > > From: "Paul Prescod" <paul@...> > > > >>If you DELETE something twice, you usually expect an error > message or a > >>core dump. > > > > Do you mean 'delete' in the classic programming language > sense (releasing > > system memory, calling destructors, etc.) or do you mean > the HTTP concept of > > DELETE? > > The fact that there is potentially a divergence there is exactly my > point. It's okay for HTTP to diverge but if the spec doesn't > say clearly > one way or another, then people will just guess. HTTP says basically > "DELETE means you should delete." > > Roy describes a very mathematical mode for HTTP (resource is > a mapping > etc.) and if the HTTP methods were described in those terms > it would be > much easier to build interoperable software. > > There are hints that it was politics that prevented this from > happening > the first time around, but what should we do about it now? > Just transmit > the true meanings of the methods through mailing lists? > Increment HTTP? > Write an RFC clarifying? Wait for Roy's new protocol? I'm > being serious > here: I think that there is a problem and a variety of > solutions and am > soliciting opinions on both issues. > > Paul Prescod > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mathews, Walden wrote, > What do others think about this approach? I think Mark Baker > proposed something like this, offering to author some new > methods once we had a clear model. Let's do it, unless it's > already been done and we'd be duplicating effort. If it has, the results haven't been published anywhere to the best of my knowledge. > I can pledge a genuine interest and *some* time, but can't > commit to any schedule, unfortunately. > > Walden > > PS - shall I publish a simple Alloy model to this list > tommorow to drive a stake into the ground? Please do ... I, for one, would be very interested in taking a look at it. Cheers, Miles
The simple fact is that there is no divergence. DELETE is idempotent and therefore deleting something once or deleting something a thousand times is the same operation. I'm not sure where people got the idea that there's something wrong with deleting something twice because that's never ever been true of HTTP and in fact most systems that expose a delete operation (eg databases, file systems, tuple spaces, g-indexes, maps). Further, there is no logical discontinuity between this behavior and the meaning of a delete request. I'm not sure why some people want to make this more complicated than it is, but I think it's clear to the majority. - itdp --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote: > S. Mike Dierken wrote: > > ----- Original Message ----- > > From: "Paul Prescod" <paul@p...> > > > >>If you DELETE something twice, you usually expect an error message or a > >>core dump. > > > > Do you mean 'delete' in the classic programming language sense (releasing > > system memory, calling destructors, etc.) or do you mean the HTTP concept of > > DELETE? > > The fact that there is potentially a divergence there is exactly my > point. It's okay for HTTP to diverge but if the spec doesn't say clearly > one way or another, then people will just guess. HTTP says basically > "DELETE means you should delete." > > Roy describes a very mathematical mode for HTTP (resource is a mapping > etc.) and if the HTTP methods were described in those terms it would be > much easier to build interoperable software. > > There are hints that it was politics that prevented this from happening > the first time around, but what should we do about it now? Just transmit > the true meanings of the methods through mailing lists? Increment HTTP? > Write an RFC clarifying? Wait for Roy's new protocol? I'm being serious > here: I think that there is a problem and a variety of solutions and am > soliciting opinions on both issues. > > Paul Prescod
inthedarkplace wrote, > I'm not sure where people got the idea that there's something wrong > with deleting something twice because that's never ever been true of > HTTP and in fact most systems that expose a delete operation (eg > databases, file systems, tuple spaces, g-indexes, maps). I think a lot turns on what's meant by "something wrong with". To take one of your examples, files systems, $ touch foo $ rm foo $ rm foo rm: cannot remove `foo': No such file or directory $ There's nothing "wrong" with this behaviour. rm is idempotent, but, nb., from the point of view of the effect on the filesystem, *not* from the point of view of the response displayed to the invoker, * WRT the filesystem, the effect of n+1 rm's is the same as the effect of n. * WRT the response displayed to the invoker, the effect of the first rm is different from the second and subsequent rm's. The gist of my earlier postings is that I believe that RFC 2616 equivocates between a view of idempotence, similar to the one above, defined soley in terms of effects on servers/resources, and one that appeals to sameness of results as seen by the client. It's this equivocation which I think is wrong, not idempotent DELETEs. Cheers, Miles
What is the true meaning of "idempotent", both in terms of HTTP and in terms
of REST? Roy Fielding does not mention idempotency in his dissertation, but
it certainly appears to be an integral part of our discussions on REST.
To start, RFC2616 [1:9.1.2] says:
Methods can also have the property of "idempotence"
in that (aside from error or expiration issues) the
side-effects of N > 0 identical requests is the same
as for a single request. The methods GET, HEAD, PUT
and DELETE share this property. Also, the methods
OPTIONS and TRACE SHOULD NOT have side effects, and
so are inherently idempotent.
Generally, I don't think we dispute the above description in terms of what
happens to a resource on a server. However, where we seem to disagree
(mostly due to ambiguity, I think), is just how far the concept of
idempotency reaches. For instance, is an operation idempotent if it returns
different responses? When we speak of responses, are we talking about only
the response entity, the metadata, or both? Since "error or expiration
issues" are explicitly noted as exceptions, what does idempotency mean in
those circumstances? What is the definition of "side-effect"?
I do not have an answer for this, but I do have some thoughts (and
opinions)...
First, let's define what "side-effect" means. I prefer the term "mutation"
here, since "side-effect" implies something that occurs indirectly to the
actual action taken. However, no one here would consider updating a
resource with a PUT as a side-effect. So, the first thing we can say about
a side-effect (in terms of the HTTP spec) is that we are speaking of the
changing of a resource. That's it. Nothing more. It could be direct or
indirect. Doesn't matter. The second thing we can say about a side-effect
(again, in terms of HTTP) is that we are speaking of the end result of the
changing of a resource, not the process itself. In other words, we only see
a side-effect in terms of what state the resource is in after the change.
Next, let's start applying some scope to these terms (where possible). To
start, let's say that side-effects are scoped to the resource on the server.
The client is never directly aware of side-effect. Next, let's also say
that an idempotent method is scoped to the resource on the server as well.
This makes sense since idempotency depends on side-effects.
Now, we get to the part where the ambiguity creeps in...
When one uses an idempotent method which causes a side-effect (PUT, DELETE),
the server returns a response just like any other request method. The
response contains two parts: the headers (metadata) and the entity-body
(which can be null). Recently, we have discussed whether returning
different responses when issuing repeated DELETEs violates idempotency or
not. One camp says that the response should reflect the results of the
request (i.e. 200 for first response, 404 afterwards). This attitude would
imply that the response does not have anything to do with whether the
request was idempotent or not. The other camp says that the response should
reflect the end state of the request (i.e. 200 for all responses). This
attitude would imply that the response is as much a part of the idempotency
requirements as the request is. What this comes down to is whether we
consider any part of the response to be within the scope of HTTP's
definition of idempotency.
My feeling is that the response has nothing to do with idempotency at all.
This comes from the use of GET. GET is an idempotent operation that has no
side-effect. As a result, I could issue the same GET several times, and the
server could return different responses for each of the requests. For
instance, in some of the responses, I could get back a 200, but have
different entity bodies (common for dynamic content). I could also get back
different response codes, such as 200 (OK), then 301 (Moved Permanently),
then 404 (Not Found). Despite these different responses, each of the GETs
is still considered to be idempotent.
Now, let's move on to PUT. When PUT is used, and the resource did not
exist, then a 201 (Created) response is expected. Subsequent PUTs to the
same resource return 200 (OK) responses. This is very common practice and I
have never heard a single person say this is not idempotent.
So, now we move on to DELETE. In this case, let's say that the first DELETE
will return a 200 response and subsequent DELETEs return a 404 response.
>From the definition and scoping of "side-effect" above, we all agree that
the state of the resource after each delete is that it does not exist. This
is enough to also satisfy DELETE's requirement of idempotency. Further,
this is no different than returning two responses for repeated PUTs.
In the end, my personal conclusion is that responses have nothing to do with
idempotency. Idempotency is only limited to the resource on the server.
Regardless of what is returned to the client, the operation on the server is
idempotent (assuming that the end state is the same after repeated identical
requests).
So what does this mean for returning responses from DELETE? I think that
200 (OK) or 202 (Accepted) or 204 (No Content), followed by 404 (Not Found)
or 410 (Gone) and maybe 303 (See Other) would be no different than expected
of other idempotent methods like PUT and GET.
If I had to suggest an order of usage, I'd say (in order of most expressive
to least expressive):
First request:
204 (No Content)
202 (Accepted)
200 (OK)
Repeated requests:
303 (See Other)
410 (Gone)
404 (Not Found)
Should we allow repeated DELETE requests to always get back a "200" (or
similar) response? PUT (DELETE's binary opposite) doesn't allow it. GET,
while possible to receive the same response over and over again, must also
be open to receiving other responses as well. So, why should DELETE be any
different? My thought here is that it would be wrong (given the way the
other two verbs work) to return the same response code regardless of whether
the resource was deleted or not.
<note>I think that's it. Sorry if it seemed to ramble on. I stopped
somewhere in the middle to watch The Daily Show (comedy central) and when
they showed the clip of Bush totally screwing up a simple quote, I just lost
all concentration (funny stuff, it was). Again, sorry if it all seems
incoherent. :) *giggle* </note>
[1] http://www.ietf.org/rfc/rfc2616.txt
---
Seairth Jacobs
seairth@...
Seairth Jacobs wrote, > In the end, my personal conclusion is that responses have nothing to > do with idempotency. Idempotency is only limited to the resource on > the server. Regardless of what is returned to the client, the > operation on the server is idempotent (assuming that the end state is > the same after repeated identical requests). This would also be my conclusion, but for one thing. If we take this interpretation of idempotence, then RFC 2616's discussion of non-idempotent sequences of idempotent methods makes no sense at all, because on this interpretation *all* sequences of idempotent methods are idempotent sequences: see the proof I gave earlier ... which I'm confident that Walden's model, if he puts it together, will verify. Cheers, Miles
> -----Original Message----- > From: inthedarkplace [mailto:inthedarkplace@...] > Sent: Wednesday, September 18, 2002 5:40 PM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Re: Resources always exist > > > The simple fact is that there is no divergence. DELETE is idempotent > and therefore deleting something once or deleting something a > thousand times is the same operation. I'm not sure where people got > the idea that there's something wrong with deleting something twice > because that's never ever been true of HTTP and in fact most systems > that expose a delete operation (eg databases, file systems, tuple > spaces, g-indexes, maps). Further, there is no logical discontinuity > between this behavior and the meaning of a delete request. I'm not > sure why some people want to make this more complicated than it is, > but I think it's clear to the majority. > > > - itdp I don't want to play any part in complicating things that are obvious. Still, that doesn't rule out modelling simple things about HTTP, because the simpler models serve as the foundation for exploring some of the more complex and controversial issues. And also for reasoning correctly about extensions. Walden
Seairth, I think I agree with you that because of the specific language of the spec, "side effects" means effects that are not directly either a request or a response, which includes all state changes in resources. Which is a little wierd when you consider that the raison d'etre of the protocol is to 'transfer' state, as much to change it as to discover it. Hence idempotence, which as discussed earlier on this list is a property of functions (constrained relations), refers to the function whose domain is a resource's pre-state and whose range is the same resource's post-state, where pre- and post- states are relative to a single HTTP method invocation. That seems clear to me -- modulo Roy's counterclaim about idempotent sequences. Still, the question arises: Should a client be able (guaranteed by contract) to discover the mapped or unmapped pre-state of a resource by invoking DELETE? Some applications may care, and so we need to know if that contract was intended by 2616 or not. Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Thursday, September 19, 2002 12:34 AM > To: rest-discuss > Subject: [rest-discuss] True meaning of "Idempotent"? > > > What is the true meaning of "idempotent", both in terms of > HTTP and in terms > of REST? Roy Fielding does not mention idempotency in his > dissertation, but > it certainly appears to be an integral part of our > discussions on REST. > > To start, RFC2616 [1:9.1.2] says: > > Methods can also have the property of "idempotence" > in that (aside from error or expiration issues) the > side-effects of N > 0 identical requests is the same > as for a single request. The methods GET, HEAD, PUT > and DELETE share this property. Also, the methods > OPTIONS and TRACE SHOULD NOT have side effects, and > so are inherently idempotent. > > Generally, I don't think we dispute the above description in > terms of what > happens to a resource on a server. However, where we seem to disagree > (mostly due to ambiguity, I think), is just how far the concept of > idempotency reaches. For instance, is an operation > idempotent if it returns > different responses? When we speak of responses, are we > talking about only > the response entity, the metadata, or both? Since "error or > expiration > issues" are explicitly noted as exceptions, what does > idempotency mean in > those circumstances? What is the definition of "side-effect"? > > I do not have an answer for this, but I do have some thoughts (and > opinions)... > > First, let's define what "side-effect" means. I prefer the > term "mutation" > here, since "side-effect" implies something that occurs > indirectly to the > actual action taken. However, no one here would consider updating a > resource with a PUT as a side-effect. So, the first thing we > can say about > a side-effect (in terms of the HTTP spec) is that we are > speaking of the > changing of a resource. That's it. Nothing more. It could > be direct or > indirect. Doesn't matter. The second thing we can say about > a side-effect > (again, in terms of HTTP) is that we are speaking of the end > result of the > changing of a resource, not the process itself. In other > words, we only see > a side-effect in terms of what state the resource is in after > the change. > > Next, let's start applying some scope to these terms (where > possible). To > start, let's say that side-effects are scoped to the resource > on the server. > The client is never directly aware of side-effect. Next, > let's also say > that an idempotent method is scoped to the resource on the > server as well. > This makes sense since idempotency depends on side-effects. > > Now, we get to the part where the ambiguity creeps in... > > When one uses an idempotent method which causes a side-effect > (PUT, DELETE), > the server returns a response just like any other request method. The > response contains two parts: the headers (metadata) and the > entity-body > (which can be null). Recently, we have discussed whether returning > different responses when issuing repeated DELETEs violates > idempotency or > not. One camp says that the response should reflect the > results of the > request (i.e. 200 for first response, 404 afterwards). This > attitude would > imply that the response does not have anything to do with whether the > request was idempotent or not. The other camp says that the > response should > reflect the end state of the request (i.e. 200 for all > responses). This > attitude would imply that the response is as much a part of > the idempotency > requirements as the request is. What this comes down to is whether we > consider any part of the response to be within the scope of HTTP's > definition of idempotency. > > My feeling is that the response has nothing to do with > idempotency at all. > This comes from the use of GET. GET is an idempotent > operation that has no > side-effect. As a result, I could issue the same GET several > times, and the > server could return different responses for each of the requests. For > instance, in some of the responses, I could get back a 200, but have > different entity bodies (common for dynamic content). I > could also get back > different response codes, such as 200 (OK), then 301 (Moved > Permanently), > then 404 (Not Found). Despite these different responses, > each of the GETs > is still considered to be idempotent. > > Now, let's move on to PUT. When PUT is used, and the resource did not > exist, then a 201 (Created) response is expected. Subsequent > PUTs to the > same resource return 200 (OK) responses. This is very common > practice and I > have never heard a single person say this is not idempotent. > > So, now we move on to DELETE. In this case, let's say that > the first DELETE > will return a 200 response and subsequent DELETEs return a > 404 response. > >From the definition and scoping of "side-effect" above, we > all agree that > the state of the resource after each delete is that it does > not exist. This > is enough to also satisfy DELETE's requirement of > idempotency. Further, > this is no different than returning two responses for repeated PUTs. > > > In the end, my personal conclusion is that responses have > nothing to do with > idempotency. Idempotency is only limited to the resource on > the server. > Regardless of what is returned to the client, the operation > on the server is > idempotent (assuming that the end state is the same after > repeated identical > requests). > > > So what does this mean for returning responses from DELETE? > I think that > 200 (OK) or 202 (Accepted) or 204 (No Content), followed by > 404 (Not Found) > or 410 (Gone) and maybe 303 (See Other) would be no different > than expected > of other idempotent methods like PUT and GET. > > If I had to suggest an order of usage, I'd say (in order of > most expressive > to least expressive): > > First request: > 204 (No Content) > 202 (Accepted) > 200 (OK) > > Repeated requests: > 303 (See Other) > 410 (Gone) > 404 (Not Found) > > > Should we allow repeated DELETE requests to always get back a > "200" (or > similar) response? PUT (DELETE's binary opposite) doesn't > allow it. GET, > while possible to receive the same response over and over > again, must also > be open to receiving other responses as well. So, why should > DELETE be any > different? My thought here is that it would be wrong (given > the way the > other two verbs work) to return the same response code > regardless of whether > the resource was deleted or not. > > > <note>I think that's it. Sorry if it seemed to ramble on. I stopped > somewhere in the middle to watch The Daily Show (comedy > central) and when > they showed the clip of Bush totally screwing up a simple > quote, I just lost > all concentration (funny stuff, it was). Again, sorry if it all seems > incoherent. :) *giggle* </note> > > [1] http://www.ietf.org/rfc/rfc2616.txt > > --- > Seairth Jacobs > seairth@... > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> If we take this interpretation of idempotence, then RFC 2616's > discussion of non-idempotent sequences of idempotent methods makes no > sense at all, because on this interpretation *all* sequences of > idempotent methods are idempotent sequences: see the proof I gave > earlier ... which I'm confident that Walden's model, if he puts it > together, will verify. I had thought the proof was convincing, but if people still have doubts, I'll throw the model together. I don't know how to model the act of repeating a function (or function series) arbitrarily many times, but I think that a discrete repeat scope = 5 should satisfy most critics. Of course it's easy to hack the model to larger scopes. Sorry for not getting these models up sooner, and I'm a bit bogged down with the rewrite of a RESTful specification right now, with management drunk of schedule pressures and postponing quality wherever possible. Bear with me; I have some of this stuff on paper. Walden
From: "Mathews, Walden" <waldenm@...> > > Still, the question arises: Should a client be able (guaranteed > by contract) to discover the mapped or unmapped pre-state of > a resource by invoking DELETE? Some applications may care, and > so we need to know if that contract was intended by 2616 or > not. I would say the answer is "yes", the client should be able to discover the pre-state when using DELETE, but can ignore what it finds. The reason I say this is because 2616 already explicitly says this very thing about PUT (201, followed by 200). The problem I see is that, unlike PUT, DELETE's spec leaves us guessing as to *which* response(s) to use. The only thing I feel for certain is that we should not send the same response when the pre-state is different between requests (e.g. 200 only), at least as far as DELETEs are concerned. --- Seairth Jacobs seairth@...
> Paul Prescod wrote: > > I think that there is a problem and a variety of solutions and am > soliciting opinions on both issues. Ambiguity of the spec with regards to DELETE has been recognized for a while, e.g.: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html I get the sense that some common understanding may have been achieved, but if in fact there was one, this agreement is now folkloric and hasn't been explicitly published anywhere. If someone can clearly demonstrate how a reasonable interpretation of the semantics of DELETE will lead to broken client-side code because of inconsistent server-side implementations, it would seem important enough that it should be addressed directly by the TAG, much like was done with regards to GET: http://www.w3.org/2001/tag/doc/get7 > Mathews, Walden wrote: > > shall I publish a simple Alloy model to this list > tommorow to drive a stake into the ground? I'd like to see it. It be a good way to bring the ambiguity into relief and help to reinforce the importance of the problem if it does get presented to the TAG. - Winter
> > > Mathews, Walden wrote: > > > > shall I publish a simple Alloy model to this list > > tommorow to drive a stake into the ground? > > I'd like to see it. It be a good way to bring the ambiguity > into relief > and help to reinforce the importance of the problem if it > does get presented > to the TAG. > > - Winter Okay, so do I understand correctly that what we want to model is the DELETE operation in two variants: the first says that the resource->representation mapping may be empty and DELETE is still a valid method; the second says the a non-empty mapping is a required pre-condition for DELETE. Translated to response codes, the former says that if the server honors DELETE, then the response code is always 200; the second says that if the server honors DELETE but the resource was unmapped before the delete, then in that case the response is 404, else it's 200. Do I correctly understand the modelling task here? Walden Is that the problem
For anyone not already participating in the uri@... mailing list, there are some interesting threads related to some of the things being discussed here on rest-discuss. I discovered these when following up on the comment Mark B made about "DELETE shouldn't return a 404." The message from Roy F. that Mark included was actually a post [1] Roy made to the uri@... list. When I went there and read the entire thread, Mark's response made more sense. In fact, my own notion of what a resource is (in HTTP) and the relationship between URIs and resources has changed somewhat. At least for me, it was interesting and instructive to follow the entire thread and some of the side-threads it generated. In partciular, there were two messages [2] [3] that talked about the concept of resources being composed of other resources - especially where a resource has multiple representations. These shed some light on the limitations of PUT with regard to representations and changed my notion of how content negotiation fits into the bigger picture . [1] http://lists.w3.org/Archives/Public/uri/2002Sep/0045.html [2] http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html [3] http://lists.w3.org/Archives/Public/uri/2002Sep/0028.html (I hate that archives are broken out by month - it makes it so much harder to follow threads that span more than one month). --Chuck
Seairth Jacobs wrote: >... I don't really see this bit as confusing at all. Of course an operation will return different responses. When you PUT to an object that doesn't exist you get Created. When you PUT again, you don't. Idempotency is about *side-effects* which I take to mean anything outside of the request/response pair. >... > Now, let's move on to PUT. When PUT is used, and the resource did not > exist, then a 201 (Created) response is expected. Subsequent PUTs to the > same resource return 200 (OK) responses. This is very common practice and I > have never heard a single person say this is not idempotent. I strongly feel your analysis is correct. I never saw the debate about two deletes as having anything to do with idempotence. It is merely a question of whether deleting a thing twice is an error or a normal action. In most file systems I'm familiar with it is an error. That's because objects have identity in a file system and trying to delete a non-existent object is a problem. In SQL, a DELETE that effects nothing is not a problem because "rows" do not have identity (except in a particular application domain where you choose some column or set of columsn to use as the identifier). But this has nothing to do with idempotency. Paul Prescod
> -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Thursday, September 19, 2002 1:20 PM > To: Seairth Jacobs > Cc: rest-discuss > Subject: Re: [rest-discuss] True meaning of "Idempotent"? > > > Seairth Jacobs wrote: > >... > I don't really see this bit as confusing at all. Of course an > operation > will return different responses. When you PUT to an object > that doesn't > exist you get Created. When you PUT again, you don't. Idempotency is > about *side-effects* which I take to mean anything outside of the > request/response pair. > > >... > > Now, let's move on to PUT. When PUT is used, and the > resource did not > > exist, then a 201 (Created) response is expected. > Subsequent PUTs to the > > same resource return 200 (OK) responses. This is very > common practice and I > > have never heard a single person say this is not idempotent. > > I strongly feel your analysis is correct. I never saw the > debate about > two deletes as having anything to do with idempotence. It is merely a > question of whether deleting a thing twice is an error or a normal > action. In most file systems I'm familiar with it is an error. That's > because objects have identity in a file system and trying to delete a > non-existent object is a problem. > > In SQL, a DELETE that effects nothing is not a problem > because "rows" do > not have identity (except in a particular application domain > where you > choose some column or set of columsn to use as the identifier). > > But this has nothing to do with idempotency. > > Paul Prescod I see the link to idempotence. Because of its definition, idempotent operations identify their end states (Proof, Miles?) In end-state "speak", SQL DELETE is idempotent because it is silent about mechanism, while filesystem delete is "idempotent" because it is silent about end-state, gabby about mechanism. Is 'declarative' the word I really want? Even so, I believe you can construct the connection between 'declarative' and 'idempotent' if you want to. Walden
> Translated to response codes, the former says that if the > server honors DELETE, then the response code is always 200; the > second says that if the server honors DELETE but the resource > was unmapped before the delete, then in that case the response > is 404, else it's 200. > > Do I correctly understand the modelling task here? I believe that captures it. I'm also left wondering: if subsequent DELETEs after an initial DELETE can return 200, does would imply that GET/HEAD should return 200/204 with an empty entity-body too? Perhaps you could include that in your model also?
> -----Original Message----- > From: Jeffrey Winter [mailto:j.winter@...] > Sent: Thursday, September 19, 2002 1:34 PM > To: Mathews, Walden; S. Mike Dierken; Paul Prescod > Cc: rest-discuss > Subject: Re: [rest-discuss] Re: Resources always exist > > > > Translated to response codes, the former says that if the > > server honors DELETE, then the response code is always 200; the > > second says that if the server honors DELETE but the resource > > was unmapped before the delete, then in that case the response > > is 404, else it's 200. > > > > Do I correctly understand the modelling task here? > > I believe that captures it. I'm also left wondering: if subsequent > DELETEs after an initial DELETE can return 200, does would imply that > GET/HEAD should return 200/204 with an empty entity-body too? Perhaps > you could include that in your model also? I'll include it if I understand it well enough. ;-) So you're saying that if the nth DELETE of some resource (with no intervening operations that could restore representation mapping) can return 200 (i.e., "OK it's not mapped"), then should a GET at this point (again, no intervening operations to change state) also return 200 (i.e., "OK, the resource is here because resources always exist) with an empty entity-body (i.e., "just because it exists doesn't mean it maps to any representations")? That's a different kind of modeling problem, and I'm not sure modeling will clarify anything. I believe the rule is that 404 means no representation was found, while it's implicit that any resource that ever existed still does. Walden > >
FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation. Insofar as this perhaps represents a "reference" implementation of an extension to the HTTP protocol, here's how it behaves: Request: PUT /test.xml HTTP/1.1 Response: HTTP/1.1 201 Created Request: GET /test.xml HTTP/1.1 Response: HTTP/1.1 200 OK Request: DELETE /test.xml HTTP/1.1 Response: HTTP/1.1 204 No Content Request: DELETE /test.xml HTTP/1.1 Response: HTTP/1.1 404 Not Found Request: GET /test.xml HTTP/1.1 Response: HTTP/1.1 404 Not Found Whether or not this represents some manifestation of the "folkloric" understanding of the behavior of the ambiguous DELETE specification I have no idea, but it of course certainly makes intuitive sense. I think it was also what most people would have expect the behavior to be - right up until Mark Baker's hand-grenade of last week: http://groups.yahoo.com/group/rest-discuss/message/2531 I'm not sure this really answers anything but it's an interesting data point. Is Slide wrong? - Winter
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation. Neat - I didn't know there was one. > > Insofar as this perhaps represents a "reference" implementation > of an extension to the HTTP protocol, here's how it behaves: I'm seeing two viewpoints of what an 'http request' is and they each have different expectations. The first is 'please perform this operation upon this resource' - so a DELETE on a non-existent resource fails. The second is 'please make it such that the resource does not exist' - so a DELETE on a non-existent resource is a 'duh - okay' response. The first is more of a procedural point of view, and the second is more of a declarative/logical assertion point of view. I don't know if that makes any sense, but I hope the HTTP philosophy isn't the declarative/logical assertion approach, since 0.001% of programmers would get it.
--- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote: > > > > -----Original Message----- > > From: Jeffrey Winter [mailto:j.winter@n...] > > Sent: Thursday, September 19, 2002 1:34 PM > > To: Mathews, Walden; S. Mike Dierken; Paul Prescod > > Cc: rest-discuss > > Subject: Re: [rest-discuss] Re: Resources always exist > > > > > > > Translated to response codes, the former says that if the > > > server honors DELETE, then the response code is always 200; the > > > second says that if the server honors DELETE but the resource > > > was unmapped before the delete, then in that case the response > > > is 404, else it's 200. > > > > > > Do I correctly understand the modelling task here? > > > > I believe that captures it. I'm also left wondering: if subsequent > > DELETEs after an initial DELETE can return 200, does would imply that > > GET/HEAD should return 200/204 with an empty entity-body too? Perhaps > > you could include that in your model also? > > I'll include it if I understand it well enough. ;-) So you're saying > that if the nth DELETE of some resource (with no intervening operations > that could restore representation mapping) can return 200 (i.e., "OK > it's not mapped"), then should a GET at this point (again, no intervening > operations to change state) also return 200 (i.e., "OK, the resource > is here because resources always exist) with an empty entity-body (i.e., > "just because it exists doesn't mean it maps to any representations")? > > That's a different kind of modeling problem, and I'm not sure modeling > will clarify anything. I believe the rule is that 404 means no > representation was found, while it's implicit that any resource that > ever existed still does. > Agreed there. The problem with DELETE does not apply for GET. While RFC 2616 says that "the side-effects of N > 0 identical requests is the same as for a single request", this is not the case with DELETE, regardless of response codes, unless the representation being deleted never existed (In which you can always return a 404 - while not stated explicitly as legal in the spec in regards to DELETE, it seems to be implied from other areas). On the first DELETE, there is a side-effect - a representation is un- mapped. On the second and subsequent DELETEs, there is no representation to un-map, so the side effect /cannot/ take place. It seems impossible to me to maintain idempotence across requests 1 and 2 with DELETE, and impossible not to (as far as effects on the server go) on all requests > 1. The problem with trying to prove that always (for requests > 0) returning a 200 (duh) OK/202/204 response would break a client is that the spec also states that it is not guaranteed that the intended side-effect actually occurred (perhaps supervisor authorisation must first be granted, for instance). To return a 404 is guaranteeing that the side-effect did not take place; to return a 20X response is more in keeping with the spec where no guarantees are given. However in the 20X case the client can never be sure the request was actioned, and your dream of a consistent interface flies out the window. Imagine if dialog boxes had "Yes", "No" and "Maybe" buttons... As a client, I'd like to see a 404 telling my I'm stupid for trying to delete something that didn't exist. At least then I can check for typos. In which case, 2616 would have to be subject to a minor alteration: "the side-effects of N > 0 identical requests is the same as for a single request [ except in the case of DELETE, where N > 1 ]"
firepipe_au wrote: > --- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote: > >... > While RFC 2616 says that "the side-effects of N > 0 identical > requests is the same as for a single request", this is not the case > with DELETE, regardless of response codes, unless the representation > being deleted never existed (In which you can always return a 404 - > while not stated explicitly as legal in the spec in regards to > DELETE, it seems to be implied from other areas). > > On the first DELETE, there is a side-effect - a representation is un- > mapped. On the second and subsequent DELETEs, there is no > representation to un-map, so the side effect /cannot/ take place. It > seems impossible to me to maintain idempotence across requests 1 and > 2 with DELETE, and impossible not to (as far as effects on the server > go) on all requests > 1. What's the problem? After one request the state of the universe is that the resource does not exist and/or is unmapped. After ten requests, the resource does not exist and/or is unmapped. That's idempotence! >... > "the side-effects of N > 0 identical requests is the same as for a > single request [ except in the case of DELETE, where N > 1 ]" The *side effect* is the same. There is no resource. The response may be different. Paul Prescod
> From: firepipe_au [mailto:michael@...] > Sent: Friday, September 20, 2002 3:37 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] Re: Resources always exist > > ... > > Agreed there. The problem with DELETE does not apply for GET. > > While RFC 2616 says that "the side-effects of N > 0 identical > requests is the same as for a single request", this is not the case > with DELETE, regardless of response codes, unless the representation > being deleted never existed (In which you can always return a 404 - > while not stated explicitly as legal in the spec in regards to > DELETE, it seems to be implied from other areas). Huh? The side effect for the single DELETE is that the URI mapping is removed. The side effect for N DELETEs (where N > 1) is the same -- the URI mapping is removed. What's the problem here? > On the first DELETE, there is a side-effect - a representation is un- > mapped. On the second and subsequent DELETEs, there is no > representation to un-map, so the side effect /cannot/ take place. It It doesn't have to anymore. > ... Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Hi all, The confusion seems to have shifted to the interpretation of "side-effects". A side-effect sounds more like a state transition than a state designation, but I'm sure Dr. Fielding meant the latter, not the former. Saying that DELETE is idempotent with respect to the function that maps the deleted resource's pre-DELETE state to its post- DELETE state is not implying anything about the response code for the DELETE request-response. Perhaps this should be specified; perhaps it shouldn't. Exciting news! I just finished an extended design session with four other developers in re-designing the web interface to the project we're working on. Several of them had epiphanies today in which they discovered the meaning (and coolness) of "hypertext as the engine of application state". Witnessing that was a terrific experience for me. Made my week. Our new design (2nd cut at hitting the REST mark) is quite good. More exciting news!! Roy is right. Sequences of idempotent operations need not be idempotent. I build an Alloy model tonight (finally) which demonstrates this. I have a pdf which I'll post here as soon as I can find my way into a mail client. So stay tuned... Walden
----- Original Message ----- From: "waldenmathews" <waldenm@...> > Several of them had epiphanies today > in which they discovered the meaning (and coolness) of "hypertext > as the engine of application state". Please explain - that part I just don't understand... examples work for me... How can 'hypertext' (which seems static) and 'engine' (which seems dynamic) be connected?
Ok, you'll find attached the pdf file generated by Alloy. The functions f, g and h are
all idempotent: they satisfy the constraint
fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for 'fun')
The analyzer was asked to generate a counterexample to the claim that
there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it found one. The
reason it's not intuitive is that we need at least 6 nodes for this condition
to occur.
Battery low. I'll post the model code tomorrow for those interested. What's
the next modelling challenge?
--Walden
----- Original Message ----- From: "waldenmathews" <waldenm@...> > > Exciting news! I just finished an extended design session with > four other developers in re-designing the web interface to the > project we're working on. Is the 'web interface' for the 'visual web' or the 'automatable web'? Is is UI or an application information model?
----- Original Message ----- From: "Walden Mathews" <waldenm@...> > Ok, you'll find attached the pdf file generated by Alloy. The functions f, g and h are > all idempotent: they satisfy the constraint > > fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for 'fun') When you have nested functions - what does that mean? Is it the return data of one function is the input to another function, or is it the function applied to the total state of the system after applying the function to the total state of the system (where its initial conditions are identified by 'x')?
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com>; "waldenmathews" <waldenm@...> Sent: Saturday, September 21, 2002 1:53 AM Subject: Re: [rest-discuss] Idempotence > > ----- Original Message ----- > From: "waldenmathews" <waldenm@...> > > > > > Exciting news! I just finished an extended design session with > > four other developers in re-designing the web interface to the > > project we're working on. > Is the 'web interface' for the 'visual web' or the 'automatable web'? Is is > UI or an application information model? Oh good heavens man, the latter, the latter. 8-) W
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com>; "Walden Mathews" <waldenm@...> Cc: <waldenm@...> Sent: Saturday, September 21, 2002 1:57 AM Subject: Re: [rest-discuss] Roy was right > > ----- Original Message ----- > From: "Walden Mathews" <waldenm@...> > > > > > Ok, you'll find attached the pdf file generated by Alloy. The functions > f, g and h are > > all idempotent: they satisfy the constraint > > > > fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for > 'fun') > > When you have nested functions - what does that mean? Is it the return data > of one function is the input to another function, or is it the function > applied to the total state of the system after applying the function to the > total state of the system (where its initial conditions are identified by > 'x')? You have to make that interpretation yourself. Idempotent is a mathematical property of homogeneous binary relations. You decide what's related to what when you do HTTP message exchange. Defined as way above. My answer is that you are relating pre-state to post-state of the resource, also badly known as the "side-effect" thing. The response code is not the same type as the resource state, so there's no homogeneity available there. Walden (truly so low on battery I must now shut down)
Walden Mathews wrote, > Ok, you'll find attached the pdf file generated by Alloy. The > functions f, g and h are all idempotent: they satisfy the constraint > > fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in > for 'fun') > > The analyzer was asked to generate a counterexample to the claim that > there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it > found one. The reason it's not intuitive is that we need at least 6 > nodes for this condition to occur. Fascinating! Good stuff ... That said, this doesn't actually settle the issue. The problem is that GET, PUT and DELETE are more constrained than f, g and h in your model. For example, a function modelling GET should never generate a state transition ... and all of the fn's in your counter-example violate that constraint. PUT and DELETE are, I think, also more constrained, in that, PUT /foo DELETE /foo is equivalent to, DELETE /foo and, DELETE /foo PUT /foo is equivalent to, PUT /foo and again, all of the fn's in your counter-example violate those constraints too. All three of these constraints played an essential role in my proof, so it'd help either if you could produce a new model which respects them, or if we could provide a rationale for why it's OK to violate them. BTW, is Alloy publicly available? Having seen the results I'd be interested in playing with it. Cheers, Miles
With REST, we talk about transfering representations. However, in HTTP, how much of a message is the representation? For instance, in a server response, we have three basic parts: 1) Response code 2) Headers 3) Entity-body (Message-body) So, which of the above is actually part of the representation of a resource? Does this change based on the verb being used? Does this change based on the response code being used? Are some headers considered part of the representation while others are not? --- Seairth Jacobs seairth@...
Hi,
I am still very new to REST and I can't decide what the best way to go would
be for the following issue:
Suppose I have an index that maps words to the documents they occurr in and
I want to make that index accessable as a RESTful web service.
Since the index is potentially too large to return it completely I need to
break it down into smaller chunks.
I wonder if
a) it is appropriate to think of the whole index as a concept of it's own and
to respond with different representations of it according to some parameters in
the query string of a GET request:
http:/foo.bar/archive/index?range=a-c
http:/foo.bar/archive/index?range=d-f
...
Again: is it a good idea to think of the particular chunks of the index as
different representations of the concept of the index as a whole ?
Or am I actually wrong when I think that the two URIs above identify the same
resource (is the query string part of the URI? )?
I think that I so far understood that fragment identifiers are not part of the
URI (don't affect what the URI identifies) and so I wonder if it would be better
to move the range part in a fragment:
http:/foo.bar/archive/index#a-c
http:/foo.bar/archive/index#d-f
or if
b) the above is actually the wrong wy to think and if it would be better to view all
the different chunks of the index as concepts themselves and to create resources
for them:
http:/foo.bar/archive/index
might then return something like
<index>
<subindex range="a-c" href="http:/foo.bar/archive/index/a-c" />
<subindex range="d-f" href="http:/foo.bar/archive/index/d-f" />
...
</index>
which would allow the server to control the size of the chunks dynamically.
If the index is quite small it might 'choose' to return
<index>
<subindex range="a-m" href="http:/foo.bar/archive/index/a-m" />
<subindex range="n-z" href="http:/foo.bar/archive/index/n-z" />
</index>
instead.
And it might also choose to return further subindexes (e.g. aa-am)
thus varying the number of drill-down levels depending on the index size.
I haven't yet understood the REST principles enough to make a decision between
a) and b) above (or yet something completely different?) and I would be very
thankful for help with this.
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > 1) Response code > 2) Headers > 3) Entity-body (Message-body) > > So, which of the above is actually part of the representation of a resource? > Does this change based on the verb being used? Does this change based on > the response code being used? Are some headers considered part of the > representation while others are not? I believe a client agent needs to understand all of them to understand what is and is not the representation. For example, the Content-Type header is metadata /about/ the representation. A status code tells you if the entity is even a representation or not. And so on.
----- Original Message ----- From: "Jan Algermissen" <algermissen@...> > > a) it is appropriate to think of the whole index as a concept of it's own and > to respond with different representations of it according to some parameters in > the query string of a GET request: > > http:/foo.bar/archive/index?range=a-c > http:/foo.bar/archive/index?range=d-f > ... > > Again: is it a good idea to think of the particular chunks of the index as > different representations of the concept of the index as a whole ? Addressing different chunks is a good idea. Some uses might not care - like if the data set was small and only occasionally used. But generally, my guess is that having chunks available is okay. If a client always gets all chunks, then you might as well stream the whole thing out in one chunk though. If you have good caching knowledge, then maybe chunks help. Maybe you should address the chunks not by lexical range, but by words themselves. Depends on what data the client is likely to retrieve - try to put that stuff in one chunk. > > Or am I actually wrong when I think that the two URIs above identify the same > resource (is the query string part of the URI? )? The query parameters are part of the URI, so these two URI are different resources. > > I think that I so far understood that fragment identifiers are not part of the > URI (don't affect what the URI identifies) and so I wonder if it would be better > to move the range part in a fragment: > > http:/foo.bar/archive/index#a-c > http:/foo.bar/archive/index#d-f This would cause a single 'index' resource to be retrieved - on large chunk. > > > or if > > b) the above is actually the wrong wy to think and if it would be better to view all > the different chunks of the index as concepts themselves and to create resources > for them: > > http:/foo.bar/archive/index > > might then return something like > > <index> > <subindex range="a-c" href="http:/foo.bar/archive/index/a-c" /> > <subindex range="d-f" href="http:/foo.bar/archive/index/d-f" /> > ... > </index> > > which would allow the server to control the size of the chunks dynamically. > If the index is quite small it might 'choose' to return > > <index> > <subindex range="a-m" href="http:/foo.bar/archive/index/a-m" /> > <subindex range="n-z" href="http:/foo.bar/archive/index/n-z" /> > </index> > > instead. Good use of hypertext to give central control & still minimize client coupling. However (and this is from previous arguments PaulP and I have had), the client is still dependent on the "range='a-m'" concept - the name 'range' and the syntax, content and meaning of the values. The client has to be coded to understand what the acceptable values, their allowable ranges, etc. An alternate would be to use your example #1 and use named query parameters with the same value space (letters with a dash between). This requires the server to support query terms, but that is really a trivial burden (some sort of mapping - path or query based - will always have to be done anyway) and generating query-based URIs is lighter weight than parsing XML and doing a content based query. > And it might also choose to return further subindexes (e.g. aa-am) > thus varying the number of drill-down levels depending on the index size. > > I haven't yet understood the REST principles enough to make a decision between > a) and b) above (or yet something completely different?) and I would be very > thankful for help with this. Good example and good questions. What kind of data size do you expect to encounter? What kind of clients do you wish to interact with? Both are fairly RESTful. Consider an alternate approach to exposing the map between a word and a list of documents. http://index.searchalert.net/documents/index?word=up This might not fit your larger system, but what is interesting about this is the potential to use POST on the same resource. You could POST a list of documents that have 'up' in them - which make the index manager purely an index manager and not a text parser. You could separate these two 'services' (pieces of functionality) across the Web (assuming a bunch of other things...)
Mike,
thanks for the very helpfull answer
(comments below).
"S. Mike Dierken" wrote:
>
> ----- Original Message -----
> From: "Jan Algermissen" <algermissen@...>
> >
> > a) it is appropriate to think of the whole index as a concept of it's own
> and
> > to respond with different representations of it according to some
> parameters in
> > the query string of a GET request:
> >
> > http:/foo.bar/archive/index?range=a-c
> > http:/foo.bar/archive/index?range=d-f
> > ...
> >
> > Again: is it a good idea to think of the particular chunks of the index
> as
> > different representations of the concept of the index as a whole ?
>
> Addressing different chunks is a good idea. Some uses might not care - like
> if the data set was small and only occasionally used. But generally, my
> guess is that having chunks available is okay. If a client always gets all
> chunks, then you might as well stream the whole thing out in one chunk
> though. If you have good caching knowledge, then maybe chunks help.
>
> Maybe you should address the chunks not by lexical range, but by words
> themselves. Depends on what data the client is likely to retrieve - try to
> put that stuff in one chunk.
>
> >
> > Or am I actually wrong when I think that the two URIs above identify
> the same
> > resource (is the query string part of the URI? )?
> The query parameters are part of the URI, so these two URI are different
> resources.
Ok, I thought so.
>
> >
> > I think that I so far understood that fragment identifiers are not part
> of the
> > URI (don't affect what the URI identifies) and so I wonder if it would
> be better
> > to move the range part in a fragment:
> >
> > http:/foo.bar/archive/index#a-c
> > http:/foo.bar/archive/index#d-f
> This would cause a single 'index' resource to be retrieved - on large chunk.
Yes, that's obvious now that you remined me ;-)
> >
> >
> > or if
> >
> > b) the above is actually the wrong wy to think and if it would be better
> to view all
> > the different chunks of the index as concepts themselves and to create
> resources
> > for them:
> >
> > http:/foo.bar/archive/index
> >
> > might then return something like
> >
> > <index>
> > <subindex range="a-c" href="http:/foo.bar/archive/index/a-c" />
> > <subindex range="d-f" href="http:/foo.bar/archive/index/d-f" />
> > ...
> > </index>
> >
> > which would allow the server to control the size of the chunks
> dynamically.
> > If the index is quite small it might 'choose' to return
> >
> > <index>
> > <subindex range="a-m" href="http:/foo.bar/archive/index/a-m" />
> > <subindex range="n-z" href="http:/foo.bar/archive/index/n-z" />
> > </index>
> >
> > instead.
> Good use of hypertext to give central control & still minimize client
> coupling. However (and this is from previous arguments PaulP and I have
> had), the client is still dependent on the "range='a-m'" concept - the name
> 'range' and the syntax, content and meaning of the values. The client has to
> be coded to understand what the acceptable values, their allowable ranges,
> etc.
Hmm, as far as I understood one idea is to put
links to subsequent resources inside a representation to give the client a path
to follow _without_ having the client to construct the URIs (using some deeper
knowledge of the server). Your answer sounds like the client would have to
construct the URIs for the subindexes, am I missing something here ?
> An alternate would be to use your example #1 and use named query parameters
> with the same value space (letters with a dash between).
Do you mean exactly like in example #1:
http:/foo.bar/archive/index?range=a-c
So basically like search engines work ?
I am using the 'drill-down' effect that way, don't I ?
> This requires the
> server to support query terms, but that is really a trivial burden (some
> sort of mapping - path or query based - will always have to be done anyway)
> and generating query-based URIs is lighter weight than parsing XML and doing
> a content based query.
Hmm, this sounds as if there is a way to avoid having the client understand the
syntax of the answer ?
>
> > And it might also choose to return further subindexes (e.g. aa-am)
> > thus varying the number of drill-down levels depending on the index
> size.
> >
> > I haven't yet understood the REST principles enough to make a decision
> between
> > a) and b) above (or yet something completely different?) and I would be
> very
> > thankful for help with this.
> Good example and good questions. What kind of data size do you expect to
> encounter?
This was actually a hypothetical example (you might think of a digital library
that would also offer things like 'view a list of all authors and their publications').
I am thinking at a very large scale where 'chunking' would definitely be a neccessity.
> What kind of clients do you wish to interact with?
Browsers (in which case I would return HTML) but also non-human clients like
other services for example.
> Both are fairly RESTful.
Good to hear ;-)
>
> Consider an alternate approach to exposing the map between a word and a list
> of documents.
> http://index.searchalert.net/documents/index?word=up
>
> This might not fit your larger system, but what is interesting about this is
> the potential to use POST on the same resource.
You mean that if the index is represented as a concept (resource) then querying
it and adding to it should both be performed on the same resource ? Ah, I see that
http://index.searchalert.net/documents/index?word=up is a resource that (might)
mean "the part of the index that represents all occurrences of 'up'" and that posting
a list of documents (URLs) to it would mean to add occurrences to that part of the index,
yes ? Interesting!
> You could POST a list of
> documents that have 'up' in them - which make the index manager purely an
> index manager and not a text parser. You could separate these two 'services'
> (pieces of functionality) across the Web (assuming a bunch of other
> things...)
Yes, I see what you are up to. Thanks, that helped a lot.
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
Jan Algermissen wrote:
> > An alternate would be to use your example #1 and use named query parameters
> > with the same value space (letters with a dash between).
>
> Do you mean exactly like in example #1:
>
> http:/foo.bar/archive/index?range=a-c
>
> So basically like search engines work ?
Uh, when I wrote:
> I am using the 'drill-down' effect that way, don't I ?
I actually meant to write:
I am loosing the 'drill-down' effect that way, don't I ?
^^^^^^^
Sorry about that.
Jan
From: "S. Mike Dierken" <mdierken@...> > > From: "Seairth Jacobs" <seairth@...> > > > > 1) Response code > > 2) Headers > > 3) Entity-body (Message-body) > > > > So, which of the above is actually part of the representation of a > > resource? > > Does this change based on the verb being used? Does this change based on > > the response code being used? Are some headers considered part of the > > representation while others are not? > > I believe a client agent needs to understand all of them to understand what > is and is not the representation. > For example, the Content-Type header is metadata /about/ the representation. > A status code tells you if the entity is even a representation or not. And > so on. This is also my current understanding, so I don't disagree with what you are saying. However, this view seems almost useless when talking about REST (at least to me). It seems to me that part of what makes REST effective is that, given a particular RESTful system, we can all agree on what does and does not constitute the representation of a resource (either sent or received, for that matter). However, with HTTP this is not very clear to me. I would think that the Message-body is always part of the representation (when there is one). But the headers seems to be less well-defined. For instance, would the "Location" header in a 201 response be considered part of the representation? As you suggest, Content-Type would be about the respresentation. Does that mean that it is not part of the representation? One thing that has suddenly occured to me is that I may be following a false assumption here as well. I assumed that in RESTful applications, representations were *always* sent (in responses). However, the more I think about this, the more this doesn't make sense. If I can send a request that contains no representation (e.g. GET), then I should be able to receive a response that has no presentation (201 maybe?). This doesn't necessarily help me understand what is part of a representation when one is sent, but this changed view would at least allow me to avoid wondering about several HTTP response codes for which there does not appear to be a representation. --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Jan Algermissen" <algermissen@...> > > This requires the > > server to support query terms, but that is really a trivial burden (some > > sort of mapping - path or query based - will always have to be done anyway) > > and generating query-based URIs is lighter weight than parsing XML and doing > > a content based query. > > Hmm, this sounds as if there is a way to avoid having the client understand the > syntax of the answer ? There are two aspects to the answers that are interesting - how you discover the location of more chunks of the index, and the data of the index itself (as viewed by the client). If you have some xml that is a mapping of multiple words to documents, then the client needs to know how to do local searches over that data - and so it doesn't much matter if you also do local searches to find more chunks to retrieve. If you have some xml that is /only/ the list of documents that a single word maps to - and the client knows what word it asked for - then you don't need to have a mix of both 'list of documents' and 'additional maps of resources and word ranges' - it simplifies the content structure. > > Good example and good questions. What kind of data size do you expect to > > encounter? > > This was actually a hypothetical example (you might think of a digital library > that would also offer things like 'view a list of all authors and their publications'). > I am thinking at a very large scale where 'chunking' would definitely be a neccessity. > > > What kind of clients do you wish to interact with? > > Browsers (in which case I would return HTML) but also non-human clients like > other services for example. Personally, I strongly believe that the resource models you end up with are different for the 'visual web' and the 'automatable web'. It is easier to do strong information architecture on the 'automatable web' approach - hyperlinking .vs. client-aware query terms, chunking, etc. The 'visual web' is a whole different ball game & existing browsers have lots of limitations (no PUT, no DELETE, etc. unless you do scripting with client components like MS's XMLHttpRequest). I think that you probably could have a REST/HTTP layer for pure information access and a UI/HTTP layer for browser and user experience concerns. Limited deployments probably would optimize away the REST information layer and go with straight SQL access - probably faster & more skill/tool support, but not as scalable/shareable. Just my opinions though.
----- Original Message ----- From: "Jan Algermissen" <algermissen@...> > > > An alternate would be to use your example #1 and use named query parameters > > with the same value space (letters with a dash between). > > Do you mean exactly like in example #1: > > http:/foo.bar/archive/index?range=a-c > > So basically like search engines work ? > > I am losing the 'drill-down' effect that way, don't I ? If the XML based index document used the very same URI as the constructed ones, the server won't notice or care. The client will send the same requests for various chunks.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > > This is also my current understanding, so I don't disagree with what you are saying. Um, thanks. > However, this view seems almost useless when talking about REST (at > least to me). It seems to me that part of what makes REST effective is > that, given a particular RESTful system, we can all agree on what does and > does not constitute the representation of a resource (either sent or > received, for that matter). However, with HTTP this is not very clear to > me. I would think that the Message-body is always part of the > representation (when there is one). But the headers seems to be less > well-defined. For instance, would the "Location" header in a 201 response > be considered part of the representation? As you suggest, Content-Type > would be about the respresentation. Does that mean that it is not part of > the representation? Yes - I believe it is not 'part' of the representation. I see a graph of related nodes - the graph is the interesting information, one node is the 'representation'. The graph says a lot about the representation - like what the syntax is, what the meaning is, what the encryption is, etc. Even if you view metadata as 'part' of the data - there are metadata items about that are purely about the request or response (success/failure, caching, etc.) that are still very useful in dealing with the representation. >
I think you're talking about control data in this thread. ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Saturday, September 21, 2002 9:21 PM Subject: Re: [rest-discuss] Where does the "representation" start? > From: "S. Mike Dierken" <mdierken@...> > > > > From: "Seairth Jacobs" <seairth@...> > > > > > > 1) Response code > > > 2) Headers > > > 3) Entity-body (Message-body) > > > > > > So, which of the above is actually part of the representation of a > > > resource? > > > Does this change based on the verb being used? Does this change based > on > > > the response code being used? Are some headers considered part of the > > > representation while others are not? > > > > I believe a client agent needs to understand all of them to understand > what > > is and is not the representation. > > For example, the Content-Type header is metadata /about/ the > representation. > > A status code tells you if the entity is even a representation or not. And > > so on. > > This is also my current understanding, so I don't disagree with what you are > saying. However, this view seems almost useless when talking about REST (at > least to me). It seems to me that part of what makes REST effective is > that, given a particular RESTful system, we can all agree on what does and > does not constitute the representation of a resource (either sent or > received, for that matter). However, with HTTP this is not very clear to > me. I would think that the Message-body is always part of the > representation (when there is one). But the headers seems to be less > well-defined. For instance, would the "Location" header in a 201 response > be considered part of the representation? As you suggest, Content-Type > would be about the respresentation. Does that mean that it is not part of > the representation? > > One thing that has suddenly occured to me is that I may be following a false > assumption here as well. I assumed that in RESTful applications, > representations were *always* sent (in responses). However, the more I > think about this, the more this doesn't make sense. If I can send a request > that contains no representation (e.g. GET), then I should be able to receive > a response that has no presentation (201 maybe?). This doesn't necessarily > help me understand what is part of a representation when one is sent, but > this changed view would at least allow me to avoid wondering about several > HTTP response codes for which there does not appear to be a representation. > > --- > Seairth Jacobs > seairth@... > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
Mathews, Walden wrote, > However, Roy's language is about idempotent compositions, not HTTP > methods in the specific, so I wanted to cover all bases and show > where his logic may be coming from. Err ... well in the context of RFC 2616, he's surely referring to compositions of idempotent _HTTP_ methods? What else would he be talking about in that RFC? > The Alloy software is available from Daniel Jackson's MIT Software > Design Group site: http://sdg.lcs.mit.edu/alloy/. There is also a > yahoo group for it called "alloy-discuss". Many thanks for the pointer ... hmm, actually, I think you sent me that once before. Sorry. > Yes, the model can be changed to correctly show the constraints on > GET, PUT and DELETE, and I believe once again that your proof will > hold rather trivially, but who knows. Fancy giving it a go? Cheers, Miles
Miles, You're absolutely right about GET, PUT and DELETE beyind constrained far beyond the constraints of mere idempotence. PUT and DELETE are both functions whose ranges consists of a single element. The range of DELETE is the "unmapped" resource, while the range of the function PUTX, where 'X' is designated end-state, is obviously just X. And GET is just an identity: GET(x)=x (in the side-effect sense). These relations don't even require the term f(f(x)) to describe them. The very notion of "sequences of idempotent functions" is peculiar because it is void of any idempotence test cases. In other words, to construct a "sequence" like g(f) you rule out f(f). Certainly we can rework the model to correctly represent the behaviors of GET, PUT and DELETE. When we do, I'm predicting that your assumption and proof will be reinforced. But I thought it would be interesting to show how compositions on idempotent functions worked in the abstract. At least we have some idea of where Roy was coming from. In other words, the spec addresses idempotence as a property of interest to clients. Extension to HTTP may want to include other idempotent methods which are less constrained than the present ones, and for which Roy's caveat would apply. Alloy is available to the public at http://sdg.lcs.mit.edu/alloy/, and there's also a yahoo group for it: alloy-discuss. Walden -----Original Message----- From: Miles Sabin To: rest-discuss@yahoogroups.com Sent: 9/21/2002 2:14 AM Subject: Re: [rest-discuss] Roy was right Walden Mathews wrote, > Ok, you'll find attached the pdf file generated by Alloy. The > functions f, g and h are all idempotent: they satisfy the constraint > > fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in > for 'fun') > > The analyzer was asked to generate a counterexample to the claim that > there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it > found one. The reason it's not intuitive is that we need at least 6 > nodes for this condition to occur. Fascinating! Good stuff ... That said, this doesn't actually settle the issue. The problem is that GET, PUT and DELETE are more constrained than f, g and h in your model. For example, a function modelling GET should never generate a state transition ... and all of the fn's in your counter-example violate that constraint. PUT and DELETE are, I think, also more constrained, in that, PUT /foo DELETE /foo is equivalent to, DELETE /foo and, DELETE /foo PUT /foo is equivalent to, PUT /foo and again, all of the fn's in your counter-example violate those constraints too. All three of these constraints played an essential role in my proof, so it'd help either if you could produce a new model which respects them, or if we could provide a rationale for why it's OK to violate them. BTW, is Alloy publicly available? Having seen the results I'd be interested in playing with it. Cheers, Miles To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mike, Yeah, it would be like saying that the Interstate highway system is the "engine" of domestic ground travel, in which case What's that whirring noise coming from under my hood? ;-) "Engine" has a broader meaning that means "means"; know what I mean? The thing that my group was "getting" was the idea that every useful state is just an explicit link from wherever we are now, and how beautiful it is when the client doesn't have to try to invent meaningful states and then gamble on their validity in the system. Walden -----Original Message----- From: S. Mike Dierken To: rest-discuss@yahoogroups.com Sent: 9/21/2002 1:52 AM Subject: Re: [rest-discuss] Idempotence ----- Original Message ----- From: "waldenmathews" <waldenm@...> > Several of them had epiphanies today > in which they discovered the meaning (and coolness) of "hypertext > as the engine of application state". Please explain - that part I just don't understand... examples work for me... How can 'hypertext' (which seems static) and 'engine' (which seems dynamic) be connected? To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> Miles Sabin wrote, > > Mathews, Walden wrote, > > However, Roy's language is about idempotent compositions, not HTTP > > methods in the specific, so I wanted to cover all bases and show > > where his logic may be coming from. > > Err ... well in the context of RFC 2616, he's surely referring to > compositions of idempotent _HTTP_ methods? What else would he be > talking about in that RFC? Since HTTP is extensible, I'm sure the definition was intended to be carried though to any other conceivable methods. Still, the original authors seem to have even the basic HTTP/1.1 methods in mind when the wording was included. This appears to be one of the original messages in which the difference in the definition of "Idempotent Methods" between RFC2616 and RFC2068 was first proposed (by Jeffrey Mogul, one of the authors): http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0704.html - Winter
Winter, Ah, transactions. So that's what those rascals were up to! Well, that explains everything. So much for my model; I was way off in the weeds. I wish they would have said "a sequence of idempotent invocations on multiple resources will not necessarily be idempotent over the collective state of those resources" or something like that. Anyhow, I'm on a modelling roll now if anyone cares to submit a challenging case for analysis. Walden --- In rest-discuss@y..., "Jeffrey Winter" <j.winter@n...> wrote: > > Miles Sabin wrote, > > > Mathews, Walden wrote, > > > However, Roy's language is about idempotent compositions, not HTTP > > > methods in the specific, so I wanted to cover all bases and show > > > where his logic may be coming from. > > > > Err ... well in the context of RFC 2616, he's surely referring to > > compositions of idempotent _HTTP_ methods? What else would he be > > talking about in that RFC? > > Since HTTP is extensible, I'm sure the definition was intended to be > carried though to any other conceivable methods. > > Still, the original authors seem to have even the basic HTTP/1.1 > methods in mind when the wording was included. > > This appears to be one of the original messages in which the difference > in the definition of "Idempotent Methods" between RFC2616 and RFC2068 > was first proposed (by Jeffrey Mogul, one of the authors): > > http://lists.w3.org/Archives/Public/ietf-http-wg- old/1997MayAug/0704.html > > - Winter
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > Yeah, it would be like saying that the Interstate highway system is the > "engine" of domestic ground travel, in which case What's that whirring noise > coming from under my hood? ;-) > > "Engine" has a broader meaning that means "means"; know what I mean? Sort of... I'm being dense just know. > > The thing that my group was "getting" was the idea that every useful state > is just an explicit link from wherever we are now, What do you mean by 'state'? I'm thinking in terms of client, server and server-based data. It sounds like you are using 'state' as in state transition... maybe that's a viewpoint that I haven't tried yet. > and how beautiful it is > when the client doesn't have to try to invent meaningful states and then > gamble on their validity in the system. > > Walden > > -----Original Message----- > From: S. Mike Dierken > To: rest-discuss@yahoogroups.com > Sent: 9/21/2002 1:52 AM > Subject: Re: [rest-discuss] Idempotence > > > ----- Original Message ----- > From: "waldenmathews" <waldenm@...> > > > Several of them had epiphanies today > > in which they discovered the meaning (and coolness) of "hypertext > > as the engine of application state". > Please explain - that part I just don't understand... examples work for > me... > How can 'hypertext' (which seems static) and 'engine' (which seems > dynamic) > be connected? > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ >
Jeffrey Winter wrote, > This appears to be one of the original messages in which the > difference in the definition of "Idempotent Methods" between RFC2616 > and RFC2068 was first proposed (by Jeffrey Mogul, one of the > authors): > > http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0704. > html Ahh ... thanks for that. This rings a bell from the last time I dug into this. OK, it's easy to see from the example in that message where the assumptions underlying my proof don't match, Step 1: x := RA.GET(); Step 2: RC.PUT(x); Step 3: y := RB.GET(); Step 4: RA.PUT(y); Step 5: x := RA.GET(); Step 6: RC.PUT(x); Step 7: y := RB.GET(); Step 8: RA.PUT(y); Clearly the PUT entity in (2) is different from the PUT entity in (6), which is a possibility I explicitly ruled out. I guess my big question now is: does allowing the PUT entity to vary from invocation to invocation in this way leave us with a coherent notion of idempotence? I obviously isn't intended to be "invoking the same method with the same args more than once has the same effect as invoking it exactly once". So what is it really intended to be? Cheers, Miles
> It sounds like you are using 'state' as in state > transition... maybe that's a viewpoint that I haven't tried yet. Yes, hypertext as the *means* of transition among the legal states of the application. Walden
> > It sounds like you are using 'state' as in state > > transition... maybe that's a viewpoint that I haven't tried yet. > > Yes, hypertext as the *means* of transition among the legal > states of the application. No, hypertext as the *engine*, because the link selections within the representation drive the state transition. Word smithing, I know, but it's important to grok how general the dynamic is. Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.gooseworks.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
I wonder if we should move the more advanced conversations about the exact formal meanings of various methods to rest-explore so that rest-discuss can be more easily used by people trying to grasp the basics (the role of URIs, hypertext, statelessness, etc.). That can be a learning curve all by itself. And then there are all of the "how do I implement this in my environment" questions to consider. Paul Prescod
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > Yes, hypertext as the *means* of transition among the legal > states of the application. Are the resources identified by the URI the set of states of the application? Hmm... I view the application as distributed across both the client and the server. Using a GET only provides information to the client (in terms of side-effects) - and the client can decide what to do with it. How does this translate into transitioning into a new state for the application? Color me still confused...
> > Yes, hypertext as the *means* of transition among the legal > > states of the application. > Are the resources identified by the URI the set of states of the > application? More like states of the client, but Dr. Fielding has already crafted the language that defines client state as being a function of outstanding requests, etc. I need not reword the concept. > Hmm... I view the application as distributed across both the > client and the > server. That's a reasonable scope. In that case I don't think the "engine" analogy is quite so clear, but I don't know that it is invalid either. Does the server change state other than when a link is followed? Certainly, but probably mostly outside the scope of web architecture, like at startup or reconfig time. I think if you overanalyze the language, you come to the dry realization that following pointers is how applications change state, and that URIs are pointers. It doesn't mean we have to abandon Neutonean physics just yet. > Using a GET only provides information to the client > (in terms of > side-effects) - and the client can decide what to do with it. I don't understand this. Don't we agree that GET is free of side-effects? > How does this translate into transitioning into a new state for the > application? Well, one of the things that characterizes states in a finite state machine is the list of eligible states reachable from where you are now. In a well-designed web application, hyperlinks correspond pretty well to that list, don't they? And it's not only about GET. If I am looking at a recently gotten User document and it has a link associated with the text "close this user", and I POST the right stuff to that URL, I just transitioned to a new client state. > > Color me still confused... > Truly confused, or just pretending a little? Walden
If I do any more modelling work, I'll post it only to rest-explore from now on. I'm not sure if anyone will read it there, but I do agree that it would be distracting for people trying to grasp the basics. Walden > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Monday, September 23, 2002 7:26 AM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] rest-explore > > > I wonder if we should move the more advanced conversations about the > exact formal meanings of various methods to rest-explore so that > rest-discuss can be more easily used by people trying to grasp the > basics (the role of URIs, hypertext, statelessness, etc.). > That can be a > learning curve all by itself. And then there are all of the "how do I > implement this in my environment" questions to consider. > > Paul Prescod > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Plan to Sell a Home? > http://us.click.yahoo.com/J2SnNA/y.lEAA/ySSFAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > Yes, hypertext as the *means* of transition among the legal > > states of the application. > > No, hypertext as the *engine*, because the link selections within the > representation drive the state transition. Word smithing, I > know, but it's > important to grok how general the dynamic is. The link *selections* (actions) drive the state transitions, not the links themselves. The engine *drives* the car; the highway does not pull it along. "Dereferencing of hypertext links" is the engine of application state, taking the active interpretation of "engine". Enough wordsmithing. It's not all that important, is it? Walden
Instead, why not start another list called "rest-basics" or "rest-learn"? I think "rest-discuss" should continue to be used as a place to discuss the intricacies, conflicting views, etc. of REST. --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Paul Prescod" <paul@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, September 23, 2002 7:25 AM Subject: [rest-discuss] rest-explore > I wonder if we should move the more advanced conversations about the > exact formal meanings of various methods to rest-explore so that > rest-discuss can be more easily used by people trying to grasp the > basics (the role of URIs, hypertext, statelessness, etc.). That can be a > learning curve all by itself. And then there are all of the "how do I > implement this in my environment" questions to consider. > > Paul Prescod > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> > > Using a GET only provides information to the client > > (in terms of > > side-effects) - and the client can decide what to do with it. > > I don't understand this. Don't we agree that GET is free of > side-effects? What I meant was that following links (where following == GET) doesn't change server state. Following links can only provide information to a client that would then change its own state. Each client could end in different states even though the hypermedia and resource representations were exactly the same for each. > > > > Color me still confused... > > > > Truly confused, or just pretending a little? > The 'state machine' viewpoint of REST is very confusing to me. I understand and like all the stuff about REST I've learned over the years, but this part doesn't (yet) fit my pre-conceived notions. I'll keep noodling on it.
> What I meant was that following links (where following == GET) doesn't > change server state. Following links can only provide information to a > client that would then change its own state. Each client could end in > different states even though the hypermedia and resource > representations > were exactly the same for each. If we're splitting hairs, then one bit difference constitutes clients in different states. But do you feel that two clients as described above could be in *significantly* different states having done the same GET and received the same representation? I think not. It does seem to depend, though, on what the client is caching along the way...Is that your point? Walden
----- Original Message ----- From: "Mathews, Walden" <waldenm@...> > > What I meant was that following links (where following == GET) doesn't > > change server state. Following links can only provide information to a > > client that would then change its own state. Each client could end in > > different states even though the hypermedia and resource > > representations > > were exactly the same for each. > > If we're splitting hairs, then one bit difference constitutes clients > in different states. But do you feel that two clients as described > above could be in *significantly* different states having done the same > GET and received the same representation? I think not. It does seem > to depend, though, on what the client is caching along the way...Is > that your point? No - I was thinking that one client was a text indexer (like a search engine) and another was a visual browser. They both receive the same content, but one just extracts words and associates them with the URI. The other shows some UI and stuff. I still don't get the 'state machine' viewpoint. Not a big deal.
S. Mike Dierken wrote: > >... > > The 'state machine' viewpoint of REST is very confusing to me. I understand > and like all the stuff about REST I've learned over the years, but this part > doesn't (yet) fit my pre-conceived notions. I'll keep noodling on it. I'm not going to jump in full-bore, but in case you haven't seen it, I've written a little about this that may or may not be helpful: http://www.prescod.net/rest/state_transition.html If not, sorry! Paul
----- Original Message ----- From: "Paul Prescod" <paul@...> > I'm not going to jump in full-bore, but in case you haven't seen it, > I've written a little about this that may or may not be helpful: > > http://www.prescod.net/rest/state_transition.html > Ahh.... many thanks Paul - you are always a help. "The current state of a conversation should be represented by a resource addressable by a URI" - this part I can grasp. I'll pretend 'state machine' relates to the states of a 'coordinating protocol' that two entities are using to dance together. Not a perfect analogy, but it gets my frame of mind headed in the right direction. This to me is a layer above REST, as opposed to REST itself - but that's okay. I like working out the coordination issues and I think this view of applying REST will be very useful.
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > "The current state of a conversation should be represented by a resource > addressable by a URI" - this part I can grasp. > I'll pretend 'state machine' relates to the states of a 'coordinating > protocol' that two entities are using to dance together. Not a perfect > analogy, but it gets my frame of mind headed in the right direction. > > This to me is a layer above REST, as opposed to REST itself - but that's > okay. I like working out the coordination issues and I think this view of > applying REST will be very useful. I started thinking about this question from the midst of a "choreography" project. Even when I started to grasp what Paul was talking about, I still made it more complicated than it needed to be. Here's an example of my current state of understanding, which probably still has a ways to go. The following is the outline of a conversation in hypertext. (Note, there's nothing special about this thread vs this topic, it was just a random selection.) http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0173.html RE: arch diagrams from the f2f From: Heather Kreger Date: Mon, Sep 23 2002 Next message: Heather Kreger: "Re: XML and SOAP constraints? (was RE: WSA constraints)" http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0174.html Previous message: Ugo Corda: "RE: Reliable Messaging Definition" http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0172.html Maybe in reply to: Heather Kreger: "arch diagrams from the f2f" http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0052.html Next in thread: Anne Thomas Manes: "RE: arch diagrams from the f2f" http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0180.html Reply: Anne Thomas Manes: "RE: arch diagrams from the f2f" http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0180.html etc. Note that the threads would not need to be all on the same site. Webloggers do this all the time: spin a conversation from one blog to another and back and forth. Each speech act contains a hyperlink to its referent. Somebody may collect the whole thread. Jon Schull and Jon Udell even did some diagrams of bloghopping threads. Business conversations could follow the same idea, using Paul's hyperlink + hash format. -Bob Haugen
> I'm seeing two viewpoints of what an 'http request' is and > they each have > different expectations. > The first is 'please perform this operation upon this resource' - so a > DELETE on a non-existent resource fails. > The second is 'please make it such that the resource does not > exist' - so a > DELETE on a non-existent resource is a 'duh - okay' response. > > The first is more of a procedural point of view, and the > second is more of a > declarative/logical assertion point of view. I don't know if > that makes any > sense, but I hope the HTTP philosophy isn't the declarative/logical > assertion approach, since 0.001% of programmers would get it. I think a few more than that would "get it", but I understand your point nonetheless. Sometimes the programmer doesn't matter as much as the customer. On my current project, we have an issue that's right on this same point. Our customer wants to "update portfolios". Up until now we've assumed, because the implementation details include the storing of incremental transaction data for audit, that the end-user is thinking this way too, but recent evidence seems to suggest that they always think "declaratively" about their portfolios. An example, the broker is allowed to run one chart window, but branch management has decided that brokers would be happier running the maximum product capability of four chart windows. Four is the target; four is the meaningful number in the problem domain; "plus 3" is the language of the application. The programmers and programing management likes "plus 3"; they don't want to change... There's a problem with "plus 3"; in order to get every broker's config up to four, we need to know in a time-sensitive manner each broker's current config. This places a high burden on the freshness of the caches. If we order "plus 3" for a broker who was participating in a prototype and already has four, we're making an illegal request. We might spend extra bandwidth to refresh caches of all affected accounts in order to stick with this non-idempotent method of portfolio update; or we might go with the natural format that matches the way portfolio coordinators and management think and use the declarative (idempotent) method instead. Based on bandwidth constraints alone, a development management who refused to listen to "idempotent" in the abstract must now pay attention and entertain the necessity of this change. That's what's been happening in our little world. If programmers can't keep up with that kind of thinking, their futures are a bit dark from where I sit. It ain't rocket science either... Peace, Walden
Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined to believe that response entity-bodies can be classified in three ways; * representations, in response to GETs * status messages, attached to exceptional status codes (e.g., 201, 404, etc.) * results, in response to POSTs Does this seem reasonable? I classify the response to a POST as a result, not a representation, because my reading is that while a POST might affect a resource's state, it does not return a representation of it; rather, it returns the results of processing. Thoughts? -- Mark Nottingham
Elsewhere I've seen the distinction between representation[1] - a representation of the resource addressed in the method invocation representation[2] - a representation of some other resource which may or may not have an identifier in the system yet. A "result" may be one of the latter, if I recall. Walden > -----Original Message----- > From: Mark Nottingham [mailto:mnot@...] > Sent: Tuesday, September 24, 2002 2:22 PM > To: rest-discuss@yahoogroups.com > Subject: [rest-discuss] responses > > > Looking over 2616 and draft-baker-http-resource-state-model, > I'm inclined > to believe that response entity-bodies can be classified in > three ways; > > * representations, in response to GETs > * status messages, attached to exceptional status codes > (e.g., 201, 404, > etc.) > * results, in response to POSTs > > Does this seem reasonable? I classify the response to a POST > as a result, > not a representation, because my reading is that while a POST > might affect > a resource's state, it does not return a representation of > it; rather, it > returns the results of processing. > > Thoughts? > > > -- > Mark Nottingham > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Home Selling? Try Us! > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
Hi Mark, On Tue, Sep 24, 2002 at 02:22:27PM -0400, Mark Nottingham wrote: > Looking over 2616 and draft-baker-http-resource-state-model, I'm > inclined > to believe that response entity-bodies can be classified in three ways; > > * representations, in response to GETs > * status messages, attached to exceptional status codes (e.g., 201, 404, > etc.) > * results, in response to POSTs > > Does this seem reasonable? I classify the response to a POST as a > result, > not a representation, because my reading is that while a POST might > affect > a resource's state, it does not return a representation of it; rather, > it > returns the results of processing. I think it's reasonable to classify the response to a successful POST as a representation of *a* resource, just not of *the* resource that the POST was invoked on. I believe that all data is a possible representation of some resource. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Definately; I'm just trying to differentiate what kinds of responses represent *that* resource's state. Would you agree that only responses to GET do so? ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Tuesday, September 24, 2002 11:35 AM Subject: Re: [rest-discuss] responses > Hi Mark, > > On Tue, Sep 24, 2002 at 02:22:27PM -0400, Mark Nottingham wrote: > > Looking over 2616 and draft-baker-http-resource-state-model, I'm > > inclined > > to believe that response entity-bodies can be classified in three ways; > > > > * representations, in response to GETs > > * status messages, attached to exceptional status codes (e.g., 201, 404, > > etc.) > > * results, in response to POSTs > > > > Does this seem reasonable? I classify the response to a POST as a > > result, > > not a representation, because my reading is that while a POST might > > affect > > a resource's state, it does not return a representation of it; rather, > > it > > returns the results of processing. > > I think it's reasonable to classify the response to a successful POST as > a representation of *a* resource, just not of *the* resource that the > POST was invoked on. > > I believe that all data is a possible representation of some resource. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined > to believe that response entity-bodies can be classified in three ways; > > * representations, in response to GETs > * status messages, attached to exceptional status codes (e.g., 201, 404, > etc.) > * results, in response to POSTs > > Does this seem reasonable? I classify the response to a POST as a result, > not a representation, because my reading is that while a POST might affect > a resource's state, it does not return a representation of it; rather, it > returns the results of processing. Very nice. If the response to a post does not identify via some header what resource the entity body is a representation of, then I'd classify it as 'result' type of response.
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined > to believe that response entity-bodies can be classified in three ways; > > * representations, in response to GETs > * status messages, attached to exceptional status codes (e.g., 201, 404, > etc.) > * results, in response to POSTs > > Does this seem reasonable? I classify the response to a POST as a result, > not a representation, because my reading is that while a POST might affect > a resource's state, it does not return a representation of it; rather, it > returns the results of processing. Very nice. If the response to a post does not identify via some header what resource the entity body is a representation of, then I'd classify it as 'result' type of response.
On Tue, Sep 24, 2002 at 11:38:27AM -0700, Mark Nottingham wrote: > Definately; I'm just trying to differentiate what kinds of responses > represent *that* resource's state. Would you agree that only responses to > GET do so? Well, turn it around. That resource's state could be represented in the response to a PUT or a POST of some other resource. 8-) But the only way to *explicitly request* a representation of the state is with GET, yes. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I think we've danced around this before, but I forget where we ended up... What are the semantics of DELETE regarding query strings. E.g., if I say DELETE /Bob?appendage=right_arm HTTP/1.1 Is Bob just practicing his writing skills, or are we all left scratching our heads and saying, "Where'd Bob get to?" I ask because of the somewhat tricky language in 2396, Section 3.4; The query component is a string of information to be interpreted by the resource. Note, "to be interpreted by the resource." -- Mark Nottingham
Hmm, just so we're crystal; The only requests which will return a representation of the state of the resource identified in the request-line will be GET; responses to other methods may contain the state of other resources, but not the one so identied. Correct? ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Tuesday, September 24, 2002 1:20 PM Subject: Re: [rest-discuss] responses > On Tue, Sep 24, 2002 at 11:38:27AM -0700, Mark Nottingham wrote: > > Definately; I'm just trying to differentiate what kinds of responses > > represent *that* resource's state. Would you agree that only responses to > > GET do so? > > Well, turn it around. That resource's state could be represented in > the response to a PUT or a POST of some other resource. 8-) > > But the only way to *explicitly request* a representation of the state > is with GET, yes. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com >
Well, rest-discuss came first, so we didn't think to call it "rest-newbies" (or whatever). But today, most of the membership is not REST experts, just people who want to learn more about REST. I agree that we should move the more advanced topics to rest-explore. May I remind you that I'm the administrator of this list ... Muhaha! 8-) MB On Mon, Sep 23, 2002 at 03:09:13PM -0400, Seairth Jacobs wrote: > Instead, why not start another list called "rest-basics" or "rest-learn"? I > think "rest-discuss" should continue to be used as a place to discuss the > intricacies, conflicting views, etc. of REST. -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tue, Sep 24, 2002 at 01:29:00PM -0700, Mark Nottingham wrote: > Hmm, just so we're crystal; > > The only requests which will return a representation of the state of the > resource identified in the request-line will be GET; responses to other > methods may contain the state of other resources, but not the one so > identied. > > Correct? Almost. The response to other methods may contain the state of any resource, including the one identified by the URI; the key point is just that there can be no expectation that the response will include the representation of any particular resource, including the targetted resource. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I wonder about the suggestion that S. Mike made earlier today. Doesn't seem like this is required anywhere, but perhaps it's a best practice? GET always returns representation of the resource you asked for. Other methods may return a representation of some resource. If they are returning such a representation, then the corresponding resource *should* be identified by a header, presumably Content-Location. If that header isn't present, then ... what? You can use the status code and the meaning of the entity body has to be determined out of band? -Lee ----- Original Message ----- From: Mark Baker To: Mark Nottingham Cc: rest-discuss@yahoogroups.com Sent: Tuesday, September 24, 2002 2:40 PM Subject: Re: [rest-discuss] responses On Tue, Sep 24, 2002 at 01:29:00PM -0700, Mark Nottingham wrote: > Hmm, just so we're crystal; > > The only requests which will return a representation of the state of the > resource identified in the request-line will be GET; responses to other > methods may contain the state of other resources, but not the one so > identied. > > Correct? Almost. The response to other methods may contain the state of any resource, including the one identified by the URI; the key point is just that there can be no expectation that the response will include the representation of any particular resource, including the targetted resource. MB
Anybody know what happened to RESTWiki. It used to be here
http://internet.conveyor.com/RESTwiki/
--Chuck
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > > I ask because of the somewhat tricky language in 2396, Section 3.4; > The query component is a string of information to be interpreted by > the resource. > > Note, "to be interpreted by the resource." I'm pretty sure this means the whole string including query /identifies/ the resource & the meaning & syntax is specific to the resource - but of course a 'manager' or 'controller' may understand the format as well. It doesn't imply identfying the resource and then passing just the query components to it. The resource (or its 'manager') is free to use whatever wacky syntax it wants.
----- Original Message ----- From: "Mark Nottingham" <mnot@...> > Hmm, just so we're crystal; > > The only requests which will return a representation of the state of the > resource identified in the request-line will be GET; responses to other > methods may contain the state of other resources, but not the one so > identied. a) but not [ever] the one so identied. b) but not [necessarily] the one so identied. I think b)
The machine was hacked, and had to have everything reinstalled on it. I'm working on it. On Tue, Sep 24, 2002 at 05:46:21PM -0400, Chuck Hinson wrote: > Anybody know what happened to RESTWiki. It used to be here > > http://internet.conveyor.com/RESTwiki/ -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tue, Sep 24, 2002 at 01:25:05PM -0700, Mark Nottingham wrote: > I think we've danced around this before, but I forget where we ended up... > > What are the semantics of DELETE regarding query strings. E.g., if I say > > DELETE /Bob?appendage=right_arm HTTP/1.1 > > Is Bob just practicing his writing skills, or are we all left scratching > our heads and saying, "Where'd Bob get to?" > > I ask because of the somewhat tricky language in 2396, Section 3.4; > The query component is a string of information to be interpreted by > the resource. > > Note, "to be interpreted by the resource." IMO, that's just unfortunate language. As Roy said, DELETE means roughly "remove any representations for this resource", so in that case - if I understand your intent - it would probably remove any pictures, or data, of/about his right arm. In other words, query parameters don't matter. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
On Tue, Sep 24, 2002 at 03:02:00PM -0600, Lee Fife wrote: > I wonder about the suggestion that S. Mike made earlier today. Doesn't seem like this is required anywhere, but perhaps it's a best practice? > > GET always returns representation of the resource you asked for. > Other methods may return a representation of some resource. If they are returning such a representation, then the corresponding resource *should* be identified by a header, presumably Content-Location. Sounds good. > If that header isn't present, then ... what? You can use the status code and the meaning of the entity body has to be determined out of band? The meaning of the body should stand on its own, independant of whether an identifier is provided or not. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Mark,
Did this discussion ever go anywhere?
I agree with the points you had made, but the current reading of "Obligations"
here:
http://www.w3.org/2001/tag/doc/get7#obligations
would indicate that some GET operation even with Google's counter would
be okay since the user agreed to those terms when obtaining a developer key.
Will this document be updated to reflect the issue you raised?
Thanks,
Jeff
----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Jeffrey Winter" <j.winter@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, September 09, 2002 12:18 PM
Subject: Re: [rest-discuss] GET: Shades of Grey
Yah, I'm following that too, and admit to being a bit puzzled by Dan's
response and the finding. I think each request has to stand alone in
its status as state-changing or not, for all the reasons I gave.
I'll see how the discussion, if any, goes, before chiming in. Dan's a
smart guy, so you better make sure your ducks are lined up before
challenging him. 8-)
MB
On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote:
> Mark,
>
> I thought that I had the issue of Google allowing an strictly
> non-idempotent GET resolved in my mind, but a recent item on
> the tag list pointed out this:
>
> http://www.w3.org/2001/tag/doc/get7#obligations
>
> I had been trying to argue - perhaps ineffectually - that the
> Developer's Key effects the notion of what "safety" means.
> The key is obtained through of an authorization relationship
> established in a way similar to that described in the "TAG Finding:
> URIs, Addressability, and the use of HTTP GET" document
> referenced above.
>
> I gave up on this line of reasoning because of your point
> about proxy cache refereshing.
>
> Do you think that your point effects the findings described
> in that TAG document? Or do you not think that the way
> Google is setup falls under this notion of "obligation"?
>
> Thanks,
>
> - Jeff
>
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA. distobj@...
http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: >On Tue, Sep 24, 2002 at 01:25:05PM -0700, Mark Nottingham wrote: > >>I think we've danced around this before, but I forget where we ended up... >> >>What are the semantics of DELETE regarding query strings. E.g., if I say >> >> DELETE /Bob?appendage=right_arm HTTP/1.1 >> >>Is Bob just practicing his writing skills, or are we all left scratching >>our heads and saying, "Where'd Bob get to?" >> >>I ask because of the somewhat tricky language in 2396, Section 3.4; >> The query component is a string of information to be interpreted by >> the resource. >> >>Note, "to be interpreted by the resource." >> > >IMO, that's just unfortunate language. As Roy said, DELETE means >roughly "remove any representations for this resource", so in that >case - if I understand your intent - it would probably remove any >pictures, or data, of/about his right arm. > >In other words, query parameters don't matter. > So, is it fair to say that for any URL x (that is, a URL of any form - qurey string or no), DELETE(x) deletes/removes/unmaps the same representation that GET(x) would have returned? --Chuck
On Wed, Sep 25, 2002 at 10:44:17AM -0400, Jeffrey Winter wrote: > Mark, > > Did this discussion ever go anywhere? Yah. I misinterpreted what Dan was saying. We were in agreement all along. > I agree with the points you had made, but the current reading of "Obligations" > here: > > http://www.w3.org/2001/tag/doc/get7#obligations > > would indicate that some GET operation even with Google's counter would > be okay since the user agreed to those terms when obtaining a developer key. Hmm, I don't read it that way. Is it the part that says "This is not to say that there are never any obligations related to following links" that leads you to believe this? FWIW, I had to do a double-take on that, but the word "related" is quite key there, as the example demonstrates. > Will this document be updated to reflect the issue you raised? The only issue I raised, that for some reason got lots of support, was that a pay-per-use example would probably be helpful to people. But I doubt it's a high priority item with the TAG - nor do I think it's very important. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Could the contract (ie, the developer key) under which the GET operation
took place part of the resource that represents the session, much as in
Paul Prescod's session="/sessions/42" example at:
http://www.prescod.net/rest/state_transition.html
Now I know why "42" -- the answer to any question!
Might even be a RESTful community convention to make resource invariants
like contracts available here -- /42 would be as interesting as /etc !
(Topic map PSIs might be available at 42/PSIs for example.)
Someone, I am sure, will let me know politely if I am breaking the
paradigm or not being RESTful.
> Mark,
>
> Did this discussion ever go anywhere?
>
> I agree with the points you had made, but the current reading of "Obligations"
> here:
>
> http://www.w3.org/2001/tag/doc/get7#obligations
>
> would indicate that some GET operation even with Google's counter would
> be okay since the user agreed to those terms when obtaining a developer key.
>
> Will this document be updated to reflect the issue you raised?
>
> Thanks,
>
> Jeff
>
>
> ----- Original Message -----
> From: "Mark Baker" <distobj@...>
> To: "Jeffrey Winter" <j.winter@...>
> Cc: <rest-discuss@yahoogroups.com>
> Sent: Monday, September 09, 2002 12:18 PM
> Subject: Re: [rest-discuss] GET: Shades of Grey
>
>
> Yah, I'm following that too, and admit to being a bit puzzled by Dan's
> response and the finding. I think each request has to stand alone in
> its status as state-changing or not, for all the reasons I gave.
>
> I'll see how the discussion, if any, goes, before chiming in. Dan's a
> smart guy, so you better make sure your ducks are lined up before
> challenging him. 8-)
>
> MB
>
> On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote:
> > Mark,
> >
> > I thought that I had the issue of Google allowing an strictly
> > non-idempotent GET resolved in my mind, but a recent item on
> > the tag list pointed out this:
> >
> > http://www.w3.org/2001/tag/doc/get7#obligations
> >
> > I had been trying to argue - perhaps ineffectually - that the
> > Developer's Key effects the notion of what "safety" means.
> > The key is obtained through of an authorization relationship
> > established in a way similar to that described in the "TAG Finding:
> > URIs, Addressability, and the use of HTTP GET" document
> > referenced above.
> >
> > I gave up on this line of reasoning because of your point
> > about proxy cache refereshing.
> >
> > Do you think that your point effects the findings described
> > in that TAG document? Or do you not think that the way
> > Google is setup falls under this notion of "obligation"?
> >
> > Thanks,
> >
> > - Jeff
> >
>
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA. distobj@...
> http://www.markbaker.ca http://www.idokorro.com
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Sam Hunting
eTopicality, Inc.
---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)
Topic map consulting and training: www.etopicality.com
Free open source topic map tools: www.gooseworks.org
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------
On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote: > So, is it fair to say that for any URL x (that is, a URL of any form - > qurey string or no), DELETE(x) deletes/removes/unmaps the same > representation that GET(x) would have returned? As well as all the other representations it knows about, yes, I'd say so. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I'm wondering about what assumptions would be safe with regard to the containment of the query-string resource within the base resource, or within other query-string resources. A pure reading has us believe that "/Bob" and "/Bob?appendage=right_arm" are each resources with no implied transitivity or implied anything. So, if I "GET /Bob", the representation returned is likely as not to include a picture of Bob's right arm, and so is the one returned from "GET /Bob?appendage=right_arm", if that's what that URI means. Next, I'll "DELETE /Bob?appendage=right_arm", GET that same resource again to confirm that the picture is no longer mapped there. Finally, I'll "GET /Bob" once more, and lo and behold he's still symmetric! Why? Because nobody told the implementation to unmap any representation stuff from "/Bob". Did I assume wrong? Walden > -----Original Message----- > From: Mark Baker [mailto:distobj@...] > Sent: Wednesday, September 25, 2002 10:56 AM > To: Chuck Hinson > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] DELETE semantics > > > On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote: > > So, is it fair to say that for any URL x (that is, a URL of > any form - > > qurey string or no), DELETE(x) deletes/removes/unmaps the same > > representation that GET(x) would have returned? > > As well as all the other representations it knows about, yes, I'd say > so. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@... > http://www.markbaker.ca http://www.idokorro.com > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Sell a Home with Ease! > http://us.click.yahoo.com/SrPZMC/kTmEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Mark Baker wrote: >On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote: > >>So, is it fair to say that for any URL x (that is, a URL of any form - >>qurey string or no), DELETE(x) deletes/removes/unmaps the same >>representation that GET(x) would have returned? >> > >As well as all the other representations it knows about, yes, I'd say >so. > >MB > So in the case of resources with multiple representations, or resources that have query strings, does it make sense to constrain DELETE in the same way the Fielding says PUT is constrained (resources that have multiple representation should not support PUT). I suspect that it probably isnt reasonable to require this constraint of DELETE, but I wonder if it wouldn't be a useful simplication is many cases. Just thinking out loud... --Chuck
Okay, despite pissing all over the idea of pipelined HTTP requests at some earlier point, I've come across a situation where this is absolutely necessary. That is, a situation where it would be nice to do e.g.: GET http://x/1?GET=http://y/2?GET=http://z/3 That is, a situation where it would be useful to pass the results of GETting z/3 as input to y/2 to be transformed, and then passing the results of that as input to x/1 and getting the result of that transformation. And it's necessary to do this strictly via a URI, that is, http://x/1?GET=http://y/2?GET=http://z/3 or somesuch is the name of this pipelined transformation result. Various folks around here have advocated this in the past, so I need some advice: the above won't work since the ? delimited parts of the query string will be interpreted as separate parameters for x/1. An alternative syntax for this might be: http://x/1/GET=http://y/2/GET=http://z/3 ...but it seems like getting e.g. Apache to do the right thing in this case might be tricky. It's particularly difficult since any of the sub-URI may themselves have query strings --- the part I'm calling z/3 in fact has a horrendously long query string of its own that shouldn't be interpreted by x or y (it's a bugzilla query, fyi.) Anybody have any suggestions on how to set things up here? Something to do with mod_rewrite? Examples --- particularly Python code--- much appreciated. jb BTW --- A colleague up at work wrote a MoinMoin processor that allows you to embed dot code directly into a Wiki page and have it generate / render the described graph, if anybody's interested. Also have a piece of Python code I wrote that turns wiki-style tables plus a "map" datastructure into a dot graph description... if anybody's interested, give me a holler. When we get the RESTWiki back up, we should install this stuff there --- tres useful. We use our Wiki up at work to coordinate all development specification and planning activities, and a lot of this stuff is the trivial fruit of some work to integrate Wiki and bugzilla and automate various dev planning processes.
I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image? that can't be right ... -Lee ----- Original Message ----- From: Chuck Hinson So in the case of resources with multiple representations, or resources that have query strings, does it make sense to constrain DELETE in the same way the Fielding says PUT is constrained (resources that have multiple representation should not support PUT). I suspect that it probably isnt reasonable to require this constraint of DELETE, but I wonder if it wouldn't be a useful simplication is many cases. Just thinking out loud... --Chuck
Why wouldn't there be a way to DELETE? -----Original Message----- From: Lee Fife [mailto:lee@...] Sent: Wednesday, September 25, 2002 1:24 PM To: rest-discuss@yahoogroups.com Subject: Re: [rest-discuss] DELETE semantics I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image? that can't be right ... -Lee ----- Original Message ----- From: Chuck Hinson <mailto:cmhinson@...> So in the case of resources with multiple representations, or resources that have query strings, does it make sense to constrain DELETE in the same way the Fielding says PUT is constrained (resources that have multiple representation should not support PUT). I suspect that it probably isnt reasonable to require this constraint of DELETE, but I wonder if it wouldn't be a useful simplication is many cases. Just thinking out loud... --Chuck Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=233217.2395914.3827946.2225242/D=egroupweb/S=17057010 14:HM/A=1227861/R=0/*http://ads.track-star.com/linker.ts?ts=1;2;312;3_2_11> <http://us.adserver.yahoo.com/l?M=233217.2395914.3827946.2225242/D=egroupmai l/S=:HM/A=1227861/rand=152150743> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
I'm just following up what Chuck said. It doesn't seem right to me.
Where does Fielding say this (no PUT for resources for multiple representations)? I don't recall seeing it ...
-Lee
----- Original Message -----
From: Mathews, Walden
To: 'Lee Fife' ; rest-discuss@yahoogroups.com
Sent: Wednesday, September 25, 2002 11:28 AM
Subject: RE: [rest-discuss] DELETE semantics
Why wouldn't there be a way to DELETE?
-----Original Message-----
From: Lee Fife [mailto:lee@...]
Sent: Wednesday, September 25, 2002 1:24 PM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] DELETE semantics
I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image?
that can't be right ...
-Lee
----- Original Message -----
From: Chuck Hinson
So in the case of resources with multiple representations, or resources
that have query strings, does it make sense to constrain DELETE in the
same way the Fielding says PUT is constrained (resources that have
multiple representation should not support PUT).
I suspect that it probably isnt reasonable to require this constraint of
DELETE, but I wonder if it wouldn't be a useful simplication is many cases.
Just thinking out loud...
--Chuck
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
I would like to apply REST principles to a problem that I am currently working through, but the current requirements are pushing towards an EBI (i.e., event-based) solution. The issue is that some read-only data is being generated that needs to be pushed to one particular class of client in near real-time. Some clients can perform periodic queries against the server to obtain this data, these others cannot. One idea would be to use some peer-to-peer protocol such as BXXP to alert that class of client that new information was available, perhaps supplying them with the URL in the message; that client could then GET the representation using HTTP. Obviously there are all the attendant scalability issues with EBI, but I can't see how to avoid it in this circumstance. What does REST have to say about this class of problem? Thanks, Jeff
I guess I'll have to squint a little harder. I read the entire line: "This is not to say that there are never any obligations related to following links; only that the obligations must be accepted some other way than requesting to follow a link." as saying that so long as you accepted the obligations (i.e., agreeing to the count-down counter) some "safe" way, that the party you have accepted the obligations from can enforce those obligations (i.e., performing the count-down) with a GET. Thanks again, Jeff
It's in one of the email archives; I'm not sure which one, but I think it might be for the uri list; it was posted a day or two on this list. Maybe the poster can answer your question. Sorry. Walden -----Original Message----- From: Lee Fife [mailto:lee.fife@...] Sent: Wednesday, September 25, 2002 1:34 PM To: rest-discuss@yahoogroups.com Cc: Mathews, Walden Subject: Re: [rest-discuss] DELETE semantics I'm just following up what Chuck said. It doesn't seem right to me. Where does Fielding say this (no PUT for resources for multiple representations)? I don't recall seeing it ... -Lee ----- Original Message ----- From: Mathews, Walden <mailto:waldenm@...> To: 'Lee Fife' <mailto:lee@...> ; rest-discuss@yahoogroups.com <mailto:rest-discuss@yahoogroups.com> Sent: Wednesday, September 25, 2002 11:28 AM Subject: RE: [rest-discuss] DELETE semantics Why wouldn't there be a way to DELETE? -----Original Message----- From: Lee Fife [mailto:lee@...] Sent: Wednesday, September 25, 2002 1:24 PM To: rest-discuss@yahoogroups.com <mailto:rest-discuss@yahoogroups.com> Subject: Re: [rest-discuss] DELETE semantics I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image? that can't be right ... -Lee ----- Original Message ----- From: Chuck <mailto:cmhinson@...> Hinson So in the case of resources with multiple representations, or resources that have query strings, does it make sense to constrain DELETE in the same way the Fielding says PUT is constrained (resources that have multiple representation should not support PUT). I suspect that it probably isnt reasonable to require this constraint of DELETE, but I wonder if it wouldn't be a useful simplication is many cases. Just thinking out loud... --Chuck Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=233217.2395914.3827946.2225242/D=egroupweb/S=17057010 14:HM/A=1227861/R=0/*http://ads.track-star.com/linker.ts?ts=1;2;312;3_2_11> <http://us.adserver.yahoo.com/l?M=233217.2395914.3827946.2225242/D=egroupmai l/S=:HM/A=1227861/rand=152150743> To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
On Wednesday, September 25, 2002, at 01:54 PM, John Fletcher wrote: > http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 Ugh... I was afraid that was how it was going to go. Any other suggestions that preserve readibility but perhaps torture URI syntax / semantics a bit more? ;-) jb
Hi, I am very new to REST and would like to know is there a Open Source REST implementation that i can look at it... Thanks, -Uday.
----- Original Message ----- From: "Jeff Bone" <jbone@...> To: <rest-discuss@yahoogroups.com> Sent: Wednesday, September 25, 2002 5:48 PM Subject: [rest-discuss] Retraction, advice sought, code offered > > Okay, despite pissing all over the idea of pipelined HTTP requests at > some earlier point, I've come across a situation where this is > absolutely necessary. That is, a situation where it would be nice to > do e.g.: > > GET http://x/1?GET=http://y/2?GET=http://z/3 > <snipped> Jeff Isn't this just what URL-Encoding is for? It's slightly more complex in that you need to "quote" the Nth URL in N layers of URL-Encoding. For example, your URL should be: http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 Regards John Fletcher
To use Uday's question as an opportunity to update everyone: I am *still* working on the REST toolkit. Since I last mentioned it, a lot of progress has been made. Currently, I am updating its use of Xerces-C from 1.6 to 2.1. When I have finally released it, which should be soon, I will be sure to first mention it here. Here are some features: 1. Class design includes CGeneral, CRequest, CResponse for messaging; CResource and CRepresentation for resources and representations; CContainer, CComponent, CConnector, CFilter and CNode as specialized resources. 2. Utility classes include implementation of thread pool, socket classes, multi-byte and XMLCh strings, URIs, lists, dictionaries, items, etc. 2. Extensible connector-based filtering through client- and server-based connector filters. 3. Design of environmental acquisition (e.g., python) and something I call "indirect traversal" which is a way to make URIs more dynamic in terms of how the server resolves them. 4. Object and resource factories for dynamic registry of factories that create specialized objects. 5. Very very primitive support for XML - the whole framework serializes itself based on a simple 10-line DTD that uses some core elements and attributes to define typing, scoping, naming, and containment. Once I finally release a first version, I really look forward to moving onto thinking about real-world examples like Paul's RESTmail idea, Bob's auction idea, etc. Thanks for being patient, Philip -----Original Message----- From: Uday .S [mailto:kumarudaya@...] Sent: Monday, September 23, 2002 5:23 PM To: rest-discuss@yahoogroups.com Subject: [rest-discuss] Newbie: Any REST Implementations? Hi, I am very new to REST and would like to know is there a Open Source REST implementation that i can look at it... Thanks, -Uday. ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
I posted a few links [1] to the uri list a few days ago which were part of a thread that talked about resources and resource containment. The third link [2] in particular implie no PUT for resources with multiple representation, though I would suggest reading the entire thread for better context. [1] http://groups.yahoo.com/group/rest-discuss/message/2620 [2] http://lists.w3.org/Archives/Public/uri/2002Sep/0028.html --Chuck Mathews, Walden wrote: > It's in one of the email archives; I'm not sure which one, but I think > it might be > > for the uri list; it was posted a day or two on this list. Maybe the > poster can > > answer your question. Sorry. > > > > Walden > > -----Original Message----- > *From:* Lee Fife [mailto:lee.fife@...] > *Sent:* Wednesday, September 25, 2002 1:34 PM > *To:* rest-discuss@yahoogroups.com > *Cc:* Mathews, Walden > *Subject:* Re: [rest-discuss] DELETE semantics > > I'm just following up what Chuck said. It doesn't seem right to me. > > > > Where does Fielding say this (no PUT for resources for multiple > representations)? I don't recall seeing it ... > > > > -Lee > > ----- Original Message ----- > > * From:* Mathews, Walden <mailto:waldenm@...> > > * To:* 'Lee Fife' <mailto:lee@...> ; > rest-discuss@yahoogroups.com > <mailto:rest-discuss@yahoogroups.com> > > * Sent:* Wednesday, September 25, 2002 11:28 AM > > * Subject:* RE: [rest-discuss] DELETE semantics > > > Why wouldn't there be a way to DELETE? > > -----Original Message----- > *From:* Lee Fife [mailto:lee@...] > *Sent:* Wednesday, September 25, 2002 1:24 PM > *To:* rest-discuss@yahoogroups.com > <mailto:rest-discuss@yahoogroups.com> > *Subject:* Re: [rest-discuss] DELETE semantics > > I must have missed this -- resources w/ multiple > representations shouldn't support PUT? So, I shouldn't > have an image resource that uses content negotiation to > decide whether to return SVG, JPG, PNG, etc. that also > allows you to PUT a new SVG version of that image? The > only way to update that image is to POST to a > container/manager? And there's no way to DELETE the image? > > > > that can't be right ... > > > > -Lee > > ----- Original Message ----- > > * From:* Chuck Hinson <mailto:cmhinson@...> > > So in the case of resources with multiple > representations, or resources > that have query strings, does it make sense to > constrain DELETE in the > same way the Fielding says PUT is constrained > (resources that have > multiple representation should not support PUT). > > I suspect that it probably isnt reasonable to require > this constraint of > DELETE, but I wonder if it wouldn't be a useful > simplication is many cases. > > Just thinking out loud... > > --Chuck > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms > of Service <http://docs.yahoo.com/info/terms/>. > > > *Yahoo! Groups Sponsor* > ADVERTISEMENT > <http://rd.yahoo.com/M=229441.2397090.3822005.2225242/D=egroupweb/S=1705701014:HM/A=1189558/R=0/*http://www.bmgmusic.com/acq/ee/q6/enroll/mhn/9/> > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service > <http://docs.yahoo.com/info/terms/>.
On Wed, Sep 25, 2002 at 01:37:09PM -0400, Jeffrey Winter wrote: > I would like to apply REST principles to a problem that I am currently working > through, but the current requirements are pushing towards an EBI (i.e., > event-based) solution. > > The issue is that some read-only data is being generated that needs to be > pushed to one particular class of client in near real-time. Some clients can > perform periodic queries against the server to obtain this data, these others > cannot. > > One idea would be to use some peer-to-peer protocol such as BXXP to alert that > class of client that new information was available, perhaps supplying them > with the URL in the message; that client could then GET the representation > using HTTP. > > Obviously there are all the attendant scalability issues with EBI, but I can't > see how to avoid it in this circumstance. > > What does REST have to say about this class of problem? Roy's description of EBI in his dissertation was pretty interesting. But I disagreed with it when he said; "The event-based integration style, also known as the implicit invocation or event system style, reduces coupling between components by removing the need for identity on the connector interface." -- http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_6_1 That's true, sort of. Coupling is reduced, but not because identity is removed from the connector interface - you still need to know the identity of the "bus" 8-) - but because you don't need to know about the identity of the publishers. Anyhow, think of it that way; the bus/channel/topic as a resource. Then visit http://developer.knownow.com. 8-) MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I object to your desire for URI readability; it implies that you are planning to do something unsafe, like use a URI as though it was a function call with parameters. I see no reason why Jill shouldn't pull out her lipstick and her PDA over a candle-lit dinner with John and using the lipstick, write the following URI on her dinner napkin and then hand that to John knowing that neither will be in the mood to surf later, if the evening goes according to expectations. I hope that answers your question. Walden > -----Original Message----- > From: Jeff Bone [mailto:jbone@...] > Sent: Wednesday, September 25, 2002 3:03 PM > To: John Fletcher > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Retraction, advice sought, code offered > > > > On Wednesday, September 25, 2002, at 01:54 PM, John Fletcher wrote: > > > http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 > > Ugh... I was afraid that was how it was going to go. Any other > suggestions that preserve readibility but perhaps torture URI > syntax / > semantics a bit more? ;-) > > jb > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Wednesday, September 25, 2002, at 02:55 PM, Mathews, Walden wrote: > I object to your desire for URI readability; it implies that you > are planning to do something unsafe, like use a URI as though it > was a function call with parameters. See --- THIS is exactly why I rant about URI opacity. It leads the naively dogmatic to make statements like the above! ;-) > I see no reason why Jill shouldn't pull out her lipstick and her > PDA over a candle-lit dinner with John and using the lipstick, write > the following URI on her dinner napkin and then hand that to John > knowing that neither will be in the mood to surf later, if the evening > goes according to expectations. But of course! Now, if she can only remember that URI.... let's see, was that >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 or >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3 of >>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 And if you say "but it's in her PDA," I'd say "well then, why doesn't she just beam it to John's PDA?" If John doesn't have one, maybe Jill doesn't either... now, where's my napkin? jb
John doesn't have a PDA, but if he keeps going out with Jill, he probably will soon, because she sells them. But that's another matter. Jill's PDA has a USB port, so she excuses herself, goes to the ladies room and patches into the HP InkJet printer they keep in there* (this Restaurant is not even in Zagats!), prints the URL on her choice of paper (there are at least 4 trays!), comes out and hands the paper to John, who is so impressed he swallows his olive down the wrong pipe. Jill can't remember the Heimlich Manouver, but no worries, the URL to that is also filed somewhere on her PDA... * This is all done via a complex setup involving an SMC Barricade firewall router -- you don't need to know the wiring details, do you? Meanwhile, at a table in the corner all by himself sits Jeff, who appears to have lost his napkin, of all things. (heh) Walden > -----Original Message----- > From: Jeff Bone [mailto:jbone@...] > Sent: Wednesday, September 25, 2002 4:12 PM > To: Mathews, Walden > Cc: John Fletcher; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Retraction, advice sought, code offered > > > > On Wednesday, September 25, 2002, at 02:55 PM, Mathews, Walden wrote: > > > I object to your desire for URI readability; it implies that you > > are planning to do something unsafe, like use a URI as though it > > was a function call with parameters. > > See --- THIS is exactly why I rant about URI opacity. It leads the > naively dogmatic to make statements like the above! ;-) > > > I see no reason why Jill shouldn't pull out her lipstick and her > > PDA over a candle-lit dinner with John and using the lipstick, write > > the following URI on her dinner napkin and then hand that to John > > knowing that neither will be in the mood to surf later, if > the evening > > goes according to expectations. > > But of course! Now, if she can only remember that URI.... > let's see, > was that > > >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 or >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3 of >>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 And if you say "but it's in her PDA," I'd say "well then, why doesn't she just beam it to John's PDA?" If John doesn't have one, maybe Jill doesn't either... now, where's my napkin? jb
You'll have to parse the URL yourself, but why not break it up using ";": http://host1/res1/res2?parm1=x;host2/res1/res2?parm2=y;host3/x - Winter ----- Original Message ----- From: "Jeff Bone" <jbone@...> To: "Mathews, Walden" <waldenm@...> Cc: "John Fletcher" <john.fletcher@...>; <rest-discuss@yahoogroups.com> Sent: Wednesday, September 25, 2002 4:11 PM Subject: Re: [rest-discuss] Retraction, advice sought, code offered On Wednesday, September 25, 2002, at 02:55 PM, Mathews, Walden wrote: > I object to your desire for URI readability; it implies that you > are planning to do something unsafe, like use a URI as though it > was a function call with parameters. See --- THIS is exactly why I rant about URI opacity. It leads the naively dogmatic to make statements like the above! ;-) > I see no reason why Jill shouldn't pull out her lipstick and her > PDA over a candle-lit dinner with John and using the lipstick, write > the following URI on her dinner napkin and then hand that to John > knowing that neither will be in the mood to surf later, if the evening > goes according to expectations. But of course! Now, if she can only remember that URI.... let's see, was that >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 or >>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3 of >>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 And if you say "but it's in her PDA," I'd say "well then, why doesn't she just beam it to John's PDA?" If John doesn't have one, maybe Jill doesn't either... now, where's my napkin? jb To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
That's fine. My question was rather mundane: assuming some arbitrary syntax / delimiter, does anybody have any existing Python / Apache or other gadgetry that does this? I.e., if I just huck a standard Python CGI up on our Apache server, Apache is going to be "friendly" and flatten out all of the params to pass to the first resource in the pipeline, which will then have to reassemble them. I guess that's trivial, though, isn't it? Just ignore all the params and parse the URI directly. Hmmm... Just wanted to know if anybody done this kind of thing; we discussed it a while back, but I wasn't sure if that was a mostly academic discussion. jb On Wednesday, September 25, 2002, at 03:33 PM, Jeffrey Winter wrote: > You'll have to parse the URL yourself, but why not break it up > using ";": > > http://host1/res1/res2?parm1=x;host2/res1/res2?parm2=y;host3/x > > - Winter > > ----- Original Message ----- > From: "Jeff Bone" <jbone@...> > To: "Mathews, Walden" <waldenm@...> > Cc: "John Fletcher" <john.fletcher@...>; > <rest-discuss@yahoogroups.com> > Sent: Wednesday, September 25, 2002 4:11 PM > Subject: Re: [rest-discuss] Retraction, advice sought, code offered > > > > On Wednesday, September 25, 2002, at 02:55 PM, Mathews, Walden wrote: > >> I object to your desire for URI readability; it implies that you >> are planning to do something unsafe, like use a URI as though it >> was a function call with parameters. > > See --- THIS is exactly why I rant about URI opacity. It leads the > naively dogmatic to make statements like the above! ;-) > >> I see no reason why Jill shouldn't pull out her lipstick and her >> PDA over a candle-lit dinner with John and using the lipstick, write >> the following URI on her dinner napkin and then hand that to John >> knowing that neither will be in the mood to surf later, if the evening >> goes according to expectations. > > But of course! Now, if she can only remember that URI.... let's see, > was that > >>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 > > or > >>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3 > > of > >>>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 > > And if you say "but it's in her PDA," I'd say "well then, why doesn't > she just beam it to John's PDA?" If John doesn't have one, maybe Jill > doesn't either... now, where's my napkin? > > > jb > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Home Selling? Try Us! > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM > --------------------------------------------------------------------- > ~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > > The issue is that some read-only data is being generated that needs to be > pushed to one particular class of client in near real-time. Some clients can > perform periodic queries against the server to obtain this data, these others > cannot. > > What does REST have to say about this class of problem? Model the receiver as a set of resources, then update them as needed in real-time. Essentially, reverse the roles of client and server. With HTTP, this means putting a port 80 listener on the client and handling PUT or POST. The resources don't have to be persisted to disk, or anything like that. Remember - The Web works both ways.
----- Original Message ----- From: "Uday .S" <kumarudaya@...> > Hi, > I am very new to REST and would like to know is there a Open Source REST implementation that i can look at it... > REST is an approach to building large scale networked applications - it isn't an app server, or code library or other implementation. You can learn about the approach and build the concepts into whatever system you are using - JMS, DCOM, SOAP, etc.- or you can build things with HTTP and gear your designs to the concepts outlined by REST. There are many ways to build with any of the many technologies available - REST is just one way to approach solving problems. Mike
Assuming that you have control over all embedded URIs below (z/3 and y/2, anyhow), how about reversing it like: GET http://z/3?GET=http://y/2?GET=http://x/1 z/3 would return a 304 (Found) to: Location: http://y/2?GET=http://x/1&results which would return another 304 to: Location: http://x/1?results which would return your final response. --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Jeff Bone" <jbone@...> To: <rest-discuss@yahoogroups.com> Sent: Wednesday, September 25, 2002 12:48 PM Subject: [rest-discuss] Retraction, advice sought, code offered > > Okay, despite pissing all over the idea of pipelined HTTP requests at > some earlier point, I've come across a situation where this is > absolutely necessary. That is, a situation where it would be nice to > do e.g.: > > GET http://x/1?GET=http://y/2?GET=http://z/3 > > That is, a situation where it would be useful to pass the results of > GETting z/3 as input to y/2 to be transformed, and then passing the > results of that as input to x/1 and getting the result of that > transformation. And it's necessary to do this strictly via a URI, that > is, > > http://x/1?GET=http://y/2?GET=http://z/3 > > or somesuch is the name of this pipelined transformation result. > Various folks around here have advocated this in the past, so I need > some advice: the above won't work since the ? delimited parts of the > query string will be interpreted as separate parameters for x/1. An > alternative syntax for this might be: > > http://x/1/GET=http://y/2/GET=http://z/3 > > ...but it seems like getting e.g. Apache to do the right thing in this > case might be tricky. It's particularly difficult since any of the > sub-URI may themselves have query strings --- the part I'm calling z/3 > in fact has a horrendously long query string of its own that shouldn't > be interpreted by x or y (it's a bugzilla query, fyi.) Anybody have > any suggestions on how to set things up here? Something to do with > mod_rewrite? Examples --- particularly Python code--- much appreciated. > > jb > > BTW --- A colleague up at work wrote a MoinMoin processor that allows > you to embed dot code directly into a Wiki page and have it generate / > render the described graph, if anybody's interested. Also have a piece > of Python code I wrote that turns wiki-style tables plus a "map" > datastructure into a dot graph description... if anybody's interested, > give me a holler. When we get the RESTWiki back up, we should install > this stuff there --- tres useful. We use our Wiki up at work to > coordinate all development specification and planning activities, and a > lot of this stuff is the trivial fruit of some work to integrate Wiki > and bugzilla and automate various dev planning processes. > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> Model the receiver as a set of resources, then update them as needed in > real-time. Essentially, reverse the roles of client and server. > With HTTP, this means putting a port 80 listener on the client and handling > PUT or POST. I actually am considering this for aspects of the system that do not require near real-time notification. For the real-time stuff though my concern is with scalability. As the number of clients grow, the publisher would end up POSTing (synchronously) to large numbers of clients. Even if I were to spin up a bunch of threads to handle this, there could be an intolerable lag waiting for responses. I started to read some of the documentation on the KnowNow.com site, but for some reason I haven't been able to connect to it for a while, So I may be missing something, but they seemed to indicate that they had some mechanism for doing HTTP POST asynchronously, that is, without waiting for a response. If true, that seems like an abuse of HTTP. Why not just choose a protocol that is built to be asynchronous? I'd prefer to stick will well supported standards-based tools if possible. This seems like a class of problem not well suited for REST - the client-server aspect of it anyway; I'll still try to maintain a generic interface, etc. - Jeff
On Thursday, Sep 26, 2002, at 19:47 Europe/Dublin, Jeffrey Winter wrote: > I started to read some of the documentation on the KnowNow.com site, > but > for some reason I haven't been able to connect to it for a while, So > I may be missing something, but they seemed to indicate that they had > some mechanism for doing HTTP POST asynchronously, that is, without > waiting for a response. If true, that seems like an abuse of HTTP. Why > not just choose a protocol that is built to be asynchronous? I'd > prefer > to stick will well supported standards-based tools if possible. i have dreamt of a RESTful protocol built as a BEEP profile to handle situations like this which would just bloat HTTP. i reckon BEEP is quite capable of just about any kind of 1 request-1 response, 1 request-no response (async) or 1 request-n response cycle you can think of. if only there were a perl module on cpan. it allows you to distinguish between the client-server and initiator-listener dichotomies. where in client-server normally the server is the listener and the client is the initiator, you could also have the opposite. if you have a copy of 'BEEP: The Definitive Guide' (o'reilly), check out chapter 4, 'Exchanges'. http://www.oreilly.com/catalog/beep so e.g. a client could connect to your server (through NAT, firewalls, etc.; all you need is TCP) and you could start sending POST methods 'back' to it. i don't know if this is the best solution to your problem but you might want to explore further. of course this is just ramblings on my part; total vapour rather than something you can pick up off the shelf and start writing code with. http://www.beepcore.org/ the website leaves a lot to be desired (e.g. the news has no dates, it's just 'there') but you should be able to at least pull RFC3080. regards, -vincent
The RESTwiki is mostly up, but for some reason the main page is "crashing". Could anybody debug it for me? I have no idea how to decypher what appears here; http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage I reinstalled a new version of MoinMoin, and of Python. Perhaps that has something to do with the problems? Follow-ups to me. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com> Sent: Thursday, September 26, 2002 11:47 AM Subject: Re: [rest-discuss] EBI vs. REST > > Model the receiver as a set of resources, then update them as needed in > > real-time. Essentially, reverse the roles of client and server. > > With HTTP, this means putting a port 80 listener on the client and handling > > PUT or POST. > > I actually am considering this for aspects of the system that do not require > near real-time notification. For the real-time stuff though my concern is > with > scalability. As the number of clients grow, the publisher would end > up POSTing (synchronously) to large numbers of clients. Even if I were > to spin up a bunch of threads to handle this, there could be an intolerable > lag waiting for responses. The POST to multiple clients can happen on one thread if you build it right. You just need asynch IO. You POST to client 1, then POST to client 2, etc. then check for response from client 1 - process it if there, then go on to client 2, etc. With a small thread pool, you could do this reasonably easy. With Java's new NIO, you probably could do it in Java also. Also, what about a cascade of machines? > I started to read some of the documentation on the KnowNow.com site, but > for some reason I haven't been able to connect to it for a while, So > I may be missing something, but they seemed to indicate that they had > some mechanism for doing HTTP POST asynchronously, that is, without > waiting for a response. If true, that seems like an abuse of HTTP. Why > not just choose a protocol that is built to be asynchronous? Thats fine too - you don't lose any REST concepts, but you may have to build up some HTTP concepts. > I'd prefer to stick will well supported standards-based tools if possible. > > This seems like a class of problem not well suited for REST - the > client-server > aspect of it anyway; I'll still try to maintain a generic interface, etc. REST works fine - HTTP may have issues.
Could you do a two-phase approach, use a POST to create the chain and then a GET to read from it? ----- Original Message ----- From: "Jeff Bone" <jbone@...> To: "John Fletcher" <john.fletcher@...> Cc: <rest-discuss@yahoogroups.com> Sent: Wednesday, September 25, 2002 12:03 PM Subject: Re: [rest-discuss] Retraction, advice sought, code offered > > On Wednesday, September 25, 2002, at 01:54 PM, John Fletcher wrote: > > > http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3 > > Ugh... I was afraid that was how it was going to go. Any other > suggestions that preserve readibility but perhaps torture URI syntax / > semantics a bit more? ;-) > > jb > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
Last week Jeff Bone posted: [quote] BTW --- A colleague up at work wrote a MoinMoin processor that allows you to embed dot code directly into a Wiki page and have it generate / render the described graph, if anybody's interested. Also have a piece of Python code I wrote that turns wiki-style tables plus a "map" datastructure into a dot graph description... if anybody's interested, give me a holler. When we get the RESTWiki back up, we should install this stuff there --- tres useful. We use our Wiki up at work to coordinate all development specification and planning activities, and a lot of this stuff is the trivial fruit of some work to integrate Wiki and bugzilla and automate various dev planning processes. [quote] Yes, very interested in the "dot code" processor. I want to post my Alloy models to the REST Wiki, showing graphs of certain instances of the models. Coincidentally, Alloy saves the info in "dot code", so yes this would be very helpful. Also helpful would be if someone knows how to make the processor part of REST Wiki, 'cuz I sure as hell don't. BTW - thanks to Mark and whomever else helped fix REST Wiki. Cheerio, Walden Walden Mathews ILX Systems 111 Fulton St. 3rd Floor New York, NY 10038 Phone (212) 510-3121 Fax (212) 520-3800
On Friday, September 27, 2002, at 12:26 PM, Mathews, Walden wrote:
> Yes, very interested in the "dot code" processor. I want to post my
> Alloy models to the REST Wiki, showing graphs of certain instances of
> the models. Coincidentally, Alloy saves the info in "dot code", so
> yes this would be very helpful. Also helpful would be if someone knows
> how to make the processor part of REST Wiki, 'cuz I sure as hell
> don't.
Pj's moindot processor is available on the moinmoin processor market
page, but it's a slightly outdated version that only allows one graph /
page. (You can set up multiple ones, but the last one is rendered for
every separate graph description. Oops. ;-) The current version we're
using doesn't have this limitation; here it is in all its glory.
Simply drop it into .../processor/moindot.py:
----
"""
MoinDot - WebDot/MoinMoin collaboration macro
Copyright (c) 2002 by Paul Jimenez <pj@...>
"""
import string, sys
def process(request, formatter, lines):
webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
localdir = "/var/www/html/webdot/"
localurl = "http://my.webdot.dir.url/webdot/"
# parse bangpath for arguments
# remove bang path
args=string.split(lines[0])
if len(args) > 1:
dotfilename = "moindot-%s.dot" % args[1]
else:
dotfilename = "moindot.dot"
dotfile = file(localdir+dotfilename,'w')
del lines[0]
for line in lines:
dotfile.write(line)
dotfile.write("\n")
#dotfile.writelines(lines)
dotfile.close()
dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)
sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")
----
To use this, just include dot code in your wikitext as follows:
{{{#!moindot
...dot code goes here...
}}}
Couple of prerequisites: you'll either need to set up the webdot stuff
on the wiki (or other) host OR use one of the open webdot renderers
out on the net somewhere. The webdoturl variable above should point at
that host. The localurl variable needs to contain the base / path for
where the webdot renderer can retrieve the dot code to render ---
that's a directory on the wikihost that should be set up.
Enjoy!
jb
Thanks Jeff! I don't picture me simply dropping that into
anywhere it would make a difference. Hopefully someone else
more empowered than I is reading this thread. 8-)
Walden
> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Friday, September 27, 2002 2:42 PM
> To: Mathews, Walden
> Cc: 'rest-discuss@yahoogroups.com'
> Subject: Re: [rest-discuss] moindot code
>
>
>
> On Friday, September 27, 2002, at 12:26 PM, Mathews, Walden wrote:
>
> > Yes, very interested in the "dot code" processor. I want to post my
> > Alloy models to the REST Wiki, showing graphs of certain
> instances of
> > the models. Coincidentally, Alloy saves the info in "dot code", so
> > yes this would be very helpful. Also helpful would be if
> someone knows
> > how to make the processor part of REST Wiki, 'cuz I sure as hell
> > don't.
>
> Pj's moindot processor is available on the moinmoin processor market
> page, but it's a slightly outdated version that only allows
> one graph /
> page. (You can set up multiple ones, but the last one is
> rendered for
> every separate graph description. Oops. ;-) The current
> version we're
> using doesn't have this limitation; here it is in all its glory.
> Simply drop it into .../processor/moindot.py:
>
> ----
> """
> MoinDot - WebDot/MoinMoin collaboration macro
>
> Copyright (c) 2002 by Paul Jimenez <pj@...>
>
> """
>
> import string, sys
>
> def process(request, formatter, lines):
> webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
> localdir = "/var/www/html/webdot/"
> localurl = "http://my.webdot.dir.url/webdot/"
> # parse bangpath for arguments
> # remove bang path
> args=string.split(lines[0])
> if len(args) > 1:
> dotfilename = "moindot-%s.dot" % args[1]
> else:
> dotfilename = "moindot.dot"
>
> dotfile = file(localdir+dotfilename,'w')
>
> del lines[0]
> for line in lines:
> dotfile.write(line)
> dotfile.write("\n")
> #dotfile.writelines(lines)
> dotfile.close()
>
> dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)
>
> sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")
>
> ----
>
> To use this, just include dot code in your wikitext as follows:
>
> {{{#!moindot
>
> ...dot code goes here...
>
> }}}
>
> Couple of prerequisites: you'll either need to set up the
> webdot stuff
> on the wiki (or other) host OR use one of the open webdot renderers
> out on the net somewhere. The webdoturl variable above
> should point at
> that host. The localurl variable needs to contain the base /
> path for
> where the webdot renderer can retrieve the dot code to render ---
> that's a directory on the wikihost that should be set up.
>
> Enjoy!
>
> jb
>
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > so e.g. a client could connect to your server (through NAT, firewalls, > etc.; all you need is TCP) and you could start sending POST methods > 'back' to it. There was some discussion a while back on this list about doing just this to 'send' to behind-the-firewall resources. The connection is initiated by the protected machine, a 'protocol upgrade' message is sent, and after that it is regular HTTP with the protected machine playing the role of server. A simple form of tunnelling which does not break HTTP in any way - other than intermediaries, which shouldn't be a concern in this situation anyway (since the alternative is a custom protocol).
On Fri, Sep 27, 2002 at 01:26:59PM -0400, Mathews, Walden wrote: > BTW - thanks to Mark and whomever else helped fix REST Wiki. It's not fixed yet. There's that bizarre top line; I have no idea where it's coming from. But it at least appears to be functional. I tried downgrading MoinMoin versions from 1.0 to 0.11, but that didn't fix it. Perhaps I'll downgrade Python. Blah. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
Not really REST per se, but interesting perhaps to RESTwiki users, MoinMoin users, and Python enthusiasts (of which this list has several.) The following code takes a (moin) wiki table description and a python "map" data structure and generates a dot graph description. It could very easily be used by a moin processor ala the pj's moindot processor, but I haven't gotten around to integrating the two yet. (We've been doing a fork-lift database redesign over the last week, two weeks before customer ship --- eegads, where are the razor blades?!? If we can get this done, it'll be phenomenal -- think 1/5th Google (in terms of items for which metadata is stored) in a single appliance, but targeted at storage system management! :-) Enjoy, this is the "result" of a half-day of my week+ family "vacation" / fishing trip last week! :-) jb
Hi, Posting to both lists for better coverage. If you're a "newbie" and you're not interested in formal models, pass this by... I've just created a page on the REST Wiki called "ResourceModel" in which I present a complete (for now at least) structural model of URI, resources, Representations and Variants in the Http resource space. The model is small, but 'checks out'. Hopefully some discussion will ensue. I probably shouldn't have said 'complete'. You be the judge. By the way, the page would be improved by the inclusion of a picture of the "Shared" function, using Jeff's "dotcode" miracle. Cheerio, Walden PS - if you're interested in Alloy, check out <alloy-discuss@yahoogroups.com> sister list.
Ah, finally. Apparently Python has some backwards compatibility issues. MoinMoin 0.9 only works with Python 2.1, not 2.2. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I came across I pretty good summary of the various options. http://www.clipcode.com/peer/http_async_notif.htm ----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, September 27, 2002 3:23 PM Subject: Re: [rest-discuss] EBI vs. REST ----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > so e.g. a client could connect to your server (through NAT, firewalls, > etc.; all you need is TCP) and you could start sending POST methods > 'back' to it. There was some discussion a while back on this list about doing just this to 'send' to behind-the-firewall resources. The connection is initiated by the protected machine, a 'protocol upgrade' message is sent, and after that it is regular HTTP with the protected machine playing the role of server. A simple form of tunnelling which does not break HTTP in any way - other than intermediaries, which shouldn't be a concern in this situation anyway (since the alternative is a custom protocol). To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> > I came across I pretty good summary of the various options. > > http://www.clipcode.com/peer/http_async_notif.htm > Yes - this is a good survey of different approaches. I'm not sure the 'never-ending response' /requires/ two connections. By the way, this is also how KnowNow does stuff (response going to a browser has multiple events, each is picked up by javascript on the client and dispatched to app code on a page). I think the 'TURN' approach is what we've talked about here - Mark or somebody suggested the 'protocol upgrade' aspect of HTTP may be able to help out here. ClipCode says this is 'not standard http' and recommends BEEP, but I think the initiation is the only part not purely HTTP (and even then, it follows the rules of extensions). http://groups.yahoo.com/group/rest-discuss/message/1980 Nobody challenged whether Upgrade is all that is needed for 'client behind firewall' or CONNECT is required - does anybody really know? > > ----- Original Message ----- > From: "S. Mike Dierken" <mdierken@...> > > ----- Original Message ----- > From: "Vincent D Murphy" <vdm@...> > > > so e.g. a client could connect to your server (through NAT, firewalls, > > etc.; all you need is TCP) and you could start sending POST methods > > 'back' to it. > There was some discussion a while back on this list about doing just this to > 'send' to behind-the-firewall resources. > The connection is initiated by the protected machine, a 'protocol upgrade' > message is sent, and after that it is regular HTTP with the protected > machine playing the role of server. A simple form of tunnelling which does > not break HTTP in any way - other than intermediaries, which shouldn't be a > concern in this situation anyway (since the alternative is a custom > protocol). >
On Wed, Oct 02, 2002 at 09:36:39AM -0700, S. Mike Dierken wrote: > http://groups.yahoo.com/group/rest-discuss/message/1980 > Nobody challenged whether Upgrade is all that is needed for 'client behind > firewall' or CONNECT is required - does anybody really know? If you want to send HTTP back through HTTP, as I see it you have two choices; CONNECT or TURN. I don't believe Upgrade is suitable, because its semantics say nothing of flipping client/server, just upgrading to a new protocol. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
I'm not sure everybody interested in Web notifications has noticed, but the world of blogs has built pub/sub mechanisms. Very useful, but not very REST. But of course, that's the way the Web was built too... There are two approaches (that I know of - I'm a newbie to blog infrastructure) - trackback (from MoveableType) - pingback Generally these both allow a blog to subscribe to a different blog - the original blog is then notified when new entries are added to the second blog, etc. Unfortunately, neither use the terms publish, subscribe, notify, etc. very often. The term 'ping' generally means 'notify'. This system is currently used to establish cross-links between items. Since it is a bare-bones pub/sub system, it will grow into more uses. Generally, this is creating a semi-distributed discussion/mail/discussion system. Semi-distributed in the sense that individual entries in a series/thread do not need to reside on a single server, but the messages are still on a server rather than being downloaded to a client (like the way email works). It shows the power of distributed hyper-linking (I'm sure PaulP is all over this...). TrackBack ----------- http://www.movabletype.org/docs/mtmanual_trackback.html TrackBack says they use a REST model for its pings, but they use GET to perform the notification. It's be better to use POST, either with an XML body or a x-www-form-urlencoded (classical form data) body. I haven't found out why they used GET. They also provide a listing of previous notifications (pings) on a particular blog entry. It is assumed that all notifications contain a link to a related posting on a different blog - pretty reasonable in the world of discussion based blogs. MoveableType definitely wants trackback to become more than just blog cross-linking. They are also addressing some security concerns. PingBack ---------- http://www.hixie.ch/specs/pingback/pingback "Pingback is a method for web authors to request notification when somebody links to one of their documents." "The pingback mechanism uses an HTTP header and an HTML or XHTML <link> element for autodiscovery, and uses a single XML-RPC call for notifying the target site of the link on the source site." This seems more cooler... they provide for an HTTP response header X-Pingback, as well as a <link> tag in HTML and XHTML: <link rel="pingback" href="http://charlie.example.com/pingback/xmlrpc"> They also say "HTTP headers are defined to override link elements when they differ." - I wonder if this is wise, given that its easier to change content than response headers. I think this happened with HTTP/HTML <meta http-equiv> tags. They also use XML-RPC instead of pure HTTP. method: pingback.ping description: Notifies the server that a link has been added to sourceURI, pointing to targetURI. It's interesting to consider the difference between notifications (that a link was added) and an explicit request (add a link to the 'referenced-by' collection). Both need a magic name - either 'pingback.ping' (the name of the method) or 'referenced-by' (the name of the collection). With a custom named method, you need another magic name to get a list (apparently not discussed in the pingback spec). With a named collection, you just use GET on that same collection.
S. Mike Dierken wrote: > I'm not sure everybody interested in Web notifications has noticed, but the > world of blogs has built pub/sub mechanisms. Very useful, but not very REST. > But of course, that's the way the Web was built too... > > > There are two approaches (that I know of - I'm a newbie to blog > infrastructure) > - trackback (from MoveableType) > - pingback > > Generally these both allow a blog to subscribe to a different blog - the > original blog is then notified when new entries are added to the second > blog, etc. > Unfortunately, neither use the terms publish, subscribe, notify, etc. very > often. The term 'ping' generally means 'notify'. At Sam Ruby's suggestion, I have spoken with the inventor of trackback about being more REST-y. He's open to the idea but we haven't converged on a final design and development plan yet. He used the term REST in his literature so he was trying to do the right thing but various implementation quirks pushed him towards using non-idempotent GETs. I think future versions will fix that. I don't know anything about PingBack. If there is anything better there maybe it could be incorporated into the TrackBack refactoring. >... > This seems more cooler... they provide for an HTTP response header > X-Pingback, as well as a <link> tag in HTML and XHTML: <link rel="pingback" > href="http://charlie.example.com/pingback/xmlrpc"> Trackback uses RDF. > They also say "HTTP headers are defined to override link elements when they > differ." - I wonder if this is wise, given that its easier to change content > than response headers. I think this happened with HTTP/HTML <meta > http-equiv> tags. > > They also use XML-RPC instead of pure HTTP. > method: pingback.ping > description: Notifies the server that a link has been added to sourceURI, > pointing to targetURI. At least it is using POST as POST instead of as GET. > It's interesting to consider the difference between notifications (that a > link was added) and an explicit request (add a link to the 'referenced-by' > collection). Both need a magic name - either 'pingback.ping' (the name of > the method) or 'referenced-by' (the name of the collection). With a custom > named method, you need another magic name to get a list (apparently not > discussed in the pingback spec). With a named collection, you just use GET > on that same collection. That's what I've been suggesting. POST extends the collection of trackbacks. GET returns the list of trackbacks. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > At Sam Ruby's suggestion, I have spoken with the inventor of trackback > about being more REST-y. He's open to the idea but we haven't converged > on a final design and development plan yet. Let me know if I can help out - I have some free time on my hands. I'm installing MoveableType and will be playing around with it. > He used the term REST in his > literature so he was trying to do the right thing but various > implementation quirks pushed him towards using non-idempotent GETs. I > think future versions will fix that. > >... > > This seems more cooler... they provide for an HTTP response header > > X-Pingback, as well as a <link> tag in HTML and XHTML: <link rel="pingback" > > href="http://charlie.example.com/pingback/xmlrpc"> > > Trackback uses RDF. But this one goes to eleven! http://spinaltapfan.com/atozed/TAP00160.HTM
I just got an email from Benjamin that indicates that future versions of TrackBack will treat URIs totally opaquely on the client, will use POST for "notify" and after backwards compatibility issues have been cleared, GETs will be freed up and probably used to report on the list of things that were POSTed. Also some minor issues with RDF will probably be cleaned up and they are working on deeper integration with RSS. Paul Prescod
Sorry guys, I haven't been following closely but from previous thinking I strongly believe that there is a really useful RFC potential in a simple mechanism to turn around an HTTP connection. It isn't that different than launching SSL from HTTP. http://rfc.sunsite.dk/rfc/rfc2817.html Sorry for jumping in the middle. Wasted my email time today on TAG. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > Sorry guys, I haven't been following closely but from previous thinking > I strongly believe that there is a really useful RFC potential in a > simple mechanism to turn around an HTTP connection. It isn't that > different than launching SSL from HTTP. > http://rfc.sunsite.dk/rfc/rfc2817.html > > Sorry for jumping in the middle. Wasted my email time today on TAG. > I think there is a lot in there that is good - but I'm not sure what HTTP method we'd apply the Upgrade header to. It is really a server operation, not a per-resource operation. I don't know the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking. So what are the choices? a) Upgrade header - what method(s) or resources would this apply to? (probably OPTIONS...) - is it sufficiently like keep-alive that is applies to multiple requests? - am I worrying over nothing regarding Upgrade and multiple resources/methods? b) CONNECT method - how would this work? - CONNECT seems to be per-host rather than per-resource (you couldn't have multiple resources, one per 'message queue'- but this might simplify security/authority issues) - what is CONNECT used for anyway? Is it for tunning a /different/ protocol over port 80 to a destination system? c) new method (TURN or something)
S. Mike Dierken wrote: > ----- Original Message ----- >... > > I think there is a lot in there that is good - but I'm not sure what HTTP > method we'd apply the Upgrade header to. They use OPTIONS. Why not copy? > It is really a server operation, not a per-resource operation. I don't know > the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking. I think that RFC 2817 bears study. I'd almost use it as a template for a new one. > So what are the choices? > a) Upgrade header > - what method(s) or resources would this apply to? (probably OPTIONS...) > - is it sufficiently like keep-alive that is applies to multiple requests? It applies to the *socket*. You are switching protocols from HTTP to "Reverse HTTP" which happens to have identical syntax and semantics to HTTP except you never create a Reverse HTTP connection directly, you always get one by reusing an ordinary HTTP socket. > - am I worrying over nothing regarding Upgrade and multiple > resources/methods? > > b) CONNECT method > - how would this work? > - CONNECT seems to be per-host rather than per-resource (you couldn't have > multiple resources, one per 'message queue'- but this might simplify > security/authority issues) > - what is CONNECT used for anyway? Is it for tunning a /different/ protocol > over port 80 to a destination system? Yes. Like HTTPS or "Reverse HTTP". > c) new method (TURN or something) I don't think that there is a need for it. Paul Prescod
Now that the REST wiki is back up, would it be possible to
install this? I'd like to experiment with pictures.
Walden
> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Friday, September 27, 2002 2:42 PM
> To: Mathews, Walden
> Cc: 'rest-discuss@yahoogroups.com'
> Subject: Re: [rest-discuss] moindot code
>
>
>
> On Friday, September 27, 2002, at 12:26 PM, Mathews, Walden wrote:
>
> > Yes, very interested in the "dot code" processor. I want to post my
> > Alloy models to the REST Wiki, showing graphs of certain
> instances of
> > the models. Coincidentally, Alloy saves the info in "dot code", so
> > yes this would be very helpful. Also helpful would be if
> someone knows
> > how to make the processor part of REST Wiki, 'cuz I sure as hell
> > don't.
>
> Pj's moindot processor is available on the moinmoin processor market
> page, but it's a slightly outdated version that only allows
> one graph /
> page. (You can set up multiple ones, but the last one is
> rendered for
> every separate graph description. Oops. ;-) The current
> version we're
> using doesn't have this limitation; here it is in all its glory.
> Simply drop it into .../processor/moindot.py:
>
> ----
> """
> MoinDot - WebDot/MoinMoin collaboration macro
>
> Copyright (c) 2002 by Paul Jimenez <pj@...>
>
> """
>
> import string, sys
>
> def process(request, formatter, lines):
> webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
> localdir = "/var/www/html/webdot/"
> localurl = "http://my.webdot.dir.url/webdot/"
> # parse bangpath for arguments
> # remove bang path
> args=string.split(lines[0])
> if len(args) > 1:
> dotfilename = "moindot-%s.dot" % args[1]
> else:
> dotfilename = "moindot.dot"
>
> dotfile = file(localdir+dotfilename,'w')
>
> del lines[0]
> for line in lines:
> dotfile.write(line)
> dotfile.write("\n")
> #dotfile.writelines(lines)
> dotfile.close()
>
> dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)
>
> sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")
>
> ----
>
> To use this, just include dot code in your wikitext as follows:
>
> {{{#!moindot
>
> ...dot code goes here...
>
> }}}
>
> Couple of prerequisites: you'll either need to set up the
> webdot stuff
> on the wiki (or other) host OR use one of the open webdot renderers
> out on the net somewhere. The webdoturl variable above
> should point at
> that host. The localurl variable needs to contain the base /
> path for
> where the webdot renderer can retrieve the dot code to render ---
> that's a directory on the wikihost that should be set up.
>
> Enjoy!
>
> jb
>
On Thu, Oct 03, 2002 at 11:45:38AM -0400, Mathews, Walden wrote: > Now that the REST wiki is back up, would it be possible to > install this? I'd like to experiment with pictures. Sure. Some install directions would help. We're using MoinMoin 0.9, which may be a problem. Let's take this off-line too. If we get it working, we'll announce it back here. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@... http://www.markbaker.ca http://www.idokorro.com
A while ago I posted a trial baloon on rest-discuss about a decentralized REST auction idea. http://groups.yahoo.com/group/rest-explore/message/96 The response was so underwhelming that I concluded the baloon may be of the lead variety. And I got busy with other things and never followed up properly. But now I see an independent emergence of the same idea from Joe Gregorio: http://bitworking.org/wellformed.html Joe's even got some implementation ideas. And he refers to REST, as well. Plus, I see Phil Eskelin noticed the idea: http://groups.yahoo.com/group/rest-discuss/message/2706 So maybe it's worth porting to rest-discuss and see if's got legs. Joe and I had a little email exchange about it, as follows: [Joe, responding to my ping] Interesting. I had come at it from an RDF angle and not web services. Given the interest I'll try putting together a quick implementation of this. [Joe's article also spawned a thread on xml-dev] Have you done any work on an implementation? [Bob] No. Busy with other things. Where I was gonna focus next was on binding the bids to the ad, and the ad to the winning bid. Then a little work on the non-repudiation angle - you don't really need to repeat the representations, just the digests. [I was thinking of Paul's URL + hash format] The other thing I was thinking is to relax the "biddingEnds" so as to eliminate sniping. Do it more like a regular auction - going, going, gone. But of course at the option of the advertiser [Joe] Oooh, neat idea. If you think of it that way then this replaces auctions and classified ads all at the same time. [Bob] Yes. What I have in mind is offers of all kinds: offers to sell, offers to buy, offers to barter, offers of services, you name it. I don't see any reason why any of this stuff can't be decentralized.
----- Original Message ----- From: "Paul Prescod" <paul@...> To: "S. Mike Dierken" <mdierken@...> Cc: <rest-discuss@yahoogroups.com> Sent: Thursday, October 03, 2002 12:23 AM Subject: Re: [rest-discuss] EBI vs. REST > S. Mike Dierken wrote: > > ----- Original Message ----- > >... > > > > I think there is a lot in there that is good - but I'm not sure what HTTP > > method we'd apply the Upgrade header to. > > They use OPTIONS. Why not copy? Yes, I think that would work. > > c) new method (TURN or something) > > I don't think that there is a need for it. I think maybe a 'PROXY' method (requesting that the server begin acting as a type of proxy) might make sense. If CONNECT has a way to advertise what particular protocol will be 'tunnelled' - like "HTTP-Reverse/1.1" - then proxies will still be able to participate (caching, cache purging, etc.). Although I don't really care if proxies are involved. I see two scenarios for this technology - a) expose private machine on public Web the private machine wants to be public but can't accept incoming connections so the public machine proxies that job Useful for dynamic IP allocation, either due to ISP allocated addresses or through 'nomadic/mobile' use. Other approaches like dyndns.org may solve the host/ip mapping issue, but not incoming connection issues. This turns the client into a server - which means you need more security and either multiple connections or multiplexing messages on a single connection. b) low-latency application messaging where a private machine just wants low-latency messages to an application but can't accept incoming connections. This may be useful for smaller devices - the public machine can do all the security, high-level policy stuff and connection management, and the small device can stay simple. I do not want to 'tunnel' stuff through a firewall - I'm not into smuggling information. Either you are the firewall admin & can open up the port, or you are not the admin and you /shouldn't/ open up the port. The third alternative is that the firewall admin doesn't care to let you listen - like an ISP that restricts incoming requests. This situation would benefit from a generic 'reverse http connector' - like an Apache mod (or hack) that did the proper socket management.
Bob wrote: > Plus, I see Phil Eskelin noticed the idea: > http://groups.yahoo.com/group/rest-discuss/message/2706 > > So maybe it's worth porting to rest-discuss and see if's got legs. I was wondering if you were registering on my interest in REST-Bay, and I assumed you were busy at the time and couldn't respond. Anyway, I think REST-Mail and REST-Bay are great examples that would help people get it. I too have been very busy in the last few weeks. Hence I haven't made as much progress as I wanted to when I posted message 2706, but I can promise you that once I release v1.0 of this toolkit, I will move focus to 1) responding to feedback from this group and 2) implementing sample programs. Thanks, Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
Hello everyone, I have been interrested in the web services architecture debates for about a year now. I read in one of the messages here that GET and POST have different uses. How is this true? And while we're at it, what's a good reference to understand the four transactions supported by HTTP? How about good background reading on HTTPS? Any information is appreciated, Geoffrey
----- Original Message ----- From: "noxavior" <noxavior@...> > Hello everyone, I have been interrested in the web services architecture debates for about a year now. > I read in one of the messages here that GET and POST have different uses. How is this true? With HTTP, a request message identifies a resource and an operation upon that resource. These operations are the methods as specified in the HTTP spec - http://www.w3.org/Protocols/rfc2616/rfc2616.html A GET message is requesting a representation of the resource identified by the URL (also called the URI). A POST message is requesting that data carried along with the request be used by the resource to 'extend' the resource. This 'extend' could be many things. For example, it could add an entry to a log, or add a file to a directory, etc. If a new resource is created, the response to the POST request can identify the URL of this new resource. > And while we're at it, what's a good reference to understand the four transactions supported by HTTP? HTTP has more than four methods - and new methods can be added. The spec has good detail, but I would like to see other descriptions also. I once read a book with a frog on it that talked alot about HTTP, but haven't seen it in a while. > How about good background reading on HTTPS? I don't know.
> Probably more a rest-discuss question, but .. ok. moved from rest-explore... >> On Wed, Oct 09, 2002 at 10:55:07AM -0400, Jeffrey Winter wrote: >> When PUTing a representation, is it the requirement that the >> entity-body will be stored as-is, or only that the representation >> not vary on GET? >> >> So in other words, if I accept the following PUT: >> >> <a><b/></a> >> >> is it okay to respond to a GET with: >> >> <a> >> <b/> >> </a> > No. Do intermediaries actually depend on this or is it just the semantics of the method itself? >> so long as that response does vary based on the headers? >> Or is the expectation that GET actually responds with >> the exact same representation that was PUT? > Yes. > > This is why we need "SET", which could do this. SET could be used with > SOAP, while PUT can't (at least as you'd expect it to be used). The SOAP PUT issue was actually one of the issues that I was wondering about. How could it really work at all? Do you envision this "SET" method allowing partial resource updates?
On Wed, Oct 09, 2002 at 11:35:12AM -0400, Jeffrey Winter wrote:
> >> On Wed, Oct 09, 2002 at 10:55:07AM -0400, Jeffrey Winter wrote:
> >> When PUTing a representation, is it the requirement that the
> >> entity-body will be stored as-is, or only that the representation
> >> not vary on GET?
> >>
> >> So in other words, if I accept the following PUT:
> >>
> >> <a><b/></a>
> >>
> >> is it okay to respond to a GET with:
> >>
> >> <a>
> >> <b/>
> >> </a>
>
> > No.
Has it been stipulated somewhere that the GET request is asking for the
same representation type that was PUT? If not, I don't understand why
that wouldn't be allowed. The two documents would appear to be variant
representations of the same resource (or perhaps I should say of each
other, since we don't know what the resource is).
--
Matt Gushee When a nation follows the Way,
Englewood, Colorado, USA Horses bear manure through
mgushee@... its fields;
http://www.havenrock.com/ When a nation ignores the Way,
Horses bear soldiers through
its streets.
--Lao Tzu (Peter Merel, trans.)
Hi,
this might actually be an FAQ question, but I want to make
sure not just 'legal HTTP' but also RESTful:
Can I POST to a URI that contains a query string ?
Example (adding a link to a linklist) :
POST /linklist?subject=travel HTTP/1.0
Host: www.myhost.com
Content-Length: 28
http://www.cheaptravel.com
Would this be OK ?
Would it be OK in an HTML <form action="..." method="POST">
element to specify an action URL that contains a query string ?
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
Hi On Thu 10-Oct-2002 at 07:09:02PM +0200, Jan Algermissen wrote: > > Can I POST to a URI that contains a query string ? We haven't had any luck doing that with Apache and Perl, the result is always the same as posting without the query string. Populating the form with the information from the query string seems the most logical thing to do. Chris -- Chris Croome <chris@...> web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/
----- Original Message ----- From: "Jan Algermissen" <algermissen@...> > Can I POST to a URI that contains a query string ? Absolutely. > > Example (adding a link to a linklist) : > > POST /linklist?subject=travel HTTP/1.0 > Host: www.myhost.com > Content-Length: 28 > > http://www.cheaptravel.com > > Would this be OK ? Definitely. > > > > Would it be OK in an HTML <form action="..." method="POST"> > element to specify an action URL that contains a query string ? Yes. The only caution I would have is when server tools parse the request, they don't always do it right. Often they provide a request property called 'parameters' - but there is no such thing in the protocol. This usually is a blending of the query terms from the resource identifier and the name/value pairs from the content being posted. Another example where common tools are broken with respect to using the protocol correctly. Often, you will have to explicitly get the query terms separate from the form data. I think ASP pages can do this relatively easily. If the names between query terms and content body are the same you may have problems, so I'd recommend avoiding that. Mike
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > > i have mod_rewrite rules in apache which do the following: > > /contributors/?foo=bar becomes > /cgi-bin/contributors/index.cgi?foo=bar > /contributors/12345 becomes > /cgi-bin/contributors/one.cgi?id=12345 > /contributors/12345?foo=bar becomes > /cgi-bin/contributors/one.cgi?id=12345&foo=bar > > and so on. each CGI script handles all requests (GET, POST for know > because that's all the clients support). This is very nice - what do the rules look like? (I don't know the Apache syntax) This is a good idea even independent of REST since the public URL doesn't have name of the implementation file (one.cgi) which could change if the system migrates to another technology (e.g. one.jsp). The URLs have a longer lifetime and this is good.
here's my .htaccess. RewriteEngine on RewriteBase /foo RewriteRule ^contributors$ contributors/ [R=permanent] RewriteRule ^contributors/$ cgi/contributors/index.pl.cgi RewriteRule ^contributors/([0-9]+)[/]?$ cgi/contributors/one.pl.cgi?id=$1 RewriteBase sets the 'root' of your URL. it could be just slash /, but i used /foo because there are other things living on the root of the same httpd. overall i found mod_rewrite to be a total pain in the ass (it took me a whole day to come up with these simple rules) but i'm of the opinion that it was worth it.
[yahoo groups was bouncing my mail, so i'm reposting this.] On Thursday, Oct 10, 2002, at 21:24 Europe/Dublin, S. Mike Dierken wrote: > The only caution I would have is when server tools parse the request, > they > don't always do it right. Often they provide a request property called > 'parameters' - but there is no such thing in the protocol. This > usually is a > blending of the query terms from the resource identifier and the > name/value > pairs from the content being posted. Another example where common > tools are > broken with respect to using the protocol correctly. agreed. in perl, pretty much all of the CPAN CGI modules (including the erst-while CPAN.pm) advertise this breakage as a feature (although to be fair i guess not many people care outside of those who are aware of REST), and you have to explicitly configure the modules to distinguish between the url-encoded entity body and the query string. i just read STDIN or the QUERY_STRING environment variable and use a hash keyed on the value of Content-type header to pick out an appropriate parser. if you want me to elaborate on this chris, let me know; i have a CGI script doing this. i'm using this in combination with mod_rewrite to have nice URIs which reflect the hierarchy. this isn't strictly a requirement of being RESTful; i just like it this way. it keeps verbs out of the URIs, they only have nouns in them. i am working on a system for tracking fund-raising. i have mod_rewrite rules in apache which do the following: /contributors/?foo=bar becomes /cgi-bin/contributors/index.cgi?foo=bar /contributors/12345 becomes /cgi-bin/contributors/one.cgi?id=12345 /contributors/12345?foo=bar becomes /cgi-bin/contributors/one.cgi?id=12345&foo=bar and so on. each CGI script handles all requests (GET, POST for know because that's all the clients support). i'm toying with the idea of boiling this stuff down into a CPAN module called CGI::Resource or something; maybe when i have a bit more experience of how well this works in practice. if anybody wants boilerplate source shout. to answer your question, POSTing to a URI with a querystring is definitely possible, and probably OK. i prefer to use querystrings for queries parameters only as much as possible, but pragmatism wins out easily over that most of the time. the tool support for eliminating querystrings except for queries isn't really there (yet). hence my wrestling with mod_rewrite. regards, -vincent
Chris Croome wrote:
>
> Hi
>
> On Thu 10-Oct-2002 at 07:09:02PM +0200, Jan Algermissen wrote:
> >
> > Can I POST to a URI that contains a query string ?
>
> We haven't had any luck doing that with Apache and Perl, the result
> is always the same as posting without the query string.
Hmm, technically I will be writing an Apache module. Am I correctly assuming
that Apache itself does not have problems with this ?
The reason why I need to use a query string is that URIs will be part of
my web service URIs
Here is a fictitious example:
Suppose there is a web service that serves manuals for all kinds
of technical goods, among them air conditioner XYZ. Also suppose that
the only way to tell the services which machine's manual I need to see
is via a URI. I would have to issue requests such as
GET /documentation/manuals?item=http://www.brandX.com/products/air-contitioners#XYZ
(not url encoded for clarity)
Would there be any way to put the air conditioner's URI into the service's
URI other than via a query string ?
Jan
>
> Populating the form with the information from the query string
> seems the most logical thing to do.
>
> Chris
>
> --
> Chris Croome <chris@...>
> web design http://www.webarchitects.co.uk/
> web content management http://mkdoc.com/
> everything else http://chris.croome.net/
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
----- Original Message ----- From: "Jan Algermissen" <algermissen@...> > Here is a fictitious example: > > Suppose there is a web service that serves manuals for all kinds > of technical goods, among them air conditioner XYZ. Also suppose that > the only way to tell the services which machine's manual I need to see > is via a URI. I would have to issue requests such as > > GET /documentation/manuals?item=http://www.brandX.com/products/air-contitioners# XYZ > > (not url encoded for clarity) > > Would there be any way to put the air conditioner's URI into the service's > URI other than via a query string ? If this is not purely a pass-through - the brandX.com is a registered data entity on your server - then you don't have to have http: in there. You would use an id that your server knew about, do the lookup to the base URL for the third party, and merge some text strings. If you don't need the protocol portion, you can just put it in a path segment (between the '/' characters). You can define for your internal implementation that any segments past a certain point are part of the other site. GET /documentation/manuals/www.brandX.com/products/air-contitioners#XYZ If you do need the protocol, then you probably need a query string.
Paul, Just cleaning out my inbox and I found this message from you. I had saved it because it hinted at the potential value of some mathematical models aimed at clarifying HTTP method semantics. Since then, about a month has passed, during which time myself and a few others who read the rest-explore list have been experimenting with such models, and probably now have enough skill with one particular modeling language (Alloy) to be able to do what you suggest below, notably: "Roy describes a very mathematical mode for HTTP (resource is a mapping etc.) and if the HTTP methods were described in those terms it would be much easier to build interoperable software." I think, for one reason or another, we've gone off more in the direction of a pure REST model, rather than an HTTP model, probably mostly because those famous two sentences from Roy's thesis are about all we really have to go on... Could you please comment on this effort and your current thoughts about it. I have been unsuccessful to date in trying to interest Roy in the benefits of developing such models. That makes it harder to know what it is we're modeling, and on whose authority, but it's still possible to build a small set of models, each of which clarifies a particular interpretation of an HTTP method. If not authority, at least it might lend some clarity, especially if we can leverage graphical representations of the models as a more accessable form for general consumption. Perhaps the modeling effort converges on a small number of method usage patterns, which could then be named, and those names might become useful to applications that want to extend the HTTP contract? You haven't said anything about this since mid-September, so an update from you would be quite valuable, I think. Thanks, Walden > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Wednesday, September 18, 2002 4:31 PM > To: S. Mike Dierken > Cc: Roy T. Fielding; rest-discuss > Subject: [rest-discuss] Re: Resources always exist > > > S. Mike Dierken wrote: > > ----- Original Message ----- > > From: "Paul Prescod" <paul@...> > > > >>If you DELETE something twice, you usually expect an error > message or a > >>core dump. > > > > Do you mean 'delete' in the classic programming language > sense (releasing > > system memory, calling destructors, etc.) or do you mean > the HTTP concept of > > DELETE? > > The fact that there is potentially a divergence there is exactly my > point. It's okay for HTTP to diverge but if the spec doesn't > say clearly > one way or another, then people will just guess. HTTP says basically > "DELETE means you should delete." > > Roy describes a very mathematical mode for HTTP (resource is > a mapping > etc.) and if the HTTP methods were described in those terms > it would be > much easier to build interoperable software. > > There are hints that it was politics that prevented this from > happening > the first time around, but what should we do about it now? > Just transmit > the true meanings of the methods through mailing lists? > Increment HTTP? > Write an RFC clarifying? Wait for Roy's new protocol? I'm > being serious > here: I think that there is a problem and a variety of > solutions and am > soliciting opinions on both issues. > > Paul Prescod > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > 4 DVDs Free +s&p Join Now > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085 Can you do the same exercise with POST, PUT and DELETE? That would be a valuable set of articles. Paul Prescod
On Tue, Oct 15, 2002 at 09:27:26AM -0700, Paul Prescod wrote: > http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085 > > Can you do the same exercise with POST, PUT and DELETE? That would be a > valuable set of articles. I'll add it to my to-do list. Ick. POST would be fun though. BTW, my to-do list is one item smaller today (well, until that last paragraph 8-); Webdot is now integrated into the RESTwiki, and the Wiki itself was upgraded to Moin-1.0, so we've got a whole bunch of new features including the rather annoying and unRESTful navigation bar that shows you your navigation path through the Wiki. See my page for an example of Webdot/Moindot; http://internet.conveyor.com/RESTwiki/moin.cgi/MarkBaker P.S. I had to patch a bug in Jeff's moindot.py code; dotfile = file(localdir+dotfilename,'w') -> dotfile = open(localdir+dotfilename,'w') MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
On Tuesday, Oct 15, 2002, at 17:27 Europe/Dublin, Paul Prescod wrote: > http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085 > > Can you do the same exercise with POST, PUT and DELETE? That would be a > valuable set of articles. ditto! explaining it as a matter of increasing generality emphasizes why GET et al are 'axiomatic'. this is something i can send my non-believer colleagues.
> BTW, my to-do list is one item smaller today (well, until that last > paragraph 8-); Webdot is now integrated into the RESTwiki, and the > Wiki itself was upgraded to Moin-1.0, so we've got a whole bunch of > new features including the rather annoying and unRESTful navigation > bar that shows you your navigation path through the Wiki. Yipee!! I enabled the dotcode on WebState already. Looks purdy. -Walden
Mark Baker wrote: >... > > P.S. I had to patch a bug in Jeff's moindot.py code; > > dotfile = file(localdir+dotfilename,'w') > -> > dotfile = open(localdir+dotfilename,'w') Not a bug, a version skew. Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> id(file) 679816 >>> id(open) 679816 >>> file is open 1 Essentially open() is a C-ism but file() allows you to think of it as a constructor for an object (which it is). Presumably sometime when our children are programmers, the "open" spelling will be removed or strongly deprecated. Paul Prescod
On Tuesday, October 15, 2002, at 04:30 PM, Paul Prescod wrote:
> Mark Baker wrote:
>> ...
>>
>> P.S. I had to patch a bug in Jeff's moindot.py code;
Wouldn't be surprising. ;-) (Last-minute pre-customer build frenzy,
I've crashed the build at work twice today with untested changes
including single-character ytpos...)
>> dotfile = file(localdir+dotfilename,'w')
>> ->
>> dotfile = open(localdir+dotfilename,'w')
>
> Not a bug, a version skew.
Yup, sorry 'bout that, should've noted it. WORKSFORME. ;-)
> Essentially open() is a C-ism but file() allows you to think of it as a
> constructor for an object (which it is). Presumably sometime when our
> children are programmers, the "open" spelling will be removed or
> strongly deprecated.
Interesting bit I just learned recently... in (a) recent Python
version (?) file objects are implicitly iterators, meaning you can do
the following:
for line in file:
print line # or whatever
jb
Hi Folks,
I have created a step-by-step guide to building XML-based Web Services.
The tutorial employs the REST architectural style.
Here is the online, HTML version of the tutorial:
http://www.xfront.com/WS/XML-based-Web-Services.html
Here is the web page to download a zip file containing the tutorial
along with all the XML documents, stylesheets, database, labs, etc
(warning: the zip file is big! --> 50MB):
http://www.xfront.com/XML-based-Web-Services.html
/Roger
----- Original Message ----- From: "Roger L. Costello" <costello@...> > > Here is the online, HTML version of the tutorial: > > http://www.xfront.com/WS/XML-based-Web-Services.html > Neat. (although it would be nice if the text were text and not a graphic) A few comments. In general I'd like to see some discussion of why providing machine-to-machine access through a SQL connection is a Bad Thing. Or is it? Slide 39 of 136 You might mention that a different app may want to return some amount of metadata, rather than requiring another request for each line item. Otherwise you might have a query explosion. If it turns out to be a problem - just adjust the 'listing' format to include metadata, or have another resource with slightly a 'deeper' view over the information. Slide 54 of 136 You may want to mention that alternate approaches to getting XML from an RDBMS would not need an extra transformation step. This is - once again - an optimization/performance issue.
Hi all, At the recent Web Services DevCon I did a talk on REST & SOAP, and how they can be combined in a RESTful manner. The slides are at [1] - I'd be interested in any feedback this group has to help me improve the talk. Thanks especially to all the participants in this group (which I've been lurking in for ages now :-)) for helping to shape my thinking on REST & SOAP. I'm hoping that RESTful SOAP will start to gain traction as people figure out that REST & SOAP can be complimentary and that RESTian thinking contains some important ideas. --Peter http://www.razorsoft.net/weblog http://staff.develop.com/peterd [1] http://www.razorsoft.net/weblog/2002/10/22.html#a362
Any chance of converting powerpoint to html so those of us without powerpoint can look at the slides too. --Chuck Peter Drayton wrote: >Hi all, > >At the recent Web Services DevCon I did a talk on REST & SOAP, and how >they can be combined in a RESTful manner. The slides are at [1] - I'd be >interested in any feedback this group has to help me improve the talk. > >Thanks especially to all the participants in this group (which I've been >lurking in for ages now :-)) for helping to shape my thinking on REST & >SOAP. I'm hoping that RESTful SOAP will start to gain traction as people >figure out that REST & SOAP can be complimentary and that RESTian >thinking contains some important ideas. > >--Peter >http://www.razorsoft.net/weblog >http://staff.develop.com/peterd > >[1] http://www.razorsoft.net/weblog/2002/10/22.html#a362 > > > >To unsubscribe from this group, send an email to: >rest-discuss-unsubscribe@yahoogroups.com > > > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
----- Original Message ----- From: "Peter Drayton" <peter@...> > At the recent Web Services DevCon I did a talk on REST & SOAP, and how > they can be combined in a RESTful manner. The slides are at [1] - I'd be > interested in any feedback this group has to help me improve the talk. Any chance I could get a representation of this resource in an HTML format (or text, or XML, or something)?
Certainly! I've just posted PDF [1] & HTML [2] versions as well. Note that there's a small animation [3] on slide 3, which gets mangled in the PDF & static HTML versions - either use the PPT itself, or the "slideshow" option on the HTML version if you care. --Peter [1] http://www.razorsoft.net/slides/RESTfulSOAP.pdf [2] http://www.razorsoft.net/slides/RESTfulSOAP/RESTfulSOAP.htm [3] The animation is 2 circles, one labelled HTML and one labelled OO/RPC, representing the 2 distinct worlds that application developers tended to fall into in the mid-90s. The labels then change to REST and SOAP, representing the evolution of the two viewpoints (My assertion is if you're an HTML & Web App person, REST seems natural. Similarly, if you're used to DCOM, CORBA, etc. SOAP seems fine & dandy). The circles then move to overlap partially, and a question-mark appear in the overlap area. This represents the point of intersection of the 2 models, which is also one of the pain points. I don't believe this is a coincidence. The thesis for my talk is that this area of intersection (called RESTful SOAP) is actually a good thing, as it provides an opportunity for SOAP to learn valuable architectural lessons from REST, and an opportunity for REST to benefit from SOAP's widespread acceptance among corporate developers. > -----Original Message----- > From: Chuck Hinson [mailto:cmhinson@...] > Sent: Wednesday, October 23, 2002 9:49 AM > To: Peter Drayton > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] RESTful SOAP presentation > > > Any chance of converting powerpoint to html so those of us without > powerpoint can look at the slides too. > > --Chuck > > Peter Drayton wrote: > > >Hi all, > > > >At the recent Web Services DevCon I did a talk on REST & > SOAP, and how > >they can be combined in a RESTful manner. The slides are at > [1] - I'd be > >interested in any feedback this group has to help me improve > the talk. > > > >Thanks especially to all the participants in this group > (which I've been > >lurking in for ages now :-)) for helping to shape my > thinking on REST & > >SOAP. I'm hoping that RESTful SOAP will start to gain > traction as people > >figure out that REST & SOAP can be complimentary and that RESTian > >thinking contains some important ideas. > > > >--Peter > >http://www.razorsoft.net/weblog > >http://staff.develop.com/peterd > > > >[1] http://www.razorsoft.net/weblog/2002/10/22.html#a362 > > > > > >------------------------ Yahoo! Groups Sponsor > ---------------------~--> > >Get 128 Bit SSL Encryption! > >http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W6uqlB/TM > >------------------------------------------------------------- > --------~-> > > > >To unsubscribe from this group, send an email to: > >rest-discuss-unsubscribe@yahoogroups.com > > > > > > > >Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > > > > >
Thanks for the presentation Peter, it was most excellent. Some comments below ... On Wed, Oct 23, 2002 at 10:21:53AM -0700, Peter Drayton wrote: > [3] The animation is 2 circles, one labelled HTML and one labelled > OO/RPC, representing the 2 distinct worlds that application developers > tended to fall into in the mid-90s. The labels then change to REST and > SOAP, representing the evolution of the two viewpoints (My assertion is > if you're an HTML & Web App person, REST seems natural. Similarly, if > you're used to DCOM, CORBA, etc. SOAP seems fine & dandy). The circles > then move to overlap partially, and a question-mark appear in the > overlap area. This represents the point of intersection of the 2 models, > which is also one of the pain points. I don't believe this is a > coincidence. The thesis for my talk is that this area of intersection > (called RESTful SOAP) is actually a good thing, as it provides an > opportunity for SOAP to learn valuable architectural lessons from REST, > and an opportunity for REST to benefit from SOAP's widespread acceptance > among corporate developers. I think you did a good job in the presentation of staying away from suggesting that the term "SOAP" suggested a use, but here you appear to do just that. SOAP is certainly well deployed, but the problem is that "SOAP" means "RPC" (either explicitly or implicitly) to practically everybody who uses it. And while I'm all for using SOAP with REST - indeed, I spent a substantial amount of time and my own money in the XMLP WG ensuring that I could - I don't think that "widespread acceptance" is sufficient when it's being misused. We need a *MASSIVE* educational campaign to fix this. And IMO, it's too late; just look at all the secondary specs written by the supposed *gurus* of Web services; chroeography, transactions, coordination. All crap. If these people don't understand the mistake they're making, how will a regular developer? Like you, about a year ago I was still optimistic that SOAP had a chance because I expected more people to recognize the error of their ways by now. I've since given up. Already people are asking "Where are the Web services?" - that question will be asked more and more in the coming year, until finally, nobody cares. P.S. I think the circles are concentric, with REST's circle being of radius X, and SOAP's being of radius X*1.01. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
I'm trying to develop a webapp in a RESTful fashion, but recently ran into a conundrum that I'm hoping y'all can help me solve. I've already scoured the wiki and the white papers but don't see any specific advice for my situation. The webapp is framed (not necessarily my choice, but it's also not necessarily a bad choice for it either). The left frame contains an explorer-type folder tree containing essentially the names of columns in a database table. The right frame is a content pane. When the user selects a column from the tree, the column's values should be added to a table in the content frame. Selecting another column from the tree adds more columns to the table. Question is, how do I make all of this happen in a RESTful fashion? Is it, in fact, even possible given our design constraints? The links in the tree are going to have to be of the form: GET /viewer?column=foo on the server-side, when processing such a request, we add the requested column to a session variable and render the new table. But the URL for the table frame is going to be incorrect after a couple such requests. If the user were to bookmark the URL and revisit it later, they would get a table with only the last column that was added. Clearly, that's not RESTful. I was idly wondering, would it be RESTful if the server-side piece that adds the requested column to the session variable were to redirect the browser to a URL for the table that was, well, unique? e.g. /viewer?column=foo&column=bar&column=bat Alternately, would it be RESTful if the server-side piece were to create a named resource which stores the state of the table and return a URL to that resource? e.g. /viewer?table=23 Or is there another, better possibility that would make for a cleaner, more RESTful urlspace? - donald
----- Original Message ----- From: "Donald Ball" <dball@...> > > Or is there another, better possibility that would make for a cleaner, more > RESTful urlspace? Two possiblities a) use client-side state for the set of column selected If the left panel has a list of db columns, and each were a checkbox in a form, auto-submit the form when a checkbox is checked, and have the form use method=GET. This will cause a URL to be generated of the format ?col1=on&col3=on&col7=on This URI identifies a resource which is that particular permutation of column names. This can be easily rendered into HTML Of course, using a FORM literally might not be the most chrome looking UI, so let your script kiddies go nuts. b) use persistent data on the server to maintain state If this information should be long-lived, have the server maintain a URI that doesn't change and is unique for that user (in the same sense that a session variable is unique to a user). When the left hand panel POSTs data to that URI, keep updating the selected columns and return a representation of the table with the users current set of selected columns. This is nice if the purpose of the app is to later use that selected 'db view' in some way - perhaps to modify attributes (like 'max rows' or something), as well as this approach makes that 'db view' an identifable concept so you could do something like 'show me db #2 with view #27' mike
Forwarded... ----- Original Message ----- From: "firepipe_au" <michael@...> To: "S. Mike Dierken" <mdierken@...> Sent: Wednesday, October 23, 2002 8:50 PM Subject: Re: How to handle in a RESTful fashion? > --- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote: > > > > ----- Original Message ----- > > From: "Donald Ball" <dball@r...> > > > > > > > > Or is there another, better possibility that would make for a > cleaner, > > more > > > RESTful urlspace? > > > > Two possiblities > > > > a) use client-side state for the set of column selected > > If the left panel has a list of db columns, and each were a > checkbox in a > > form, auto-submit the form when a checkbox is checked, and have the > form use > > method=GET. This will cause a URL to be generated of the format > > ?col1=on&col3=on&col7=on > > This URI identifies a resource which is that particular permutation > of > > column names. This can be easily rendered into HTML > > Of course, using a FORM literally might not be the most chrome > looking UI, > > so let your script kiddies go nuts. > > As the parameters that you're passing are always of the same 'type' > (a column, here), I'd be inclined to put all selected columns in the > one parameter: > > /viewer?columns=foo,bar,bob,harriet > > You can also rewrite your links that update the view: > > heres a link in your control pane that selects the column called foo: > /viewdb?columns=foo > this one assumes you have no columns already selected. > > when you update the view pane, you also update the control pane > so that all of the links are rewritten. Here's the href for > selected a column called bar, with the foo column already selected > /viewer?columns=foo,bar > another column called bob has a href like so: > /viewer?columns=foo,bob > > this way also means that you don't need to maintain state in a > session variable, which some of the people around here consider a > bad thing. Using it or not, however, depends on whether you want to > maintain a user's view across browser sessions, as Mike mentions > below (although as this is entirely a GET scenario, you could > provide a link that bookmarks a particular view, keeping your 256 > byte limit in mind. Your parent frameset would of course have to > process that URL to create the control and view panes...) > > > > > b) use persistent data on the server to maintain state > > If this information should be long-lived, have the server maintain > a URI > > that doesn't change and is unique for that user (in the same sense > that a > > session variable is unique to a user). When the left hand panel > POSTs data > > to that URI, keep updating the selected columns and return a > representation > > of the table with the users current set of selected columns. > > This is nice if the purpose of the app is to later use that > selected 'db > > view' in some way - perhaps to modify attributes (like 'max rows' or > > something), as well as this approach makes that 'db view' an > identifable > > concept so you could do something like 'show me db #2 with view #27' > > > > mike >
http://radio.weblogs.com/0113297/stories/2002/09/24/wholisticWebServices.htm l This is an interesting read on what some WebServices may grow into. "The original idea of "software as service" emerged before the current hype around web services. It was the notion that applications would run in the network. That the user interface could be downloaded and used on the fly on any Internet-connected device (most likely a PC), and that substantial portions of the application --- in particular those that were focused on logic and data --- could be exposed and used by other applications easily. I love the idea of being able to use a high-quality, desktop-like, media-rich software application over the Internet --- to have a means to have that application cached on my local computer; to work offline; to synchronize new versions when needed, and the ability to easily consume and integrate logic and data in other applications on the network. " This is a concise description of the kinds of problems that REST-based systems are good at solving. Forget the HTML/browser mess that we have today - build for the future. Solve these problems with clean design and strong automation capabilities.
Dear REST'ers,
I am happy to share the news with you all that very recently I implemented the REST interface to the open source ebxml registry/repository.This REST binding is a v3.0 feature.
you can find the announcement@
http://www.geocrawler.com/lists/3/SourceForge/21818/0/9957605/
The project home page is,
http://ebxmlrr.sf.net
If you have any question about the usage of the product,you can send email to: 'ebxmlrr-tech@...'
Thanks,
-Uday.
I'm not sure everybody had heard about this, but Mitch Kapor is starting a group to build an open source PIM - email, contacts, schedule, etc. It's going to be a P2P client app and all information items will be URI addressable and that is where the REST crowd may be interested - we can watch the growth of and possibly help a URI based design for a potentially large-scale networked application. It'll have RDF, Python, Jabber, etc. technology, so I'm sure PaulP will be all over that...
>a) use client-side state for the set of column selected >If the left panel has a list of db columns, and each were a checkbox in a >form, auto-submit the form when a checkbox is checked, and have the form >use >method=GET. This will cause a URL to be generated of the format >?col1=on&col3=on&col7=on >This URI identifies a resource which is that particular permutation of >column names. This can be easily rendered into HTML >Of course, using a FORM literally might not be the most chrome looking UI, >so let your script kiddies go nuts. Can't / don't want to reload this frame every time the link is checked. It's a big tree and somewhat expensive to render. Could use javascript to generate the links on the fly, but that's also not necessarily desirable from a RESTful pov. >b) use persistent data on the server to maintain state >If this information should be long-lived, have the server maintain a URI >that doesn't change and is unique for that user (in the same sense that a >session variable is unique to a user). When the left hand panel POSTs data >to that URI, keep updating the selected columns and return a representation >of the table with the users current set of selected columns. >This is nice if the purpose of the app is to later use that selected 'db >view' in some way - perhaps to modify attributes (like 'max rows' or >something), as well as this approach makes that 'db view' an identifable >concept so you could do something like 'show me db #2 with view #27' I think that's the one I'd like to run with. Question is, what do the mechanics look like? When adding a column to a view, I issue a request something like: GET /view?task=add&var=foo then I redirect the user to: /view?id=23 which is the long-lived URL for the dataset view they're constructing. This solution isn't entirely RESTful for two reasons, though, I think: 1. I'm not specifying the view id in the change request. Due to the fact that I don't want to regenerate the link tree, though, this is largely unavoidable. I'll just store the user's active view id in their session, but always redirect them to a URL which they can use absent a session. 2. I should be using a POST request when changing the dataset view. There are two reasons why I can't/shouldn't though: a. The change request is activated by a link, which can't issue a POST request unless use javascript links b. You're not supposed to issue a redirect from a POST request Any thoughts on either the proposed solution or the (nitpicky) problems I see in the solution? - donald
----- Original Message ----- From: "Donald Ball" <dball@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, October 28, 2002 7:56 AM Subject: Re: [rest-discuss] How to handle in a RESTful fashion? > >a) use client-side state for the set of column selected > >If the left panel has a list of db columns, and each were a checkbox in a > >form, auto-submit the form when a checkbox is checked, and have the form > >use > >method=GET. This will cause a URL to be generated of the format > >?col1=on&col3=on&col7=on > >This URI identifies a resource which is that particular permutation of > >column names. This can be easily rendered into HTML > >Of course, using a FORM literally might not be the most chrome looking UI, > >so let your script kiddies go nuts. > > Can't / don't want to reload this frame every time the link is checked. > It's a big tree and somewhat expensive to render. You don't re-load the frame on the left, you use <form target='panel_right' > to reload the panel on the right. > Could use javascript to generate the links on the fly, but that's also not necessarily desirable > from a RESTful pov. You are in a classical browser, you aren't going to get very far into REST land that way. Serve the user first, and the architecture second. > > >b) use persistent data on the server to maintain state > >If this information should be long-lived, have the server maintain a URI > >that doesn't change and is unique for that user (in the same sense that a > >session variable is unique to a user). When the left hand panel POSTs data > >to that URI, keep updating the selected columns and return a > representation > >of the table with the users current set of selected columns. > >This is nice if the purpose of the app is to later use that selected 'db > >view' in some way - perhaps to modify attributes (like 'max rows' or > >something), as well as this approach makes that 'db view' an identifable > >concept so you could do something like 'show me db #2 with view #27' > > I think that's the one I'd like to run with. Question is, what do the > mechanics look like? When adding a column to a view, I issue a request > something like: > > GET /view?task=add&var=foo No, no, no. Did I mention, no? Do not do an 'update' with a GET. If you have a single view that you add names to over time, then the requests will go to the /same uri/ - so don't put things in the query terms (it is part of the URI). You will want something like: ==== // request #1 POST /view?task=add Content-Type: application/x-www-form-urlencoded var=foo // request #2 POST /view?task=add Content-Type: application/x-www-form-urlencoded var=bar ===== Notice how the same URI is used twice. That is because the same resource is updated twice. Also, notice that the URI that is being used isn't all that great - all users would be appending column names all day long. You need to get some qualifying information intothe URI - either the userID, the viewID, or something. > > then I redirect the user to: > > /view?id=23 > > which is the long-lived URL for the dataset view they're constructing. This > solution isn't entirely RESTful for two reasons, though, I think: > > 1. I'm not specifying the view id in the change request. Due to the fact > that I don't want to regenerate the link tree, though, this is largely > unavoidable. I'll just store the user's active view id in their session, > but always redirect them to a URL which they can use absent a session. Tell me again why using a viewId causes the tree to change? > > 2. I should be using a POST request when changing the dataset view. There > are two reasons why I can't/shouldn't though: > > a. The change request is activated by a link, which can't issue a POST > request unless use javascript links Causing updates on the server via a link is to be avoided. I know it would be really nice to do this, but you need to avoid this anyway. If you really want that kind of silent update, use javascript. If you use checkboxes and send the form on each click, then you'll know when the user de-selects a column. Clicking links won't allow you do de-select columns. > > b. You're not supposed to issue a redirect from a POST request There are two different response status codes - one means 'request finished - see this link for results', the other means 'request not processed - try again at this location'. Why aren't you supposed to redirect from a POST?
>> >a) use client-side state for the set of column selected >> >If the left panel has a list of db columns, and each were a checkbox in >a >> >form, auto-submit the form when a checkbox is checked, and have the form >> >use >> >method=GET. This will cause a URL to be generated of the format >> >?col1=on&col3=on&col7=on >> >This URI identifies a resource which is that particular permutation of >> >column names. This can be easily rendered into HTML >> >Of course, using a FORM literally might not be the most chrome looking >UI, >> >so let your script kiddies go nuts. >> >> Can't / don't want to reload this frame every time the link is checked. >> It's a big tree and somewhat expensive to render. >You don't re-load the frame on the left, you use <form target='panel_right' >> to reload the panel on the right. I take your point, if the thing on the left was a form with checkboxes, but UI constraints dictate that it's an explorer tree with links. c'e la vie. >> Could use javascript to generate the links on the fly, but that's also >not >necessarily desirable >> from a RESTful pov. >You are in a classical browser, you aren't going to get very far into REST >land that way. >Serve the user first, and the architecture second. I think the REST architecture principles have just as much to offer traditional HTML webapps as new-fangled XML web services. But that's beside the point. >> I think that's the one I'd like to run with. Question is, what do the >> mechanics look like? When adding a column to a view, I issue a request >> something like: >> >> GET /view?task=add&var=foo >No, no, no. Did I mention, no? Do not do an 'update' with a GET. >If you have a single view that you add names to over time, then the >requests >will go to the /same uri/ - so don't put things in the query terms (it is >part of the URI). So you're of the opinion that, given the design constraints, it would be preferable to massage the requests to POSTs using javascript than to issue GET requests without relying on javascript? >You will want something like: > >==== >// request #1 >POST /view?task=add >Content-Type: application/x-www-form-urlencoded > >var=foo > >// request #2 >POST /view?task=add >Content-Type: application/x-www-form-urlencoded > >var=bar > >===== >Notice how the same URI is used twice. That is because the same resource is >updated twice. Also, notice that the URI that is being used isn't all that >great - all users would be appending column names all day long. You need to >get some qualifying information intothe URI - either the userID, the >viewID, >or something. unless the semantics for the /view URL dictate that, absent a specific identifier, the current view for the user is the one being modified. Is that legit from a REST pov? >> 1. I'm not specifying the view id in the change request. Due to the fact >> that I don't want to regenerate the link tree, though, this is largely >> unavoidable. I'll just store the user's active view id in their session, >> but always redirect them to a URL which they can use absent a session. >Tell me again why using a viewId causes the tree to change? because I don't know the view id until the user has created one by clicking on a link in the tree. It would be undesirable for a couple of other reasons as well, actually. >> 2. I should be using a POST request when changing the dataset view. There >> are two reasons why I can't/shouldn't though: >> >> a. The change request is activated by a link, which can't issue a POST >> request unless use javascript links >Causing updates on the server via a link is to be avoided. I know it would >be really nice to do this, but you need to avoid this anyway. >If you really want that kind of silent update, use javascript. If you use >checkboxes and send the form on each click, then you'll know when the user >de-selects a column. Clicking links won't allow you do de-select columns. Once a column is in the active dataset view, there are a number of things that can be done to the column in the view frame, including removing it from the dataset. >> b. You're not supposed to issue a redirect from a POST request >There are two different response status codes - one means 'request >finished - see this link for results', the other means 'request not >processed - try again at this location'. >Why aren't you supposed to redirect from a POST? I had been given to understand that it was technically not allowed according to the HTTP spec, but as it turns out, that's untrue. It _is_ true that browsers are supposed to verify a redirect request with a user if the server issues a 302 or a 307 in response to a POST (although none do, it would seem), but HTTP/1.1 added a 303 response which is suitable for redirects from POST requests. Doesn't work with NN4, but 302 is an acceptable fallback. So the upshot seems to be that, given my constraints, the links in the explorer should silently turn into POST requests, which send back 303 redirects to a long-lived URL for the dataset view. I can live with that, thanks for the conversation. - donald
----- Original Message ----- From: "Donald Ball" <dball@...> > >You don't re-load the frame on the left, you use <form > target='panel_right' > >> to reload the panel on the right. > > I take your point, if the thing on the left was a form with checkboxes, but > UI constraints dictate that it's an explorer tree with links. c'e la vie. Use a hidden frame with a form to send control messages. The onClick for the link calls script that submits a non-visible form in a zero or one pixel high frame. This can be used to communicate with the server without bumping into UI/presentation issues. > > So you're of the opinion that, given the design constraints, it would be > preferable to massage the requests to POSTs using javascript than to issue > GET requests without relying on javascript? If doing a GET modifies data on the server, then I would use POST - even if that means using script on the client. What happens if the user clicks the same link twice? How does a user remove the column name from the view? What happens when a spider crawls the link? What happens when a user bookmarks a link or drags the link to their desktop? What does the user see when they click link A, then link B, then link A? The second time they click link A they won't see the same as the first time they clicked on link A - it'll look like they are still on link B. > > unless the semantics for the /view URL dictate that, absent a specific > identifier, the current view for the user is the one being modified. Is > that legit from a REST pov? No. The resource identifier should identify the same resource for all clients. If you generate the HTML for the tree control with href= links that have the userid in a query term, then that isn't a problem. It makes the HTML slightly larger though. > > >> 1. I'm not specifying the view id in the change request. Due to the fact > >> that I don't want to regenerate the link tree, though, this is largely > >> unavoidable. I'll just store the user's active view id in their session, > >> but always redirect them to a URL which they can use absent a session. > >Tell me again why using a viewId causes the tree to change? > > because I don't know the view id until the user has created one by clicking > on a link in the tree. It would be undesirable for a couple of other > reasons as well, actually. What about always having a view ID for each user - even if it is empty. The tree would always have that URI in the href= links. > So the upshot seems to be that, given my constraints, the links in the > explorer should silently turn into POST requests, which send back 303 > redirects to a long-lived URL for the dataset view. I can live with that, > thanks for the conversation. No problem. But this conversation is like many I've had when designing systems in the past. It's also very indicative of why I believe that REST based resource modelling is best suited for 'automation' based Web systems and classical UI based systems with existing browsers & server technology just run into too many issues that are counter to good REST based design. Essentially I believe that usability requirements (projected onto browsers and their use of HTTP) conflict with REST principles projected onto HTTP. So, it's okay to strive for RESTfulness with HTML and browsers, but don't sweat the (sometimes major) conflicts that are going to pop up.
http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml I've just read this article on the upcoming Groove web services interfaces. It talks about how Groove have tried to create a RESTful interface using SOAP/WSDL and that the result is an "exceptionally elegant and productive Web services API". Then I read that; "It's all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete." ! They really seem to have grasped the value of uri-addressable resources represented in xml, accessed using a small number of standardised methods. So what did they need SOAP for ? I have to hope that their next step is to make SOAP optional. Or will they continue, and start reinventing http-caching. Any thoughts ? Michael Smith.
On Mon, Nov 04, 2002 at 09:11:44PM +0000, Michael Smith wrote: > Then I read that; > "It's all organized as a web of linked XML documents controlled by a > handful of verbs such as Create, Read, Update, and Delete." ! > > They really seem to have grasped the value of uri-addressable resources > represented in xml, accessed using a small number of standardised methods. > So what did they need SOAP for ? > I have to hope that their next step is to make SOAP optional. Or will > they continue, and start reinventing http-caching. > > Any thoughts ? It sounds just like Hailstorm/My-Services. I think their protocol was called HSML or something, but was basically CRUD (in more ways than one). MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Michael wrote: > Then I read that; > "It's all organized as a web of linked XML documents controlled by a > handful of verbs such as Create, Read, Update, and Delete." ! > > They really seem to have grasped the value of uri-addressable resources > represented in xml, accessed using a small number of standardised methods. > So what did they need SOAP for ? > I have to hope that their next step is to make SOAP optional. Or will > they continue, and start reinventing http-caching. > > Any thoughts ? When there was buzz around P2P, and Groove was the first mover, I really thought Groove would be the "Netscape" of the P2P wave. After downloading and attempting to use it, I found that it was worth the space it took on my hard disk, so I removed it. My sense was that it was more hype than anything. Regarding Groove Web Services, my thought is that their interface may in fact be very RESTful, but the sentence you quote above leads me to believe that nothing has changed - more hype than anything. A REST developer who *really* got it would call them like they are: GET, PUT, POST, and DELETE. And that same developer would know that SOAP was irrelevant. Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
I wrote: > After downloading and attempting to use it, I found that it was > worth the space it took on my hard disk, so I removed it. My > sense was that it was more hype than anything. I meant that it was *not* worth the space it took on my hard drive. I don't know what others thought, and I don't mean to venture off-topic, but it was a classic example of a tight, simple concept gone overbloated and overcomplicated. Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
From: "Phil Eskelin" <philip.eskelin@...> > > Regarding Groove Web Services, my thought is that their interface may in > fact be very RESTful, but the sentence you quote above leads me to believe > that nothing has changed - more hype than anything. A REST developer who > *really* got it would call them like they are: GET, PUT, POST, and DELETE. > And that same developer would know that SOAP was irrelevant. All other arguments aside, I strongly disagree that a REST developer would only get it right if they were to use HTTP verbs. HTTP verbs have specific, limited meanings that are not necessarily a good match with the Groove Web Services. It is just as RESTful to create ones own set of verbs that actually provide the exact functionality needed. While I admit that HTTP (and its verbs) is fairly prolific, it is not the "be all, end all" of web protocols. While HTTP is RESTful, not all things RESTful are HTTP. --- Seairth Jacobs seairth@...
On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote: > It is just as RESTful to create ones own set of verbs that > actually provide the exact functionality needed. No it isn't. You've been here long enough to know that Seairth! 8-O With REST, you're constrained to using methods that you could use on anything. So "CREATE" isn't a REST method, because I don't know what it would mean to invoke that on a URI identifying a stock quote. This is a severe constraint on *form*, but does not in any way constrain *function*. i.e. every problem has a solution with a system built with this constraint in mind. > While HTTP is RESTful, not all things RESTful are HTTP. That's true, but largely irrelevant today; it's all we've got that is. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Hi, I'm just wondering about the interplay of authorization with resource space when developing web applications. Is there anything un-RESTful about constraining resources implicitly based on the user's authenticated identity? It makes me uneasy, but I'm not sure why. Let's say we have a simple DBMS-based application that relates Users to Products and allows, say, a subscription mechanism to build more such bindings and a cancellation mechanism to break them down. Now we want the users to subscribe and unsubscribe themselves, and we want to expose this through a web interface. A User ought to be able to manage his own space without constraint, but should not be able to see or change other Users' subscriptions. Therefore, we need to authenticate users and authorize their activities based on their identity. What happens if there is a resource, say /Subscriptions, that spans many users, and one particular user, with authentication, wants to dereference that? One answer is that because part of /Subscriptions is out of bounds of that user, the entire resource is "Unauthorized". Another answer is that the representation given to a user is filtered, based on his authenticated identity. In that case, two different users accessing /Subscriptions via GET will see disjoint subsets of the resource. By extension, an entire resource schema (application) may be implicitly constrained by the security properties of the access. What does REST have to say about this, if anything? Walden Mathews MIS Special Projects Sales, Trading and Wealth Management Thomson Financial Voice (212) 510-3121 Fax (212) 732-7191
From: "Mark Baker" <distobj@...> > > On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote: > > It is just as RESTful to create ones own set of verbs that > > actually provide the exact functionality needed. > > No it isn't. You've been here long enough to know that Seairth! 8-O > With REST, you're constrained to using methods that you could use on > anything. So "CREATE" isn't a REST method, because I don't know what > it would mean to invoke that on a URI identifying a stock quote. Huh? This is the first time I've heard that all RESTful methods must be usable on *anything*. All I understood of REST was that you should use a few, generic methods. Within the domain that Groove is functioning, their choice of methods are RESTful. *sigh* Just when I thought that I understood this REST thing... > This is a severe constraint on *form*, but does not in any way constrain > *function*. i.e. every problem has a solution with a system built with > this constraint in mind. > > > While HTTP is RESTful, not all things RESTful are HTTP. > > That's true, but largely irrelevant today; it's all we've got that is. If it is largely irrelevant today, then why do we talk about REST at all? Why not just talk about HTTP Best Practices instead? If HTTP is the only RESTful thing we will be using for any forseeable future, REST concepts would get much further if we were to just put it aside and get people to focus on HTTP... --- Seairth Jacobs seairth@...
On Tue, Nov 05, 2002 at 02:09:32PM -0500, Seairth Jacobs wrote: > > No it isn't. You've been here long enough to know that Seairth! 8-O > > With REST, you're constrained to using methods that you could use on > > anything. So "CREATE" isn't a REST method, because I don't know what > > it would mean to invoke that on a URI identifying a stock quote. > > Huh? This is the first time I've heard that all RESTful methods must be > usable on *anything*. All I understood of REST was that you should use a > few, generic methods. Within the domain that Groove is functioning, their > choice of methods are RESTful. > > *sigh* Just when I thought that I understood this REST thing... Oops. 8-( Yah, that's what "uniform interface" means. If a method doesn't mean something to everything you can invoke it on, then it's not uniform! It's like being restricted to interacting with Java objects by using java.lang.Object. The uniform interface constraint is really two constraints in one. First, there's the constraint that you need to prespecify the methods you'll use, for visibility and low-coordination cost reasons. Second, there's the additional constraint that the interface will be the most general one possible, which you get by constraining that all methods are usable on everything. > > > While HTTP is RESTful, not all things RESTful are HTTP. > > > > That's true, but largely irrelevant today; it's all we've got that is. > > If it is largely irrelevant today, then why do we talk about REST at all? > Why not just talk about HTTP Best Practices instead? If HTTP is the only > RESTful thing we will be using for any forseeable future, REST concepts > would get much further if we were to just put it aside and get people to > focus on HTTP... That's what some of us are doing, but it's also useful to focus on REST to explain how some HTTP related things are broken. e.g. cookies. Plus, sometimes it's not obvious from just looking at RFC 2616 why things are the way they are. That's where REST helps. For example, statelessness. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > Seairth Jacobs wrote: > > It is just as RESTful to create ones own set of verbs that > > actually provide the exact functionality needed. > > No it isn't. You've been here long enough to know that Seairth! > 8-O With REST, you're constrained to using methods that you could > use on anything. So "CREATE" isn't a REST method, because I > don't know what it would mean to invoke that on a URI identifying > a stock quote. One of the big benefits that one should receive from taking a RESTful approach is purification and simplification of an otherwise ugly situation that will only get uglier. If Groove uses 'Create', then someone else will use 'myCreate', then someone else will use hungarian notiation with 'urilstCreate', and then in a few years we circle back to the same recursive scope creep scenario that led to the creation of SOAP in the first place. People agreeing on HTTP and its verbs is a key success factor of REST. > This is a severe constraint on *form*, but does not in any way > constrain *function*. i.e. every problem has a solution with a > system built with this constraint in mind. I went back and read the entire article [1], written by Jon Udell at InfoWorld. I can't tell if my problem comes from what I perceive as a writer trying to sound smart, Groove trying to cash in on hype, or from those who created the notion of RESTful SOAP trying to start a riot. Udell says GWS is a textbook example of "RESTful SOAP" - is that good or bad? To elaborate on what that means, he references the SOAP 1.2 working draft, saying that URIs should be used as resource identifiers. DUH!! Then comes this paragraph: For example, the root of GWS is a SOAP service with an address like http://localhost:9080/GWS/Groove/1.0/Accounts. Since a Groove account is a container of identities, a Read operation on this resource produces an XML document that enumerates them. Each identity includes an element like /GWS/Groove/1.0/Spaces/grooveIdentity/123...xyz -- that is, the URI of the SOAP service that enumerates the shared spaces for that identity. Traversal of spaces, tools, and data proceeds in a similar fashion. It's all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete. First (if I was claiming to be RESTful), I would replace every instance of 'SOAP service' with 'resource'. Then, I would replace 'Create, Read, Update, and Delete' with 'PUT, GET, POST, and DELETE'. To clarify my point, I might reword the last sentence to say "...web of linked resources accessed by a handful of verbs that allow you to create, read, update, and delete them." I would then elaborate on the connection between a RESTful style and HTTP and make sure I reference Fielding's thesis. Philip 1. http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
----- Original Message ----- From: "Phil Eskelin" <philip.eskelin@...> > > First (if I was claiming to be RESTful), I would replace every instance of > 'SOAP service' with 'resource'. Then, I would replace 'Create, Read, > Update, and Delete' with 'PUT, GET, POST, and DELETE'. To clarify my point, > I might reword the last sentence to say "...web of linked resources accessed > by a handful of verbs that allow you to create, read, update, and delete > them." I would then elaborate on the connection between a RESTful style and > HTTP and make sure I reference Fielding's thesis. I don't believe that REST depends on those /particular/ operations. Any self-consistent system can pick whatever small number of operations it wants. It will only be consistent with itself though, unless it uses the same operations (with the same meanings, etc) as other systems though. If your job is to build a system, without regard to interoperability with other systems, then using those particular operations is a lower priority. But if you are successful, you will eventually run into them, so you better be prepared to translate, or just use them from day one.
----- Original Message ----- From: "Mathews, Walden" <walden.mathews@...> > > What happens if there is a resource, say /Subscriptions, that spans > many users, and one particular user, with authentication, wants to > dereference that? One answer is that because part of /Subscriptions > is out of bounds of that user, the entire resource is "Unauthorized". > Another answer is that the representation given to a user is filtered, based > on his authenticated identity. In that case, two different users > accessing /Subscriptions via GET will see disjoint subsets of the > resource. By extension, an entire resource schema (application) may > be implicitly constrained by the security properties of the access. > > What does REST have to say about this, if anything? > Cool... filtered views. Good question. My guess is that with HTTP you might be able to indicate how the response was dependent on the request - I think the 'vary' header is used for that. So you could say that the response varies according to the auth header. This is useful for caching, etc. It essentially creates a 'meta-key' or 'meta-identifier' that can be used to a small degree as an identifier for the transient representations.
Does anyone had a look at Jabber as a Rest protocol ? It's full XML, based on few methods (get,set,result,error) for the <iq/> element. I'm quite new to Rest and very new to Jabber, but it sounds like they could work together fine. ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > If it is largely irrelevant today, then why do we talk about REST at all? > Why not just talk about HTTP Best Practices instead? If HTTP is the only > RESTful thing we will be using for any forseeable future, REST concepts > would get much further if we were to just put it aside and get people to > focus on HTTP... >
Phil Eskelin wrote: > I went back and read the entire article [1], written by Jon Udell at > InfoWorld. I can't tell if my problem comes from what I perceive as a > writer trying to sound smart, Groove trying to cash in on hype... This development marks the onset of REST as a buzzword. The pioneers should feel both proud and appalled. I remember when the same thing happened to patterns, and objects before that. A new concept gets promoted, initially adopted by a few and disdained by many. If the promoters are successful, the new concept becomes synonymous with goodness. Pretty soon everybody wants to claim the goodness. Unfortunately, many of them only put it on like lipstick. Next step, a rack of REST books, some of them based on RPC-oriented SOAP? But the fact remains, Roy, Mark, Paul and colleagues have executed a remarkably successful education campaign! Going from disdain to hype-as-goodness in about a year?
> ----- Original Message ----- > From: "Mathews, Walden" <walden.mathews@...> > > > > > What happens if there is a resource, say /Subscriptions, that spans > > many users, and one particular user, with authentication, wants to > > dereference that? One answer is that because part of /Subscriptions > > is out of bounds of that user, the entire resource is > "Unauthorized". > > Another answer is that the representation given to a user > is filtered, > based > > on his authenticated identity. In that case, two different users > > accessing /Subscriptions via GET will see disjoint subsets of the > > resource. By extension, an entire resource schema (application) may > > be implicitly constrained by the security properties of the access. > > > > What does REST have to say about this, if anything? > > > > Cool... filtered views. Good question. > My guess is that with HTTP you might be able to indicate how > the response > was dependent on the request - I think the 'vary' header is > used for that. > So you could say that the response varies according to the > auth header. This > is useful for caching, etc. It essentially creates a 'meta-key' or > 'meta-identifier' that can be used to a small degree as an > identifier for > the transient representations. Okay, that's ringing a bell (I'm not sure which bell, but one having to do with shared caches I think), but it doesn't really answer my question. My question is whether that sort of filtering is consistent with the constraints of REST, or whether it violates the latter in some subtle way that I can't seem to put my finger on. Unless you answered that when you said "Cool..". This has got to be an awfully common pattern in web applications. Jesus, I've only developed two such, and it's in both! Walden
Bob wrote: > This development marks the onset of REST as a buzzword. > The pioneers should feel both proud and appalled. > > I remember when the same thing happened to patterns, > and objects before that. Very very true. Remember requests like 'I need a pattern to search a string for a token' on patterns-discussion? Journalists thrive on change, and often you see them struggle with a new concept when they're early adopters to a potentially mainstream trend. In this case, I don't think Udell struggled with the concept, since in my experience he seems to articulate new concepts well, but he seems to be stuck somewhere in the gray area between being a SOAP and REST (clearly anybody who boasts 'RESTful SOAP' is missing or hiding something). > Next step, a rack of REST books, > some of them based on RPC-oriented SOAP? It must be funny for people browsing in bookstores who are not technical. First they see patterns, thinking maybe programmers are sewers. Then they see SOAP, thinking that programmers finally discovered hygiene. Now REST...will they think it's a new form of meditation? It sort of is, if you do it right ;-) > But the fact remains, Roy, Mark, Paul and colleagues > have executed a remarkably successful education campaign! > Going from disdain to hype-as-goodness in about a year? Gush gush gush! For me, all three have contributed greatly to my understanding of what I'm doing in my own efforts. Roy's dissertation helped me understand the core concepts, but Mark and Paul helped me realize I needed to refactor and redesign my toolkit a lot more before it was RESTful enough for release. Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
On Wed, Nov 06, 2002 at 12:44:02PM -0000, bhaugen32 wrote: > But the fact remains, Roy, Mark, Paul and colleagues > have executed a remarkably successful education campaign! > Going from disdain to hype-as-goodness in about a year? More like two-and-a-half for me. It was March 2000 when I started the REST/Web promotion on soap@.... I got one convert out of that brief stint (though I'm still subscribed), Ken MacLeod. 8-) Thanks for the kind words. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
(from the thread at http://groups.yahoo.com/group/rest-discuss/message/2781) bhaugen32 wrote: >... > This development marks the onset of REST as a buzzword. > The pioneers should feel both proud and appalled. Yes, REST has been quite a buzzword for a while. For some it means "use existing Internet infrastructure". For others it means "use few methods, whether they are HTTP's or not." For others it means "use lots of URIs." If people are thinking about the issues enough to misunderstand them, that's at least progress. ;) I'm somewhat confused about how the RESTful SOAP Groove thing will work. First, I wonder how they will work around the well-known problems in using service URIs in WSDL. Second, I wonder why they would use a READ method instead of the GET method embedded in the implementations of hundreds of tools and standards, from Xalan to Squid, XPath to the DOM. My guess is that the answers to those questions are linked. They couldn't use HTTP GET because WSDL has such poor support for REST. I would guess they've built a REST-a-like on top of a standard single-endpoint SOAP services. I would guess that the addressing model is *still* broken into domain/port/service-path and resource-path whereas the Web has domain/port/resource-path. The service-path/resource-path split is still proprietary, just as if resource-path was using some kind of proprietary GrooveIDs. And of course the method names and semantics are still proprietary to Groove. If we all do this then we will end up with hundreds of incompatible web-alikes. I understand the position Groove is in: they have to ship software and can't wait until WSDL is fixed. And they have to demo Visual Studio.NET integration so they can't dump WSDL. Maybe they did the right thing from a marketing and sales point of view. But nevertheless, fans of "RESTful SOAP" should get out there and publicize the problems with WSDL so that they will be fixed one day. It would be really tragic if five years from now that the REST acronym is associated with a design pattern that has been deployed in hundreds of incompatible ways in hundreds of incompatible services. These issues are discussed further here: * http://www.blogstream.com/pauls/1032521623/index_html * http://www.prescod.net/rest/wsdlhttp.html Paul Prescod
Hi, To indicate that a POSTed XML file is not valid against a schema, which of these response codes would be more appropriate: 400 Bad Request (HTTP request contains syntax error?) 403 Forbidden (I understand, but won't do it?) 406 Not Acceptable (You won't like the response?) 409 Conflict (Change something, then repeat request?) 415 Unsupported Media Type (...) Any thoughts? Michael
On Thu, Nov 07, 2002 at 09:24:17AM +1100, Michael Day wrote: > > Hi, > > To indicate that a POSTed XML file is not valid against a schema, which of > these response codes would be more appropriate: > > 400 Bad Request (HTTP request contains syntax error?) > 403 Forbidden (I understand, but won't do it?) > 406 Not Acceptable (You won't like the response?) > 409 Conflict (Change something, then repeat request?) > 415 Unsupported Media Type (...) > > Any thoughts? This is a good question, and I have to admit to getting caught by it on occasion. I haven't developed a fool proof, simple model yet. But I'd say that it depends on your application. If you consider "invalid document" to be a valid state of your app, then 2xx would be the correct response. This would be the case if anything needed to explicitly reference the "invalid document" state, or if the implications of the submission of it were more than just "fix and resubmit" (though those are the same thing, I think). Like I say, the model is a work in progress. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Mathews, Walden wrote: > Hi, > > I'm just wondering about the interplay of authorization with > resource space when developing web applications. Is there anything > un-RESTful about constraining resources implicitly based on the > user's authenticated identity? It makes me uneasy, but I'm not sure > why. You are varying the view based on something explicitly in the message *and* defined by HTTP. I think that's okay. It is not that different than content-negotiation or language-negotiation. > ... In that case, two different users > accessing /Subscriptions via GET will see disjoint subsets of the > resource. By extension, an entire resource schema (application) may > be implicitly constrained by the security properties of the access. > > What does REST have to say about this, if anything? It is implicit in that there is no flag saying: "This representation is specific to you" but it is triggered by something in the request message and in that sense it is explicit. Paul Prescod
Mark Baker wrote: > On Thu, Nov 07, 2002 at 09:24:17AM +1100, Michael Day wrote: > >>Hi, >> >>To indicate that a POSTed XML file is not valid against a schema, which of >>these response codes would be more appropriate: >> >> 400 Bad Request (HTTP request contains syntax error?) >> 403 Forbidden (I understand, but won't do it?) >> 406 Not Acceptable (You won't like the response?) >> 409 Conflict (Change something, then repeat request?) >> 415 Unsupported Media Type (...) >> >>Any thoughts? > > > This is a good question, and I have to admit to getting caught by it > on occasion. I haven't developed a fool proof, simple model yet. I don't think there is one for POST. Which is odd; you would think the CGI would have run up against input validation years ago. > But I'd say that it depends on your application. That might couple the client and server with private definitions. The server side of the application can't possibly know ahead of time all its clients. Nor is it ideal to expect a client to be able to handle error codes on a per server basis (think what it would be like if RSS used schema validation). You really want to pick one code - or have HTTP extended to deal with this use case. Bill de h�ra
On Wed, Nov 06, 2002 at 08:35:29AM +0100, Yannick Loiseau wrote: > Does anyone had a look at Jabber as a Rest protocol ? It's full XML, based > on few methods (get,set,result,error) for the <iq/> element. I'm quite new > to Rest and very new to Jabber, but it sounds like they could work together > fine. Well, like every system out there, a REST interface could be built to Jabber. But not the other direction. Jabber itself is not based on a REST architecture; having a few verbs isn't sufficient, not even for the "uniform interface" constraint. The RESTwiki has a Jabber FAQ; http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq#head-250b927a770c13278503a632e209fef4dd1b3f6e MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
<http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt> this draft might be interesting to anyone working with secure http systems. Bill de h�ra > -------- Original Message -------- > Subject: I-D ACTION:draft-nystrom-http-sasl-05.txt > Date: Thu, 07 Nov 2002 06:23:59 -0500 > From: Internet-Drafts@... > Reply-To: Internet-Drafts@... > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SASL in HTTP/1.1 > Author(s) : M. Nystrom, R. Zuccherato, A. Melnikov > Filename : draft-nystrom-http-sasl-05.txt > Pages : 25 > Date : 2002-11-6 > > This memo suggest the use of SASL [RFC2222] as a framework to enable > the use of strong authentication mechanisms in http/1.1 [RFC2616], > and defines one approach to accomplish this. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt > >
This seems exactly like content or language negotiation. So, it seems like the right thing is to have /Subscriptions return different content (representations) depending on user.
Or at least as long as the user credentials are explicitly contained in the request. Right? Don't play magic games with cookies containing session ids. Which, I think, for HTTP says that you have to use the Authorization header in the request, and the response would have a Vary: Authorization header.
Looks like HTTP restricts Vary to using the set of defined request headers, so you can't add your own extension header and have the response Vary on it. That seems a little strange -- I don't see why it would be hard for caches to understand any set of request headers that the particular returned representation depended on. After all, if you used an extension header to carry auth credentials, no client that doesn't understand the header will generate it. And so, there doesn't seem to be any danger of the cache returning the wrong rep. At worst, the cache doesn't cache as much as it could.
Which makes me think ... Can someone run the argument for why cookies are evil by me again, please? How does the client end up holding more state in a cookie than it does to fill in an Authorization header? In either case, you need more than the URI to get a useful representation of the resource back.
I accept that having some of the resource identification stored in the URI and some stored in a cookie is a bad thing. I also accept that using a "session" id that refers to a hidden resource on the server and identifying that hidden resource in a cookie using a proprietary addressing scheme, rather than mentioning the session resource directly via its URI, is a bad thing.
Of course, there's judgement involved in deciding what's the resource (identified by URI) and what's a representation (varying on request headers or cookie values). But in Walden's example, the URI identifies the resource (/Subscriptions) and you need extra info beyond the URI to carry authentication info. In either case (request header or cookie) the extra info is in the message.
Maybe the distinction is that intermediaries like caches can know the fixed set of request headers, can know that server-driven negotiation uses those headers and that the headers of interest will be returned in a Vary response header, and can then serve appropriate cached content using efficient means.
But, is there some hard technical reason that makes limiting the range of Vary a requirement? I.e., if you allowed Vary response to indicate any header in the request (extension headers as well as request headers) or to name a cookie, then caches would have a real hard time dealing with server-driven negotiation? It would be so expensive to support that caches would just pass the request thru? Or else, they'd do the wrong thing?
-Lee
----- Original Message -----
From: Paul Prescod
To: Mathews, Walden
Cc: 'rest-discuss@yahoogroups.com'
Sent: Wednesday, November 06, 2002 8:44 PM
Subject: Re: [rest-discuss] Security and REST
Mathews, Walden wrote:
> Hi,
>
> I'm just wondering about the interplay of authorization with
> resource space when developing web applications. Is there anything
> un-RESTful about constraining resources implicitly based on the
> user's authenticated identity? It makes me uneasy, but I'm not sure
> why.
You are varying the view based on something explicitly in the message
*and* defined by HTTP. I think that's okay. It is not that different
than content-negotiation or language-negotiation.
> ... In that case, two different users
> accessing /Subscriptions via GET will see disjoint subsets of the
> resource. By extension, an entire resource schema (application) may
> be implicitly constrained by the security properties of the access.
>
> What does REST have to say about this, if anything?
It is implicit in that there is no flag saying: "This representation is
specific to you" but it is triggered by something in the request message
and in that sense it is explicit.
Paul PrescodOn Thu, Nov 07, 2002 at 04:08:20PM -0500, Lee Fife wrote: > This seems exactly like content or language negotiation. So, it seems > like the right thing is to have /Subscriptions return different content > (representations) depending on user. There's a tradeoff, of course. It's my understanding that many caches can't handle this type of use very well (though maybe it's improved). > Or at least as long as the user credentials are explicitly contained in > the request. Right? Don't play magic games with cookies containing > session ids. Which, I think, for HTTP says that you have to use the > Authorization header in the request, and the response would have a Vary: > Authorization header. Right. > Which makes me think ... Can someone run the argument for why cookies > are evil by me again, please? How does the client end up holding more > state in a cookie than it does to fill in an Authorization header? In The client ends up holding *less* state; state that it would normally have, such as id/password, are held on the server and the client is just given a "receipt" for them. The server is holding state on the client's behalf. That's the problem. > But, is there some hard technical reason that makes limiting the range > of Vary a requirement? I.e., if you allowed Vary response to indicate > any header in the request (extension headers as well as request headers) Vary can name any header, even extension ones. Just like Connection. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Mark,
From: "Mark Baker" <distobj@...>
> On Thu, Nov 07, 2002 at 04:08:20PM -0500, Lee Fife wrote:
> > This seems exactly like content or language negotiation. So, it seems
> > like the right thing is to have /Subscriptions return different content
> > (representations) depending on user.
>
> There's a tradeoff, of course. It's my understanding that many
> caches can't handle this type of use very well (though maybe it's
> improved).
So, the caches are built to only support negotiation on the Accept and
Accept-* headers? The set of headers the cache looks at is built in? And
presumably if the response Vary header specifies some other request header,
then the response isn't cached?
> > But, is there some hard technical reason that makes limiting the range
> > of Vary a requirement? I.e., if you allowed Vary response to indicate
> > any header in the request (extension headers as well as request headers)
>
> Vary can name any header, even extension ones. Just like Connection.
So, am I misreading the rfc: " Field-names listed in Vary headers are those
of request-headers.". (Sect 14.3) Instead, you're saying that Vary can name
any of the headers present in a request message? (sect 5)
Request = Request-Line ; Section 5.1
*( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
So, Vary can include anything from general-header + request-header +
entity-header?
(BTW, the def for Connection appears to allow any header from the message.)
thanks,
Lee
Mark Baker wrote: >... > > > The client ends up holding *less* state; state that it would > normally have, such as id/password, are held on the server and > the client is just given a "receipt" for them. The server is > holding state on the client's behalf. That's the problem. My thought is that if the Web-as-we-use it were architected entirely according to REST, then "client-side" state (not username/passwords, but preferences, etc.) would more likely live at any URI-addressable home. So you might launch your favorite news site like this: http://www.mynews.com/ or like this: http://www.mynews.com?prefs=http://mypreferences.com/~prescod No matter what device you were using, you would point the site at your consistent preferences-URI. The browser would (at your _request_) send the information to remote servers. Servers would _ask you_ for read and/or write permission to your preferences-URI and the information stored there would tend to be open, textual and in many cases defined independent of any particular application. If you "publish" your favourite sports team, it should be provided to all services _and all of your devices_ unless you specifically override it for some particular application or device. The problem with this vision is it requires a trusted third party to hold your preference information. Most people do not run their own servers. ISPs are the logical choice except who trusts AOL or MSN??? But even so, there could be a degenerate case where the preference-URI is something like "local://mybrowser/preference-cache" and some protocol magic would make that work as if it were a real, full-time preference server. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > My thought is that if the Web-as-we-use it were architected entirely > according to REST, then "client-side" state (not username/passwords, but > preferences, etc.) would more likely live at any URI-addressable home. > So you might launch your favorite news site like this: > > http://www.mynews.com/ > > or like this: > > http://www.mynews.com?prefs=http://mypreferences.com/~prescod Wouldn't it be hard to do caching that way? Or was the thought that preferences (per representation changes based on personal choices) breaks caching anyway? > > No matter what device you were using, you would point the site at your > consistent preferences-URI. The same URI for each device? This is what I would like, but in practice that doesn't happen all that often. > The browser would (at your _request_) send > the information to remote servers. Servers would _ask you_ for read > and/or write permission to your preferences-URI and the information > stored there would tend to be open, textual and in many cases defined > independent of any particular application. If you "publish" your > favourite sports team, it should be provided to all services _and all of > your devices_ unless you specifically override it for some particular > application or device. Wasn't there several attempts at this 'shared preferences' approach? I can't find any references right now...
----- Original Message ----- From: "Mark Baker" <distobj@...> > The client ends up holding *less* state; state that it would > normally have, such as id/password, are held on the server and > the client is just given a "receipt" for them. The server is > holding state on the client's behalf. That's the problem. > Since the Web has migrated on its own to a system where the server holds authentication information on the client's behalf, doesn't this indicate an actual benefit to that approach? Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type being unsecure, why do so many systems use something else? And why isn't there an RFC describing/standardizing current practice? The servlet engines I know have a servlet config for authentication called 'form auth' which makes it easy to use POST to authenticate & then pass down a cookie. Wouldn't it make sense to describe a use of HTML FORM that indicated to the user-agent (the browser) that it was 'authentication' information and then the browser could send it in the correct header? Or maybe a new HTML element like <AUTH> or something...
S. Mike Dierken wrote: >... >>http://www.mynews.com/ >> >>or like this: >> >>http://www.mynews.com?prefs=http://mypreferences.com/~prescod > > > Wouldn't it be hard to do caching that way? Or was the thought that > preferences (per representation changes based on personal choices) breaks > caching anyway? Exactly! But perhaps we can use persistent connections, inclusions and prefetching to get more granular. Perhaps the page that is returned consists mostly of "includes" and those includes are cached or not cached based on whether they are specific to you or not. >>No matter what device you were using, you would point the site at your >>consistent preferences-URI. > > The same URI for each device? This is what I would like, but in practice > that doesn't happen all that often. None of this happens in practice. It is a proposal. ;) >... > > Wasn't there several attempts at this 'shared preferences' approach? I can't > find any references right now... Netscape had a remote preferences feature but I'm not sure if it covered cookies. Hailstorm was to be more or less a remote cookie repository. But they couldn't find a business model for it because the natural home for it is at the ISP (or at least portal) and the biggest ISP in the world would NEVER cooperate with Microsoft. Plus, ISPs seem to have frozen the set of applications they are willing to deliver around 1995. How many of them are working to roll out Jabber or multicast or smart content caching techniques or decent spam filtering or universal inboxes (=phone and email) or ... They are about as imaginative as cable TV companies because these days they _are_ cable TV companies. Paul Prescod
In REST, we agree that all state should be kept on the client side. Now, what is the best way to go about doing that? I am not necessarily talking about using existing HTTP browser/server technology. I am talking about creating a ficticious client and server that did this correctly. Paul mentioned the idea of having a URI-referencable client state that the server could query. However, what sets the state in the first place (presumably in a RESTful manner)? Who is responsible for setting the state? Client? Server? Both? --- Seairth Jacobs seairth@...
On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote: > My thought is that if the Web-as-we-use it were architected entirely > according to REST, then "client-side" state (not username/passwords, but > preferences, etc.) would more likely live at any URI-addressable home. > So you might launch your favorite news site like this: > > http://www.mynews.com/ > > or like this: > > http://www.mynews.com?prefs=http://mypreferences.com/~prescod That's certainly *an* approach, but it's stateful not stateless because the preferences form part of the meaning of the message, but are not in the message. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
On Thu, Nov 07, 2002 at 02:38:30PM -0700, Lee Fife wrote: > So, the caches are built to only support negotiation on the Accept and > Accept-* headers? The set of headers the cache looks at is built in? And > presumably if the response Vary header specifies some other request header, > then the response isn't cached? All I know about this, I heard from others. Mnot would be the best person to comment on the specifics. > > Vary can name any header, even extension ones. Just like Connection. > > So, am I misreading the rfc: " Field-names listed in Vary headers are those > of request-headers.". (Sect 14.3) Instead, you're saying that Vary can name > any of the headers present in a request message? (sect 5) > > Request = Request-Line ; Section 5.1 > *( general-header ; Section 4.5 > | request-header ; Section 5.3 > | entity-header ) ; Section 7.1 > CRLF > [ message-body ] ; Section 7.2 > > So, Vary can include anything from general-header + request-header + > entity-header? Sorry, I meant any *request* header. But it can be any extension header too, not just those in the HTTP spec, which is what I thought you were talking about. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
On Thu, Nov 07, 2002 at 09:25:12PM -0500, S. Mike Dierken wrote: > Since the Web has migrated on its own to a system where the server holds > authentication information on the client's behalf, doesn't this indicate an > actual benefit to that approach? For sure, there's lots of benefits to them; they're a catch-all, they're easy to use and implement, etc.. But there's also serious disadvantages, such as messing up browsing (i.e. hitting "Back" doesn't remove the cookie), plus resource consumption on the server. Obviously the pros outweight the cons for browsers. Cookies are the way they are because they got deployed first, and they did the job. That doesn't mean we can't do better for non-browser based apps, which was I was so disappointed to see the WS-I Basic Profile support them as a state mechanism. > Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type > being unsecure, why do so many systems use something else? As you suggest below, I believe it's the lack of a UI. > And why isn't there an RFC describing/standardizing current practice? The > servlet engines I know have a servlet config for authentication called 'form > auth' which makes it easy to use POST to authenticate & then pass down a > cookie. Well, that doesn't impact the protocol, so I don't know what value there would be to doing that, other than illustrative. > Wouldn't it make sense to describe a use of HTML FORM that indicated to the > user-agent (the browser) that it was 'authentication' information and then > the browser could send it in the correct header? Or maybe a new HTML element > like <AUTH> or something... Yep. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
Mark Baker wrote: > For sure, there's lots of benefits to them; they're a catch-all, they're > easy to use and implement, etc.. But there's also serious disadvantages, > such as messing up browsing (i.e. hitting "Back" doesn't remove the > cookie), plus resource consumption on the server. Obviously the pros > outweight the cons for browsers. The back button is a (literally) a world in itself and cookies are incidental to it. > Cookies are the way they are because they got deployed first, and they > did the job. Maybe. But if we keep refusing to use TTPs then there isn't a better game in town that storing state on servers. I'll also observe that even if cookies vanished tommorrow, the server would still need to hold state to deal with back button 'semantics', which are not unlike trying to write software while an evil pixie inserts random goto statements into the code. >That doesn't mean we can't do better for non-browser based > apps, which was I was so disappointed to see the WS-I Basic Profile > support them as a state mechanism. Absolutely. Bill de h�ra
Hi, I would really like to use the Resource-Type header defined here: http://lists.w3.org/Archives/Public/www-archive/2002Mar/att-0054/01-draft-palmer-resrep-type-00.txt for linking resources to an RDF Schema, allowing clients to infer the POST interface that they support. Is this header any kind of standard? Is there any way to achieve the same effect without using HTTP headers? Michael
I think we need to be careful to say "conversational state" in instances like this. When you propose to capture conversational state as a globally addressable resource, you're promoting it to something "higher" than conversational state. Indeed, you're likely factoring out the conversation in doing that, maintaining only the points of agreement. Think: If clients were responsible for *all* application state, then there would be no need for servers. Please let's try to keep the word "conversational" in there where it belongs. Thanks, Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Thursday, November 07, 2002 9:55 PM > To: rest-discuss > Subject: [rest-discuss] client-side state (was Re: Security and REST) > > > In REST, we agree that all state should be kept on the client > side. Now, > what is the best way to go about doing that? I am not > necessarily talking > about using existing HTTP browser/server technology. I am > talking about > creating a ficticious client and server that did this correctly. Paul > mentioned the idea of having a URI-referencable client state > that the server > could query. However, what sets the state in the first place > (presumably in > a RESTful manner)? Who is responsible for setting the state? Client? > Server? Both? > > --- > Seairth Jacobs > seairth@... > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
On Fri, Nov 08, 2002 at 09:16:48AM -0500, Mathews, Walden wrote: > I think we need to be careful to say "conversational state" > in instances like this. Definitely. Either that or "application state" or maybe "session state". I used to prefer "session state", but "application state" has grown on me despite many people thinking it means data. "conversational state" is arguably better, especially when talking to Web services folks, since, of course, "conversations" are a big deal. > When you propose to capture conversational > state as a globally addressable resource, you're promoting it > to something "higher" than conversational state. Indeed, you're > likely factoring out the conversation in doing that, maintaining > only the points of agreement. > > Think: If clients were responsible for *all* application state, then > there would be no need for servers. I like to call that "application data". "application state" should refer to the state of the application (duh!), such as "waiting for input from user", etc.. MB -- Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA. http://www.markbaker.ca http://www.idokorro.com
> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, November 08, 2002 9:45 AM
> To: Mathews, Walden
> Cc: 'Seairth Jacobs'; rest-discuss
> Subject: Re: [rest-discuss] client-side state (was Re: Security and
> REST)
>
>
> On Fri, Nov 08, 2002 at 09:16:48AM -0500, Mathews, Walden wrote:
> > I think we need to be careful to say "conversational state"
> > in instances like this.
>
> Definitely. Either that or "application state" or maybe "session
> state". I used to prefer "session state", but "application state"
> has grown on me despite many people thinking it means data.
> "conversational state" is arguably better, especially when talking
> to Web services folks, since, of course, "conversations" are a big
> deal.
>
> > When you propose to capture conversational
> > state as a globally addressable resource, you're promoting it
> > to something "higher" than conversational state. Indeed, you're
> > likely factoring out the conversation in doing that, maintaining
> > only the points of agreement.
> >
> > Think: If clients were responsible for *all* application state, then
> > there would be no need for servers.
>
> I like to call that "application data". "application state" should
> refer to the state of the application (duh!), such as "waiting for
> input from user", etc..
There are scope ambiguities inherent in "application state" when
the application is distributed between a client and a server. My
view is that "the application" spans client and server, and spans
ephemeral states (conversational) and durable states (persistent
data). In other words, Application State is the whole enchelada.
In Alloy, you'd typically model it under a signature called "System {}"
or something suitably global sounding.
"Waiting for input from user" is a server state scoped by the
message-passing domain, so it's not even part of conversational state
proper, unless you promote it to "Waiting for confirmation to the
pending proposal" or some such. We'd best be careful here, lest we
conflate transport and application layers, after all that work
educating the public as to the difference(!).
"Application data" carries no special meaning to me, but I agree
that we need a term that distinguishes the state of the application's
problem domain from the state of conversations about it. For
instance, the conference room scheduler's problem domain consists
of rooms, people, reservations and the resulting schedules. The
state of that domain at any given time controls what room you can
occupy and what room you can reserve for the future.
Although you can get some benefit from a separation of concerns like
the above, it's interesting to note that mutable applications exist
to shape conversations into durable facts about the domain. For
example, when you converse with the conference room scheduler, you
pass back and forth half-baked specifications of a reservation until
it achieves permanent (problem domain) status by agreement.
Forgive me, for I take the anal-retentive modeler's view of
what "state" is, namely: everything that isn't change. Forgive
me again, for I didn't mean to rant or preach on the subject;
just to gather my own thoughts (and share them).
Waldoon
On Fri, Nov 08, 2002 at 10:45:02AM -0500, Mathews, Walden wrote:
> There are scope ambiguities inherent in "application state" when
> the application is distributed between a client and a server. My
> view is that "the application" spans client and server, and spans
> ephemeral states (conversational) and durable states (persistent
> data).
Ditto.
> In other words, Application State is the whole enchelada.
> In Alloy, you'd typically model it under a signature called "System {}"
> or something suitably global sounding.
Hmm, that's reasonable I suppose. But I think it's still fair to say
that the term is currently ambiguous, so one should also try to
expand on what you mean by it.
> "Waiting for input from user" is a server state scoped by the
Actually I meant that a user agent was waiting for the user.
> "Application data" carries no special meaning to me, but I agree
The word "data" is definitely understandable by more people. Maybe
the word "application" is unnecessary.
We need a glossary in the Wiki. Obviously the Wiki *is* a glossary,
but I mean getting some more basic terms defined as Wiki words,
including distributed systems stuff. Volunteers?
> Forgive me, for I take the anal-retentive modeler's view of
> what "state" is, namely: everything that isn't change. Forgive
> me again, for I didn't mean to rant or preach on the subject;
> just to gather my own thoughts (and share them).
Depending on who I'm talking to (!!), it either means "anything that is
remembered", or what you call conversation state. Of course, the former
is a superset of the latter.
MB
--
Mark Baker, CTO, Idokorro Mobile. Ottawa, Ontario, CANADA.
http://www.markbaker.ca http://www.idokorro.com
S. Mike Dierken wrote: >... > > Wouldn't it make sense to describe a use of HTML FORM that indicated to the > user-agent (the browser) that it was 'authentication' information and then > the browser could send it in the correct header? Or maybe a new HTML element > like <AUTH> or something... Yes, and this is a known deficiency with both HTML forms and XForms. Unfortunately the REST/HTTP community didn't push the issue with XForms. By the time I became very knowledgable about XForms, REST and the interaction between them, the XForms working group was already exhausted and in somewhat of a defensive mode. Now they are almost at CR stage and will resist changes even more strongly. Perhaps XHTML 2.0 is the next opportunity to attack the problem. Another option is to just write a W3C NOTE ... or if anyone is ambitious enough (and works at a member company) to try to push the NOTE through the process as its own WD. "HTTP Authentication extensions for XForms and XHTML". When I mentioned the problem to Dan Connolly at a conference he slapped his head and said something like: "We STILL haven't fixed that? Damn." It's a little thing but with a wide impact on how people build websites... Paul Prescod
Sorry to beat a dead horse here, but I'm trying to understand what the HTTP rfc actually means. Anyway, Mark said: > Vary can name any header, even extension ones. Just like Connection. I replied, quoting from rfc 2068: > So, am I misreading the rfc: "Field-names listed in Vary headers are those > of request-headers.". (Sect 14.3) And Mark responded: > Sorry, I meant any *request* header. But it can be any extension > header too, not just those in the HTTP spec, which is what I thought > you were talking about. Finally: * yes, I was talking about extension headers. Those seem like a natural place to put authentication credentials if you're using some non-standard scheme * I was interpreting "request-headers" as referring specifically to the set of headers defined in the production for request-header in Sect 5.3. It seems like Mark is saying "request-headers" should mean any header in the request message? BTW, I'd like this better, cause then you could Vary on extension headers. But, then I'd expect the rfc to say something like "any request header". But, practically, what's the impact of this? Is an intermediary justified in rejecting a response message if it has illegal headers in it? E.g., could a firewall fail to pass thru a response containing a "Vary: foobar" header (where foobar is some extension header from the request)? Or could a cache ignore the unrecognized Vary header fields and return the wrong page to a subsequent request? (Of course, a broken firewall or cache could do anything ... I'm talking about "correct per the rfc" behavior.) -Lee
>> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type >> being unsecure, why do so many systems use something else? >As you suggest below, I believe it's the lack of a UI. My two cents: In the systems I've built, lack of UI is exactly the reason we're rejected HTTP Auth. Two main problems: * usability: simple as it seems, the uname/pw dialog that the browsers present seems to stump naive users. There's no feedback if you enter bad credentials (besides the dialog popping up again), there's no help, there's no way to retrieve a forgotten password. * branding/look&feel: no way to control the UI. So you can't make it look like the rest of your app. Insecurity of the Basic scheme hasn't been a big deal for a these apps: newsletters, targetted prof databases, etc. Given configurable client-side control of the auth UI, I think we would have happily used HTTP auth for almost all these apps. -Lee
Mark Baker wrote: > On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote: > >>My thought is that if the Web-as-we-use it were architected entirely >>according to REST, then "client-side" state (not username/passwords, but >>preferences, etc.) would more likely live at any URI-addressable home. >>So you might launch your favorite news site like this: >> >>http://www.mynews.com/ >> >>or like this: >> >>http://www.mynews.com?prefs=http://mypreferences.com/~prescod > > > That's certainly *an* approach, but it's stateful not stateless because > the preferences form part of the meaning of the message, but are not in > the message. So you would say that all your preferences should be sent in every message? We're talking about HTTP GET, so it would have to be HTTP headers...which is a pain for structured information. What if each individual page on a site uses only some small subset of them? There are performance costs to sending them all every time. It is quite a bit cheaper to send a URL or list of URLs and let the recipient choose which to dereference and how deeply to follow links into the representations it finds. ==== To me, statelessness has these advantages: 1. Conversations can migrate between agents and devices because there is no privileged information associated with the connection between the initial "initator" and the "listener". My proposal preserves this. 2. Filtering, caching and other intermediary projects are easier because there is no need to store state between messages. My proposal preserves this. Filters and caches _may_ need to dereference URIs, but they don't have to maintain state themselves. That is important for scalability. It means cache's memory usage does not increase with the number of conversations they watch. 3. If a message is missed or a conversation partner dies, it is easy to "reboot" and "resynch" the client and server state through transfer of representations. My proposal preserves this. 4. Logs are explicit so that historically you can look at a single message in isolation and understand its meaning entirely. My proposal does not preserve this. In a perfect world, I would get all 4 every time. But if the only problem is really "4." then I consider that an acceptable cost. On the other hand, if there is some other major benefit of scalability I am missing... Paul Prescod
> >> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' > >> auth-type being unsecure, why do so many systems use something else? > > > >As you suggest below, I believe it's the lack of a UI. > > My two cents: In the systems I've built, lack of UI is exactly the reason > we're rejected HTTP Auth. Two main problems: > * usability: simple as it seems, the uname/pw dialog that the browsers > present seems to stump naive users. There's no feedback if you enter bad > credentials (besides the dialog popping up again), there's no help, there's > no way to retrieve a forgotten password. > * branding/look&feel: no way to control the UI. So you can't make it look > like the rest of your app. My biggest concern with HTTP Auth (as currently implemented by browsers) is that once you've logged in, there is no way for the user to tell the browser to "forget" that username and password! You have to close ALL browser windows to get it to forget the authentication. Wouldn't it be nice if the web browser had a statusbar icon (similar to the lock for HTTPS) indicating that it was currently sending authentication information with each request? Clicking on this icon would allow the user to "manage" their current logins, including an easy way to logout from a given site (where logout simply means no longer sending authentication information). Fixing this problem would make HTTP auth usable by browsers. Of course, UI improvements would be welcome......... > Given configurable client-side control of the auth UI, I think we would > have happily used HTTP auth for almost all these apps. Agreed! The server should be able to return a simple HTML document as the entity-body of the HTTP 401 Unauthorized response. Just need a standard way to inform the browser which field is the username, and which is the password. -Andrew
On Fri, Nov 08, 2002 at 12:02:59PM -0700, Lee Fife wrote: > * I was interpreting "request-headers" as referring specifically to the set > of headers defined in the production for request-header in Sect 5.3. It > seems like Mark is saying "request-headers" should mean any header in the > request message? BTW, I'd like this better, cause then you could Vary on > extension headers. But, then I'd expect the rfc to say something like "any > request header". Hmm, interesting, I never noticed that. Not sure what the general implications of it are, or if it's a bug, but at least there's this bit from 12.1 to cover your Vary question; "However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension header fields not defined by this specification." > But, practically, what's the impact of this? Is an intermediary justified in > rejecting a response message if it has illegal headers in it? E.g., could a > firewall fail to pass thru a response containing a "Vary: foobar" header > (where foobar is some extension header from the request)? Or could a cache > ignore the unrecognized Vary header fields and return the wrong page to a > subsequent request? (Of course, a broken firewall or cache could do anything > ... I'm talking about "correct per the rfc" behavior.) HTTP's processing model is a bit loose, but basically most software out there is "liberal in what it receives" meaning that they won't likely reject a message for containing a header which it doesn't recognize. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
I'm still thinking in terms of conversational state. Maybe I spent too much time in ebXML, don't know. But it still seems to me that if everything gets modeled as business- semantic concepts and speech acts, and both business-semantic concepts and speech acts are implemented as Web resources, then the state of the conversation is represented by the speech acts that have been "uttered". I haven't written down all my thoughts on this in any accessible way, but this document might give an idea: http://www.openebxml.org/information/papers/ecomo02stockholm.pdf It's framed in terms of an ebXML-like model (EDI mailbox-style messages), but one of my goals in joining Rest-discuss was to reframe the speech acts and economic concepts as REST resources. <excerpt> 5.1 Pragmatic Actions The basic notion introduced for relating business actions to economic concepts is that of a pragmatic action, see Fig. 5. A Pragmatic Action is a speech act, as defined in Section 2, and consists of two parts: a content and an illocutionary force. In ecommerce applications, the content is always an economic concept. The illocutionary force of a pragmatic action indicates in what way the action is related to its content. An agent can perform a pragmatic action and thereby influence an economic concept in a specific way. Depending on which economic concept a pragmatic action addresses, different illocutionary forces are applicable. The pragmatic actions are, therefore, divided into several subclasses as indicated in Fig. 5. The three main subclasses are information actions, deontic actions, and fulfilment actions. The underling intuition for identifying these three sub classes of pragmatic actions is that in an e-commerce scenario, trading partners exchange business information, then establish different obligations, and finally exchange economic resources, thereby fulfilling the obligations. [...] A Fulfilment Action has an economic event as its content. The action may declare that an Economic Event has been performed, or it may express that such a declaration is accepted or rejected. There are three possible illocutionary forces for information actions: Declare states that an economic event has been performed, Accept states that a preceding declaration of performing an economic event is accepted, Reject states that such a declaration is rejected. Examples of fulfilment actions are "declare shipment completed" and "accept shipment". A Deontic Action can have a commitment or contract as its content. Thus, a deontic action concerns obligations to carry out events in the future. There are seven possible illocutionary forces for deontic actions: Propose means that an agent proposes the establishment of a commitment or contract. Accept is the acceptance of such a proposal while Reject is the rejection of a preceding proposal, Request- Cancellation is a request to cancel an established commitment or contract, AcceptCancellation is the acceptance of such a request, while RejectCancellation is the rejection of a preceding request to cancel, Cancel is a unilateral cancellation. Examples of Deontic Actions are "request purchase order" and "accept purchase order request". </excerpt> It's clear that some of their Actions should just be GETs. Commitment and Fulfillment actions are the ones that seem to me to be the basis for making business conversations into resource models. The state of the conversation is the combination of the Pragmatic Actions uttered and the states of the economic concepts they affected. There's two levels: the utterances and their relationships (e.g. Offer and Acceptance utterances refer to an Order, Fulfillment actions refer to the Order they fulfill, etc. I think what this means in REST terms is that Pragmatic Actions would be POSTed as statements and result in the creation or updating of economic concept resources, but the Pragmatic Actions would themselves become resources and could refer to each other. For example, an Accept statement would need to refer to an Offer or Assertion statement. With a small number of economic concepts and statements and relationships, it would be possible to configure conversations on the fly from hyperlinked Web resources, and know what the state of the conversation was by examining the resources. Still not quite soup yet, but coming along, as I get time and figure out the details. -Bob Haugen
----- Original Message ----- From: "Andrew Tipton" <atipton@...> > My biggest concern with HTTP Auth (as currently implemented by browsers) is > that once you've logged in, there is no way for the user to tell the browser > to "forget" that username and password! You have to close ALL browser > windows to get it to forget the authentication. Same thing with cookies. Typical cookie based (distributed) apps send a response that has a cookie with negative duration or something that signals the browser to delete the cookie. There should be a corresponding capability in the HTTP Auth approach. > > Wouldn't it be nice if the web browser had a statusbar icon (similar to the > lock for HTTPS) indicating that it was currently sending authentication > information with each request? Clicking on this icon would allow the user to > "manage" their current logins, including an easy way to logout from a given > site (where logout simply means no longer sending authentication > information). Giving the users control over highly technical issues usually doesn't work. Let the web app author present to the user the most appropriate form for 'log out'. Okay... sounds like everybody wants this. Who knows how to write a W3C NOTE?
This may already be widely known, but it just occured to me that this might be a useful resource (ahem) for this group; http://www.cs.wpi.edu/~webbib/ I've used it for years in regards to caching (which a lot of it focuses on), but the topic is actually just the WWW as a distributed system, which seems to be of interest here. The bibliography-by-reverse-date and list of conferences are especially useful. Cheers, -- Mark Nottingham
On Fri, Nov 08, 2002 at 11:31:01AM -0800, Paul Prescod wrote: > So you would say that all your preferences should be sent in every > message? We're talking about HTTP GET, so it would have to be HTTP > headers...which is a pain for structured information. As long as it's part of the *message*. Headers seem the obvious place, but the body's fine too. There's many ways to do this. > What if each individual page on a site uses only some small subset of > them? There are performance costs to sending them all every time. It is > quite a bit cheaper to send a URL or list of URLs and let the recipient > choose which to dereference and how deeply to follow links into the > representations it finds. Yep, very true. The WAPforum went back and forth on this for quite a while with CC/PP. Initially, everybody assumed that the preferences would be cached, but I'm pretty sure the final decision was to send all the data in each message. I could be wrong, the final decision happened after I left, and after I cared. > To me, statelessness has these advantages: > > 1. Conversations can migrate between agents and devices because there > is no privileged information associated with the connection between the > initial "initator" and the "listener". My proposal preserves this. Yep. > 2. Filtering, caching and other intermediary projects are easier > because there is no need to store state between messages. My proposal > preserves this. Filters and caches _may_ need to dereference URIs, but > they don't have to maintain state themselves. That is important for > scalability. It means cache's memory usage does not increase with the > number of conversations they watch. Yep. > 3. If a message is missed or a conversation partner dies, it is easy > to "reboot" and "resynch" the client and server state through transfer > of representations. My proposal preserves this. State of preferences? Ok. > 4. Logs are explicit so that historically you can look at a single > message in isolation and understand its meaning entirely. My proposal > does not preserve this. Right. > In a perfect world, I would get all 4 every time. But if the only > problem is really "4." then I consider that an acceptable cost. On the > other hand, if there is some other major benefit of scalability I am > missing... No, that's a good summary. With any design choice, it's pros vs. cons. On the other hand, a simple policy decision could turn the same message syntax into a stateless transaction, if the URI were to identify a fixed preferences profile that didn't change over time. So if the preferences change, the URI changes. This would allow you to include URIs for fixed and common preference profiles, while including the frequently-changing preferences by-value. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
> > Come to think of it, is there a nice demonstration of content negotiation > > on the web anywhere, preferably at a high profile / popular web site? It > > would be nice to have a working example to show people. > > http://www.w3.org I should have mentioned, w3.org is a no-brainer, and does not fit in the category of high profile / popular except on mailing lists for the discussion of web architecture, HTML or XML :) Does anyone *else* use content negotiation? Michael
On Mon, Nov 11, 2002 at 12:21:15PM +1100, Michael Day wrote: > Does anyone *else* use content negotiation? I don't know. The problem is, if it's done right (for server-driven), you don't know you're using it. Since most big sites use content management tools combined with a Web server, you start looking to see which tools support it. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Mon, Nov 11, 2002 at 11:32:23AM +1100, Michael Day wrote: > Unfortunately, mechanisms that rely on "unusual" HTTP headers such as > Resource-Type and even content negotiation headers like Accept are very > difficult to deploy in environments unfamiliar with their usage. I agree with Resource-Type because it's non-standard, but I think Accept and conneg is quite well deployed, even though a lot of user agents still send "Accept: */*". > Come to think of it, is there a nice demonstration of content negotiation > on the web anywhere, preferably at a high profile / popular web site? It > would be nice to have a working example to show people. http://www.w3.org Specifically, the XML Rec, and presumably others, are available in three formats; HTML, PDF, and "xmlspec"; HTML; http://www.w3.org/TR/REC-xml.html PDF; http://www.w3.org/TR/REC-xml.pdf XMLSPEC; http://www.w3.org/TR/REC-xml.xml GET on http://www.w3.org/TR/REC-xml with the appropriate Accept header will return the variant you ask for, with Content-Location set to the URI listed above. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Fri, Nov 08, 2002 at 10:13:34PM +1100, Michael Day wrote: > > Hi, > > I would really like to use the Resource-Type header defined here: > > http://lists.w3.org/Archives/Public/www-archive/2002Mar/att-0054/01-draft-palmer-resrep-type-00.txt > > for linking resources to an RDF Schema, allowing clients to infer the POST > interface that they support. > > Is this header any kind of standard? Nope, but that doesn't prevent you from using it. > Is there any way to achieve the same > effect without using HTTP headers? You could content-negotiate for RDF and look for an rdf:type assertion in there. Resource-Type is simpler and more efficient, though it's a new thing to deploy. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
> > Is there any way to achieve the same > > effect without using HTTP headers? > > You could content-negotiate for RDF and look for an rdf:type assertion > in there. Resource-Type is simpler and more efficient, though it's a > new thing to deploy. Unfortunately, mechanisms that rely on "unusual" HTTP headers such as Resource-Type and even content negotiation headers like Accept are very difficult to deploy in environments unfamiliar with their usage. Come to think of it, is there a nice demonstration of content negotiation on the web anywhere, preferably at a high profile / popular web site? It would be nice to have a working example to show people. Michael
This [1] is an Internet-Draft that proposes how SASL should be integrated into HTTP authentication. What concerns me is this section: [[[ 4.3.9 "Web farm" considerations Implementation and configuration of the SASL negotiation mechanism described in this memo requires special considerations in the case of web farm environments where several servers may serve user requests since authentication state information otherwise may be lost. In particular, if a persistent connection to a particular server cannot be guaranteed, means for sharing of authentication negotiation state must be available. ]]] In other words, there is apparently server-side state kept during the negotiation of authentication. This seems broken to me, and I have a feeling it's going to cause problems (for reasons that should be clear to REST-heads). Assuming you have a persistent connection isn't possible *or* a good idea in the HTTP. Thoughts? 1. http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt -- Mark Nottingham
On Sun, Nov 10, 2002 at 07:30:11PM -0800, Mark Nottingham wrote: > This [1] is an Internet-Draft that proposes how SASL should be integrated > into HTTP authentication. > > What concerns me is this section: > > [[[ > 4.3.9 "Web farm" considerations > > Implementation and configuration of the SASL negotiation mechanism > described in this memo requires special considerations in the case of > web farm environments where several servers may serve user requests > since authentication state information otherwise may be lost. In > particular, if a persistent connection to a particular server cannot > be guaranteed, means for sharing of authentication negotiation state > must be available. > ]]] > > In other words, there is apparently server-side state kept during the > negotiation of authentication. This seems broken to me, and I have a > feeling it's going to cause problems (for reasons that should be clear to > REST-heads). Assuming you have a persistent connection isn't possible *or* > a good idea in the HTTP. Good catch, yeah, that seems broken and unnecessary. I don't know a lot about SASL, but the little I do suggests to me that it need not be stateful. Better let the author now, if you haven't already ... MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
> > In other words, there is apparently server-side state kept during the > > negotiation of authentication. This seems broken to me, and I have a > > feeling it's going to cause problems (for reasons that should be clear to > > REST-heads). Assuming you have a persistent connection isn't possible *or* > > a good idea in the HTTP. Doesn't HTTP over SSL (HTTPS) involve persistent connections? Michael
Looking a bit deeper, it *appears* that server-side state is only required when the underlying SASL mechanism requires three-stage negotiation (I'm not a SASL expert, but a houseguest is ;) It may be that this scheme will work, but may still be REST-unfriendly. Will dig deeper... ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Mark Nottingham" <mnot@...> Cc: <rest-discuss@yahoogroups.com> Sent: Sunday, November 10, 2002 7:48 PM Subject: Re: [rest-discuss] draft-nystrom-http-sasl-05.txt > On Sun, Nov 10, 2002 at 07:30:11PM -0800, Mark Nottingham wrote: > > This [1] is an Internet-Draft that proposes how SASL should be integrated > > into HTTP authentication. > > > > What concerns me is this section: > > > > [[[ > > 4.3.9 "Web farm" considerations > > > > Implementation and configuration of the SASL negotiation mechanism > > described in this memo requires special considerations in the case of > > web farm environments where several servers may serve user requests > > since authentication state information otherwise may be lost. In > > particular, if a persistent connection to a particular server cannot > > be guaranteed, means for sharing of authentication negotiation state > > must be available. > > ]]] > > > > In other words, there is apparently server-side state kept during the > > negotiation of authentication. This seems broken to me, and I have a > > feeling it's going to cause problems (for reasons that should be clear to > > REST-heads). Assuming you have a persistent connection isn't possible *or* > > a good idea in the HTTP. > > Good catch, yeah, that seems broken and unnecessary. I don't know a lot > about SASL, but the little I do suggests to me that it need not be > stateful. > > Better let the author now, if you haven't already ... > > MB > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > > Will distribute objects for food >
Yes, but HTTP is layered above SSL, not below it. ----- Original Message ----- From: "Michael Day" <mikeday@...> To: <rest-discuss@yahoogroups.com> Sent: Sunday, November 10, 2002 7:57 PM Subject: Re: [rest-discuss] draft-nystrom-http-sasl-05.txt > > > > In other words, there is apparently server-side state kept during the > > > negotiation of authentication. This seems broken to me, and I have a > > > feeling it's going to cause problems (for reasons that should be clear to > > > REST-heads). Assuming you have a persistent connection isn't possible *or* > > > a good idea in the HTTP. > > Doesn't HTTP over SSL (HTTPS) involve persistent connections? > > Michael > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
On Mon, Nov 11, 2002 at 11:32:23AM +1100, Michael Day wrote: > Come to think of it, is there a nice demonstration of content negotiation > on the web anywhere, preferably at a high profile / popular web site? It > would be nice to have a working example to show people. http://www.google.com/ has supported Accept-Language for at least a year. (Change the list of acceptable languages to demonstrate it in a browser.) They don't come much more high profile / popular than that! -- Daniel Biddle <deltab@...>
> http://www.google.com/ has supported Accept-Language for at least a year. > (Change the list of acceptable languages to demonstrate it in a browser.) > > They don't come much more high profile / popular than that! Thanks, that's a good one! It would be nice to dispell some of the voodoo people feel is associated with HTTP headers. Michael
> That might couple the client and server with private definitions. > The server side of the application can't possibly know ahead of time > all its clients. Nor is it ideal to expect a client to be able to > handle error codes on a per server basis (think what it would be > like if RSS used schema validation). You really want to pick one > code - or have HTTP extended to deal with this use case. I picked "403 Forbidden" as the response code for invalid input for my application. It seemed to match the meaning of the request, which was "Please do X with this data" and as the data is invalid the server says "No", which in HTTP is a 403 response. The *reason* the server said no has to be indicated in the body of the response in HTML or RDF or whatever is appropriate. In fact the more I think about it, the more that 403 seems like the right choice. Quoting the spec: The server understood the request, but is refusing to fulfill it ... the request SHOULD NOT be repeated ... it SHOULD describe the reason for the refusal in the entity It could be worth changing the status message for 403 from "Forbidden" to "No", to make it clearer that it's not necessarily an access permission issue. Michael
From Scott Andrew LePera's weblog: "In a strange twist of events, the brass at KnowNow have given the green light to Open Source some of the early prototypes of our 2-way-web technology. The legacy code includes a notification server written in Perl (for the Apache HTTP server) and a JavaScript library (called a microserver) which takes care of the publish-and-subscribe stuff. The project is called mod_pubsub, with all of the code available at the Sourceforge project page, with the goal of melding these concepts into an full C module that turns Apache into a real-time messaging bus. Whew." http://www.scottandrew.com/weblog/2002_11#a000462
Hi,
I have a question regarding the use of non-standardised HTTP Headers:
Suppose there is a serach engine that annotates the returned hit list
with meta data (e.g. title, author, creation date) and suppose this
search engine would be able to use several vocabularies (e.g. Dublin Core)
for this annotation.
What I would like to do, is to base the serch engine's decision about what
meta data vocabulary to use on HTTP content negotioation to anable the client
tell the serach engine what metadata it understands.
Would that be a RESTful approach ?
Example header:
Accept-MetadataEncodingScheme: Dublin-Core
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
On Mon, Nov 18, 2002 at 11:08:42PM +0100, Jan Algermissen wrote: > Hi, > > I have a question regarding the use of non-standardised HTTP Headers: > > Suppose there is a serach engine that annotates the returned hit list > with meta data (e.g. title, author, creation date) and suppose this > search engine would be able to use several vocabularies (e.g. Dublin Core) > for this annotation. > > What I would like to do, is to base the serch engine's decision about what > meta data vocabulary to use on HTTP content negotioation to anable the client > tell the serach engine what metadata it understands. > > Would that be a RESTful approach ? > > > Example header: > > Accept-MetadataEncodingScheme: Dublin-Core Sure! I might use the DC namespace as an identifier, but the idea of using content negotiation here is fine. For more complicated header semantics, where the client needs to be guaranteed that the server understands the extension, something like PEP, RFC 2774, or SOAP would be required. But it doesn't sound like that's critical for this example. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Mark,
thanks very much!
I should propably proof-read the next time....
Jan
Mark Baker wrote:
>
> On Mon, Nov 18, 2002 at 11:08:42PM +0100, Jan Algermissen wrote:
> > Hi,
> >
> > I have a question regarding the use of non-standardised HTTP Headers:
> >
> > Suppose there is a serach engine that annotates the returned hit list
> > with meta data (e.g. title, author, creation date) and suppose this
> > search engine would be able to use several vocabularies (e.g. Dublin Core)
> > for this annotation.
> >
> > What I would like to do, is to base the serch engine's decision about what
> > meta data vocabulary to use on HTTP content negotioation to anable the client
> > tell the serach engine what metadata it understands.
> >
> > Would that be a RESTful approach ?
> >
> >
> > Example header:
> >
> > Accept-MetadataEncodingScheme: Dublin-Core
>
> Sure! I might use the DC namespace as an identifier, but the idea of
> using content negotiation here is fine.
>
> For more complicated header semantics, where the client needs to be
> guaranteed that the server understands the extension, something like
> PEP, RFC 2774, or SOAP would be required. But it doesn't sound like
> that's critical for this example.
>
> MB
> --
> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
>
> Will distribute objects for food
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
for those who don't know, waka is fielding's (creator of REST) vision of a next-gen http, and therefore may be of interest to those here. http://www.radwin.org/michael/blog/archives/2002_11_19.html#000049
Wow! A lot more good stuff on Waka than he had previously discussed. RENDER? Hmm, interesting. Not sure why an extended POST wouldn't suffice for that, but I suppose a new method could be an optimization. MONITOR sounds familiar. 8-) Note that Michael Radwin got the Web services comments backwards; they don't solve the N^2 problem, they are the N^2 problem. Roy's point is that a uniform interface drives integration complexity to O(N) (which was Jeff's earlier comment) MB On Wed, Nov 20, 2002 at 12:10:49AM +0000, Vincent D Murphy wrote: > for those who don't know, waka is fielding's (creator of REST) vision of > a next-gen http, and therefore may be of interest to those here. > > http://www.radwin.org/michael/blog/archives/2002_11_19.html#000049 MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
> Note that Michael Radwin got the Web services comments backwards; they > don't solve the N^2 problem, they are the N^2 problem. Roy's point is > that a uniform interface drives integration complexity to O(N) (which > was Jeff's earlier comment) > > MB A couple of minor points on big O. First "uniform interface drives integration complexity to O(N)" is too easy to be true. It doesn't take into account that while there is much similarity among peer businesses, there is also individuality, a/k/a competitive edge, which mandates, to a degree, custom interfaces. "Uniform interface" is like "software process improvement". You use it to factor away known redundancy, but no more. Any time POST doesn't mean "add this to a list", uniformity is only skin deep. Secondly, your position in the scheme of things determines whether you, personally will feel integration as O(N) or O(N^2) or something else. Basically, God is the only one with the N^2 problem, because it's the system view of the system. An individual newcomer to a party without uniform interfaces causes an integration problem (for itself and all others who wish to integrate with him) with a sum total of O(N). Over time, from historical (God) perspecive, you would observe the N^2 thing, but it's not a price paid daily. Thank you. Waldne
Mathews, Walden wrote, > A couple of minor points on big O. I made related points offlist ... may as well repost them here ... Mark Baker wrote, > what it says is that with Web services, integration complexity is > O(N^2), while O(N) with a common interface. As an aside ... I think this is a double-edged sword. Certainly the integration complexity is reduced. But OTOH the effort of reaching agreement on the common interface is increased. Just to spell this out a bit more, with multiple point-to-point interfaces only two parties need to agree on any particular interface, whereas all N have to agree on the common interface. I'd conjecture that the cost of reaching agreement is exponential in the number of parties to the agreement. That gives us O(N^2)*O(2^2) (ie. just O(N^2)) cost for agreement in the multiple interface case (O(N^2) pairs each having to reach an independent bilateral agreement) vs. O(2^N) cost for agreement in the common interface case. I'd also conjecture that O(N^2) is a wildly pessimistic worst case because in practice not everybody needs to talk to everybody else. You only need O(NlogN) edges in a random graph to get complete connectivity, so O(NlogN) seems like a good guess for the typical, as opposed to the worst, case. FWIW ... not proof, but I've seen data from a major (ie. one that hasn't gone bust yet ;-) B2B exchange which supports this. For multiple interfaces that'd give us, O(NlogN) cost of integration (ie. NlogN implemented interfaces) O(NlogN) cost of agreement (ie. NlogN bilateral agreements) For a common interface it'd give us, O(N) cost of integration O(2^N) cost of agreement Notice that the cost of agreement won't scale down to the typical case for the common interface in the same way as it does for multiple interfaces, because the common interface still requires global agreement whether or not all parties need to communicate with each other. I guess that you know as well as I do that agreements are fraught, messy, political and expensive. I take that as a hint that reducing that element of the _total_ cost is likely to be a win. And I also think that multiple interfaces are likely to scale better in the face of growth and change (yup, I realize that this runs completely counter to what _everyone_ else is saying ;-). That's because changes are liable to be local, hence in the multiple interface case only require local renegotiation and reimplementation; and because new participants only have to reach agreements with the subset of existing participants they actually need to communicate with. OTOH, on the common interface model every change requires global renegotiation and reimplementation; and new particpants either have to get along with what the first-movers already decided on whether or not it's fully appropriate for them, or alternatively simply not become participants at all (or become participants in something else). And, again FWIW, I've seen data from several B2B exchanges that this last problem is a real one ... they have a tough time signing up anyone beyond the initial consortia. Interestingly, the numbers above generate the exact opposite of the typical "network effect" on the common interface model ... we actually end up with _decreasing_ returns to scale. Thoughts? Cheers, Miles
"Mathews, Walden" wrote: > A couple of minor points on big O. First "uniform interface drives > integration complexity to O(N)" is too easy to be true. It doesn't > take into account that while there is much similarity among peer businesses, > there is also individuality, a/k/a competitive edge, which mandates, to > a degree, custom interfaces. Depends on what interfaces you are thinking about. If it's for exchanges between companies, then uniform interface will be a big win. Companies exist as members of value systems composed of many other companies. So you might think "uniform interface for this value system", as WalMart does. But most of WalMart's suppliers also belong to other value systems, including some with big dogs at the head (e.g. Home Depot). So even in WalMart's value system, there are forces for global uniformity. That's why UN/CEFACT (the UN trade facilitation org) exists. > Any time POST doesn't mean "add this to a list", uniformity is only > skin deep. I agree with you on this point, but think the second-level of "what POST means" can also be boiled down to a minimal set of meanings. A Swedish project connected to UN/CEFACT is working this out in terms of speech acts as we discuss here. I've tried to bring this topic up in rest-discuss several times, but no bites yet. Regardless, I remain convinced it's on target. > Secondly, your position in the scheme of things determines whether you, > personally will feel integration as O(N) or O(N^2) or something else. > Basically, God is the only one with the N^2 problem, because it's the > system view of the system. It's also the value-system view of the system. For example, one international trade deal may involve 30 parties. Right now, such deals are very difficult to automate in-total. Uniform interfaces (including what POST means in economic terms) will be required. -Bob Haugen
Miles Sabin wrote: > I think this is a double-edged sword. Certainly the integration > complexity is reduced. But OTOH the effort of reaching agreement on the > common interface is increased. Miles, your opinion is really interesting and I agree with it from one angle, but disagree from another angle. > Just to spell this out a bit more, with multiple point-to-point > interfaces only two parties need to agree on any particular interface, > whereas all N have to agree on the common interface. That's true, but the actual practice since the early days of EDI says it's best to have a combination of aspects that are standardized and aspects are negotiated between each pair of trading partners. The more aspects that are standardized, the easier it is to negotiate the operational interface between trading partners. Plus, each trading partner usually has many other partners. So unless you want a different interface for each of your trading partners, the forces for uniform interface remain in play, even locally. > I guess that you know as well as I do that agreements are fraught, > messy, political and expensive. I take that as a hint that reducing > that element of the _total_ cost is likely to be a win. That still says to me, standardize as many aspects as possible, but keep the scope of each detailed trading contract as small as possible (e.g. two parties per). > OTOH, on the common interface model every change requires global > renegotiation and reimplementation; That assumes everything is standardized and mandatory, doesn't it? > and new particpants either have to > get along with what the first-movers already decided on whether or not > it's fully appropriate for them, or alternatively simply not become > participants at all (or become participants in something else). And, > again FWIW, I've seen data from several B2B exchanges that this last > problem is a real one ... they have a tough time signing up anyone > beyond the initial consortia. There's a lot more to the B2B exchanges problems than common interfaces. In fact, the major B2B exchanges I know about are all involved in efforts to create global uniform standards. (I don't think interfaces have anything to do with their business problems, by the way, so standards won't help them either.) -Bob Haugen
bhaugen32 wrote, > Miles Sabin wrote: > > Just to spell this out a bit more, with multiple point-to-point > > interfaces only two parties need to agree on any particular > > interface, whereas all N have to agree on the common interface. > > That's true, but the actual practice since the early days of EDI says > it's best to have a combination of aspects that are standardized and > aspects are negotiated between each pair of trading partners. Right, but isn't this conceeding the point? Once we have bilateral agreements we've departed from a common interface. That said, I completely agree that where _partial_ global agreements are already in effect, then it would almost certainly help to factor them out of any bilateral agreement ... eg. we agree on TCP/IP and HTTP, XML, maybe REST, so no need to negotiate over them). But that's a fixed, already sunk, cost. The problem is all the stuff that comes _afterwards_. > The more aspects that are standardized, the easier it is to negotiate > the operational interface between trading partners. The trouble is that the higher you climb up the semantic ladder the harder this stuff becomes. > Plus, each trading partner usually has many other partners. So unless > you want a different interface for each of your trading partners, the > forces for uniform interface remain in play, even locally. That's already taken into account in the (admittedly crude) model I suggested ... I'm assuming O(logN) partners each (hence O(NlogN) trading pairs). > > OTOH, on the common interface model every change requires global > > renegotiation and reimplementation; > > That assumes everything is standardized and mandatory, doesn't it? If it isn't, then how is it a common interface? > > And, again FWIW, I've seen data from several B2B exchanges that this > > last problem is a real one ... they have a tough time signing up > > anyone beyond the initial consortia. > > There's a lot more to the B2B exchanges problems than common > interfaces. Oh, sure, I agree with that ;-) > In fact, the major B2B exchanges I know about are all involved in > efforts to create global uniform standards. (I don't think interfaces > have anything to do with their business problems, by the way, so > standards won't help them either.) Agreed ... but I take that as evidence that they're doomed ;-) Cheers, Miles
On Tuesday, November 19, 2002, at 08:13 PM, Mark Baker wrote: > Note that Michael Radwin got the Web services comments backwards; they > don't solve the N^2 problem, they are the N^2 problem. Roy's point is > that a uniform interface drives integration complexity to O(N) (which > was Jeff's earlier comment) Now, for the bonus bucks, give a comprehensive (formal) definition of "integration complexity." (Please, please, please... make my life easier. ;-) jb
On Wed, Nov 20, 2002 at 12:32:25PM -0600, Jeff Bone wrote: > Now, for the bonus bucks, give a comprehensive (formal) definition of > "integration complexity." (Please, please, please... make my life > easier. ;-) Ha! After you! 8-) MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Wednesday, November 20, 2002, at 10:01 AM, Miles Sabin wrote: > I think this is a double-edged sword. Certainly the integration > complexity is reduced. But OTOH the effort of reaching agreement on the > common interface is increased. Who says agreement has to be reached at all? Take a look at the world: most real innovation occurs as the result of one or a few persons defining / implementing disruptive technology that has good survival characteristics. Once "in the wild," the masses simply adopt and adapt to this technology; but once in the wild, this technology usually evolves slowly if at all. (HTTP is certainly an example of this.) Very little if any innovation happens as the result of a consensus-making process. Progress is driven by unilateral invention, and the rest of the world just follows along. Hence, optimizing a software architecture on its ability to minimize consensus-making efforts among its users is, IMHO, of little real value --- *particularly* if doing so increases the cost of its actual deployment and usage in the field. > For multiple interfaces that'd give us, > > O(NlogN) cost of integration (ie. NlogN implemented interfaces) > O(NlogN) cost of agreement (ie. NlogN bilateral agreements) > > For a common interface it'd give us, > > O(N) cost of integration > O(2^N) cost of agreement Modification: need to "weight" these costs. As mentioned above, I believe that the top weight is in practice much greater than the bottom weight; lots of effort gets spent on agreement, but most real progress happens by fiat or near-fiat. (Case study: rate of RFCs from IETF modulo number of participants at IETF meetings over history; standards evolution through RFCs.) > Notice that the cost of agreement won't scale down to the typical case > for the common interface in the same way as it does for multiple > interfaces, because the common interface still requires global > agreement whether or not all parties need to communicate with each > other. It would be interesting to consider what the far-reaching implications are when you start with a bias of "everyone needs to *be able to* talk to everyone else" vs. "each party only needs to be able to talk to certain other parties." Also interesting: whether and to what extent assumption of a priori knowledge of "co-communicants" has any impact. > Interestingly, the numbers above generate the exact opposite of the > typical "network effect" on the common interface model ... we actually > end up with _decreasing_ returns to scale. Only if agreement-cost is weighted equal to or greater than integration-cost... jb
Miles Sabin wrote: > > the actual practice since the early days of EDI says > > it's best to have a combination of aspects that are standardized and > > aspects are negotiated between each pair of trading partners. > > Right, but isn't this conceeding the point? Once we have bilateral > agreements we've departed from a common interface. Of course, but it's conceding only part of the point: there will be bilateral agreements. It doesn't detract from the value of the common interface. The common parts make the bilateral agreements much simpler and easier. For example, there are now and will continue to emerge "wannabe standard" business protocols for the order-to-cash cycle. I expect (as in Jeff Bone parallel argument) a small number of these will be widely adopted and have identities (URIs and common names). At that point, the bilateral agreement can just say "let's use http://www.PrepaidDropShipOrder.std with these modifications". As opposed to the several months and many thousands of dollars it takes now to negotiate bilateral EDI agreements... > That said, I completely agree that where _partial_ global agreements are > already in effect, then it would almost certainly help to factor them > out of any bilateral agreement ... eg. we agree on TCP/IP and HTTP, > XML, maybe REST, so no need to negotiate over them). > > But that's a fixed, already sunk, cost. The problem is all the stuff > that comes _afterwards_. > > > The more aspects that are standardized, the easier it is to negotiate > > the operational interface between trading partners. > > The trouble is that the higher you climb up the semantic ladder the > harder this stuff becomes. Of course. Another aspect of agreement. And WalMart may continue to use the WalMart proprietary flavor of everything for a long time to come... Nothing's perfect. -Bob Haugen
On Wed, Nov 20, 2002 at 11:01:45AM -0500, Miles Sabin wrote: > I made related points offlist ... may as well repost them here ... I was going to suggest that.. > > Mark Baker wrote, > > what it says is that with Web services, integration complexity is > > O(N^2), while O(N) with a common interface. > > As an aside ... > > I think this is a double-edged sword. Certainly the integration > complexity is reduced. But OTOH the effort of reaching agreement on the > common interface is increased. Well, I'm not so sure. I assume you're not referring to the standardization portion of the interface, just the decision to use it in the first place. I would say that network effects, one the self-catalyzing point has been reached, make it more expensive to not agree than to agree, the same way that in 1995/1996, everybody *had* to have a Web site. > I'd also conjecture that O(N^2) is a wildly pessimistic worst case > because in practice not everybody needs to talk to everybody else. You > only need O(NlogN) edges in a random graph to get complete > connectivity, so O(NlogN) seems like a good guess for the typical, as > opposed to the worst, case. FWIW ... not proof, but I've seen data from > a major (ie. one that hasn't gone bust yet ;-) B2B exchange which > supports this. Agreed. > And I also think that multiple interfaces are likely to scale better in > the face of growth and change (yup, I realize that this runs completely > counter to what _everyone_ else is saying ;-). That's because changes > are liable to be local, hence in the multiple interface case only > require local renegotiation and reimplementation; and because new > participants only have to reach agreements with the subset of existing > participants they actually need to communicate with. Yah, I understand that position, I think. But I think the Web has shown that these sort of "local islands of closed-worldlyness" are spurious as they succumb to the network effects inherrent in the integration, anywhere, anytime approach of the Web. As an example of this, I recently wanted to reference a Merriam Webster definition of a word, but noticed that their primary interface to their dictionary was via POST, not GET. They do have a GET interface, which I later found, but that's not obvious to people. So dictionary.com is now the defacto english language dictionary on the Web since its primary interface is GET. Goodbye M-W. That's not exactly the situation you describe, but I think the basic principles are the same. There's also the simple maintenance issue that it's cheaper to update one interface than two, so if you've got a service exposed to the world via HTTP, then you might as well use that even for private agreements. > OTOH, on the common interface model every change requires global > renegotiation and reimplementation; and new particpants either have to > get along with what the first-movers already decided on whether or not > it's fully appropriate for them, or alternatively simply not become > participants at all (or become participants in something else). Yes, which is why incrementally deployed extensions are an absolutely must. The Web has no "off" switch. HTTP, and things like RFC 2774 (which improved on that), were designed exactly for this. Waka will be even better, by the looks of it, with built in scoping and mandatory extensions, like PEP and SOAP. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Jeff Bone wrote, > On Wednesday, November 20, 2002, at 10:01 AM, Miles Sabin wrote: > > I think this is a double-edged sword. Certainly the integration > > complexity is reduced. But OTOH the effort of reaching agreement on > > the common interface is increased. > > Who says agreement has to be reached at all? > > Take a look at the world: most real innovation occurs as the result of > one or a few persons defining / implementing disruptive technology > that has good survival characteristics. Once "in the wild," the > masses simply adopt and adapt to this technology; but once in the > wild, this technology usually evolves slowly if at all. In rare cases a proposal might be so instantly compelling that's it achieves widespread adoption without any kind of negotiation being needed. But let's face it ... that's pretty rare. > (HTTP is certainly an example of this.) I think it almost certainly _isn't_ an example of this. Take a look through the HTTP WG archives and think how long it took for HTTP/1.1 to be widely implemented and deployed. > Very little if any innovation happens as the result of a > consensus-making process. Agreed ... but we're not talking about innovation here, we're talking about the adoption of common interfaces. Anyone with a bright idea can strike out on their own, but it takes a different (and often more expensive) kind of effort to get everyone else to follow. > Progress is driven by unilateral invention, and the rest of the world > just follows along. I admire your optimism, but I'm afraid I don't share it. Also note that continuous unilateral innovation is _disruptive_ of existing standards ... a good thing IMO, and one which I think supports my argument. > Hence, optimizing a software architecture on its ability to minimize > consensus-making efforts among its users is, IMHO, of little real > value --- *particularly* if doing so increases the cost of its actual > deployment and usage in the field. Well, YMMV ... > > For multiple interfaces that'd give us, > > > > O(NlogN) cost of integration (ie. NlogN implemented interfaces) > > O(NlogN) cost of agreement (ie. NlogN bilateral agreements) > > > > For a common interface it'd give us, > > > > O(N) cost of integration > > O(2^N) cost of agreement > > Modification: need to "weight" these costs. Umm ... big-Oh means I _don't_ need to weight anything. But yes, to relate these to euro/dollar prices they clearly need weighting. Nevertheless, 2^N will be bigger than NlogN for some values of N and the constant factors. > As mentioned above, I believe that the top weight is in practice much > greater than the bottom weight; lots of effort gets spent on > agreement, but most real progress happens by fiat or near-fiat. (Case > study: rate of RFCs from IETF modulo number of participants at IETF > meetings over history; standards evolution through RFCs.) Without numbers to attach to this, your belief is just as speculative as my conjectures. FWIW, I don't think measuring the raw number of published RFC is a particularly useful metric. Measuring the number of RFC that actually make it to STD or BCP might be more useful. Measuring the number of those that are actually widely deployed would be even more useful. And raw numbers of IETF participants isn't a useful metric either ... we really need a measure of the true costs (work hours, plane trips, implementation costs to achieve interoperability etc.). > > Notice that the cost of agreement won't scale down to the typical > > case for the common interface in the same way as it does for > > multiple interfaces, because the common interface still requires > > global agreement whether or not all parties need to communicate > > with each other. > > It would be interesting to consider what the far-reaching > implications are when you start with a bias of "everyone needs to *be > able to* talk to everyone else" vs. "each party only needs to be able > to talk to certain other parties." Also interesting: whether and to > what extent assumption of a priori knowledge of "co-communicants" has > any impact. Agreed. As I said, I only have a conjecture and some anecdotal evidence. It'd be very interesting to see some serious research work done on this. Cheers, Miles
> Now, for the bonus bucks, give a comprehensive (formal) definition of > "integration complexity." (Please, please, please... make my life > easier. ;-) > > jb If this is a joke, I don't quite get it. The "complexity" referred to in the Big-Oh expressions is simply the number of interface mismatches that have to be dealt with, isn't it? Jeff, you may have to settle for having your life being made simpler, but not easier. Walden
Mark Baker wrote, > On Wed, Nov 20, 2002 at 11:01:45AM -0500, Miles Sabin wrote: > > And I also think that multiple interfaces are likely to scale > > better in the face of growth and change (yup, I realize that this > > runs completely counter to what _everyone_ else is saying ;-). > > That's because changes are liable to be local, hence in the > > multiple interface case only require local renegotiation and > > reimplementation; and because new participants only have to reach > > agreements with the subset of existing participants they actually > > need to communicate with. > > Yah, I understand that position, I think. But I think the Web has > shown that these sort of "local islands of closed-worldlyness" are > spurious as they succumb to the network effects inherrent in the > integration, anywhere, anytime approach of the Web. If there were always "network effects inherrent in the integration, anywhere, anytime approach of the Web" then I'd have to agree with you. But this is really the point at issue. I'm not at all convinced that those network effects are always there. Or if they are, their combined with a whole bunch of other effects which pull in the opposite direction. > As an example of this, I recently wanted to reference a Merriam > Webster definition of a word, but noticed that their primary > interface to their dictionary was via POST, not GET. They do have a > GET interface, which I later found, but that's not obvious to people. > So dictionary.com is now the defacto english language dictionary on > the Web since its primary interface is GET. Goodbye M-W. Do you have any evidence that this is a "GET vs. POST" issue rather than a "dictionary.com is easier to spell than miriam-wibster.com" issue? Or better content? Or a better UI (in ways orthogonal to REST)? > There's also the simple maintenance issue that it's cheaper to update > one interface than two, so if you've got a service exposed to the > world via HTTP, then you might as well use that even for private > agreements. Not necessarily. Simple maintenance is often evolution (I'm sure you've had the experience of a bug fix requiring a non-backwards compatible change). Evolution needs agreement, and it's easier to get two parties to agree to a change than three ... or three hundred. > > OTOH, on the common interface model every change requires global > > renegotiation and reimplementation; and new particpants either have > > to get along with what the first-movers already decided on whether > > or not it's fully appropriate for them, or alternatively simply not > > become participants at all (or become participants in something > > else). > > Yes, which is why incrementally deployed extensions are an absolutely > must. The Web has no "off" switch. HTTP, and things like RFC 2774 > (which improved on that), were designed exactly for this. Waka will > be even better, by the looks of it, with built in scoping and > mandatory extensions, like PEP and SOAP. Agreed completely ... which is why Waka is a new protocol rather than an extension of HTTP. Cheers, Miles
On Wednesday, November 20, 2002, at 01:37 PM, Mathews, Walden wrote: >> Now, for the bonus bucks, give a comprehensive (formal) definition of >> "integration complexity." (Please, please, please... make my life >> easier. ;-) >> >> jb > > If this is a joke, I don't quite get it. The "complexity" referred to > in the Big-Oh expressions is simply the number of interface mismatches > that have to be dealt with, isn't it? Sure. And that's an easy thing to intuit and to reason about... but turning that into a useful metric for system complexity has kept me up way too late many nights over the last couple of years... it's a subtle and slippery topic. :-) > Jeff, you may have to settle for having your life being made simpler, > but not easier. I can be satisfied with that. ;-) jb
Hi, does anybody know what Roy is referring to when he says: "Authoring methods (DAV simplified) - elimination on non-resource identifiers " Maybe QNames that identify properties? Julian [1] <http://www.apache.org/~fielding/waka/200211_fielding_apachecon.ppt> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > If this is a joke, I don't quite get it. The "complexity" > referred to > > in the Big-Oh expressions is simply the number of interface > mismatches > > that have to be dealt with, isn't it? > > Sure. And that's an easy thing to intuit and to reason about... but > turning that into a useful metric for system complexity has > kept me up > way too late many nights over the last couple of years... it's a > subtle and slippery topic. :-) The operative word being 'useful' I suppose. Complexity measure is just a measure of the number of pieces something has, but that might vary according to perspective, and not knowing yours, I'm powerless to comment. WM
On Wednesday, November 20, 2002, at 01:28 PM, Miles Sabin wrote: > In rare cases a proposal might be so instantly compelling that's it > achieves widespread adoption without any kind of negotiation being > needed. > > But let's face it ... that's pretty rare. What's rare is for any technology-by-consensus to achieve enough initial adoption to be relevant. OTOH, almost every technology that is broadly relevant in our industry was designed essentially by fiat by a small number of people and evolved --- slowly --- through consensus only after the adoption curve had already been ascended. SMTP. DNS. POP. IMAP. HTTP. Etc., etc., etc. > >> (HTTP is certainly an example of this.) > > I think it almost certainly _isn't_ an example of this. Take a look > through the HTTP WG archives and think how long it took for HTTP/1.1 to > be widely implemented and deployed. Exactly. This is an example of slow evolution once out "in the wild" --- slowness caused by the consensus-making effort. But the adoption curve had already been mostly ascended at that point. >> Very little if any innovation happens as the result of a >> consensus-making process. > > Agreed ... but we're not talking about innovation here, we're talking > about the adoption of common interfaces. Anyone with a bright idea can > strike out on their own, but it takes a different (and often more > expensive) kind of effort to get everyone else to follow. That's true. My point is that in the best examples of rapid adoption of technology that we've got to work with --- the Web, for instance --- the "common interface" that drives initial adoption is *not* the result of a consensus-building effort, but rather a unilateral innovation. >> Progress is driven by unilateral invention, and the rest of the world >> just follows along. > > I admire your optimism, but I'm afraid I don't share it. Actually, I don't see that as optimism at all --- more like something between pragmatism and fatalism. It would be great if it were the case that technological progress (wrt network protocols, for example) could be driven farther and faster by cooperative groups. Unf., there's almost a reverse scaling factor; the more heads get thrown at a problem, the less progress is made. I wouldn't call that realization "optimism" --- it relies on gestalt to drive things forward. And this isn't a philosophical position I particularly like, either. OTOH, look around: in the protocol and "killer app" worlds, you can clearly identify in every instance a small number of individuals who drove initial adoption and deployment. > Also note that continuous unilateral innovation is _disruptive_ of > existing standards ... a good thing IMO, and one which I think supports > my argument. I think we're arguing two different things, here. I'm arguing about how technological innovation and proliferation happens, you're talking about how technology incrementally evolves. > Umm ... big-Oh means I _don't_ need to weight anything. Actually, you're using big-Oh to measure dimensionless scalar quantities. What I'm saying is that you assume that you're using the *same* dimensionless scalar in both cases, and that's not a safe assumption. > As I said, I only have a conjecture and some anecdotal evidence. It'd > be > very interesting to see some serious research work done on this. If I ever manage to hit it big again, and manage to get out of the market with the shirt on my back, I'd like to do some "serious" research work on this. :-) jb
I am working on a REST based weblog interface, described here:
http://wellformedweb.org/RESTLog.cgi/5
the design of which is heavily influenced by:
http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger
Before I get too far along I want to make
sure I haven't wandered off into the weeds.
Any feedback would be greatly appreciated.
Thanks,
-joe
--
http://BitWorking.org
http://WellFormedWeb.org
One other thought. On Wednesday, November 20, 2002, at 10:01 AM, Miles Sabin wrote: > I'd also conjecture that O(N^2) is a wildly pessimistic worst case > because in practice not everybody needs to talk to everybody else. You > only need O(NlogN) edges in a random graph to get complete > connectivity, so O(NlogN) seems like a good guess for the typical, as > opposed to the worst, case. FWIW ... not proof, but I've seen data from > a major (ie. one that hasn't gone bust yet ;-) B2B exchange which > supports this. I would agree that O(N log N) is a sound estimate in this case... > For multiple interfaces that'd give us, > > O(NlogN) cost of integration (ie. NlogN implemented interfaces) > O(NlogN) cost of agreement (ie. NlogN bilateral agreements) > > For a common interface it'd give us, > > O(N) cost of integration > O(2^N) cost of agreement Another thing this misses is the asymmetry between consumers of an interface and producers of an interface; i.e., for most interfaces, the producer of an interface is not dependent on consensus among all intended consumers. In fact, in the open-world of the Web, the producer usually cannot even know a priori more than a very small subset of consumers, much less seek consensus among them. So N in the integration case is the number of interfaces, while in the agreement case there's really a different quantity involved --- M, the number of parties to the agreement a priori. And M is guaranteed to be a miniscule value relative to N. M != N! Perhaps the notation should reflect this; better to say something like: Closed world assumption, full participation of parties to agreement, type-specific interfaces: O(N log N) integration cost (N = number of implemented interfaces) O(N * M log M) consensus cost (M = number of bilateral agreements == total number of participants) Open world assumption, many non-agreeing consumers, generic interfaces: O(N) integration cost O(N * Q log Q) consensus cost (Q = producers / consumers party to agreement, Q << M) jb
Mathews, Walden wrote: > > A couple of minor points on big O. First "uniform interface drives > integration complexity to O(N)" is too easy to be true. It doesn't > take into account that while there is much similarity among peer > businesses, there is also individuality, a/k/a competitive edge, which > mandates, to a degree, custom interfaces. "Uniform interface" is like > "software process improvement". You use it to factor away known > redundancy, but no more. I think that this is an important point. To me, REST is about standardizing what can be standardized. It doesn't take a rocket scientist to recognize that addressing models can and should be standardized (or it might have taken a rocket scientist in the late 1990s, but it shouldn't today). Similarly, it doesn't take a rocket scientist to see that it is possible to standardize the method you use to to report or modify the state of a resource, or request the destruction of a resource. But applications do not consist of those two things so there will ALWAYS be effort in integrating applications. Just not necessarily in integrating their addressing schemes and method names. > Secondly, your position in the scheme of things determines whether you, > personally will feel integration as O(N) or O(N^2) or something else. > Basically, God is the only one with the N^2 problem, because it's the > system view of the system. An individual newcomer to a party without > uniform interfaces causes an integration problem (for itself and all > others > who wish to integrate with him) with a sum total of O(N). Over time, > from historical (God) perspecive, you would observe the N^2 thing, but > it's not a price paid daily. You don't observe the whole price daily, but when the newcomer cannot even conceptualize their service because the integration costs are so massive, the overall ecology pays the price. Paul Prescod
N is the number of web-based services (not HTTP server implementations, but the number of services that use Web infrastructure). That number is in the millions. The number of people who "agreed" on the details of HTTP are in the hundreds. I don't see how you can plausibly argue that there is an O(2^N) relationship there. Much more often, the majority of the people who adhere to a standard learn about it long after the standardization process is done. They buy the books that describe the standard (see also HTML). They don't even really "agree" to use it -- certainly not bilaterally, anyhow! They just use what everyone else is using, sometimes without even really wanting to! I really don't by the thesis that standards are created (or even adopted) through "agreement" between implementors and users. Paul Prescod
Jeff Bone wrote,
[snip: lots of stuff I largely agree with]
> I think we're arguing two different things, here. I'm arguing about
> how technological innovation and proliferation happens, you're
> talking about how technology incrementally evolves.
Yes, I think that's possible.
But I think that the main point I'm trying to make is that just like
"internet time", the idea of bandwagon and network effects have been
bandied around a little too lazily. The technological environment is
subject to many forces pulling in many different directions, and I
think that the phenomenon I've pointed to can, in at least some
circumstances, act as a counterveiling pressure to network effects.
I take your point that the initial takeoff of a new technology might
look more like a bandwagon than a consensus forming process.
Nevertheless, I can't help wondering if this is partly due to focussing
primarily on technologies which _did_ take off and ignoring the many
others that fell by the wayside. Perhaps there's no need for explicit
agreement, but there is a need to attract attention and foster
adoption. And that fails more often than not ... just look at the
activity levels of, eg., SourceForge projects. To a certain extent, I
think you may be pointing to the successful bandwagons and saying "Hey!
Look! Getting a bandwagon going isn't all _that_ hard".
I think I'm pointing to a later stage in the game where new technologies
are applied in pre-existing environments with pre-exisiting
constraints. It's not so much the technology which is the focus of
consensus forming, but the details of making it work in any given
context. And I'm also pointing to higher-level and narrower agreements
... not about TCP/IP or HTTP or REST or SOAP, but, eg., about how
widget consumers and producers can use those technologies to buy and
sell widgets. The semantic escalation makes agreement harder ("just
what _is_ a widget anyway?") and the narrower constituency means that
we're a long way from perfect markets (producers and consumers might
know each other, individual producers/consumers can influence the
market, political and strategic conflicts loom large).
Clearly things aren't _always_ like that. But equally we're not always
in the free market of ideas.
I'm also a little non-plussed, because it seems as tho' your argument
from heroic innovation also undercuts Mark/Roy's original point (but in
a different way from my argument). The original claim was that a
uniform interface drives integration complexity to O(N). Heroic
innovation says "screw the common interface, I'm going _this_ way,
follow me if you dare". That might settle down to a _new_ common
interface later ... but if it does I'll bet there will have had to be a
lot of consensus forming first.
Cheers,
Miles
Paul Prescod wrote, > N is the number of web-based services (not HTTP server > implementations, but the number of services that use Web > infrastructure). That number is in the millions. Actually, it's the number of _types_ of web-based services. Those types _potentially_ number in the millions, but I think we're a long way from that at the moment. And many of those types are of extremely narrow applicability and have a correspondingly narrow constituency with correspondingly more entrenched vested interests. > The number of people who "agreed" on the details of HTTP are in the > hundreds. I don't see how you can plausibly argue that there is an > O(2^N) relationship there. Right, but that's because HTTP is general purpose infrastructure, and that gets you a natural split between the producers and the largely passive consumers. The hundreds who were involved in the process represented a significant slice of the producers of that infrastructure. But not everything is general purpose infrastructure. The closer you get to the domain-specific the more the biases and interests of the participants come to the fore. And that's when consensus forming is needed. Cheers, Miles
Mark Baker wrote: > Wow! A lot more good stuff on Waka than he had previously discussed. > RENDER? Hmm, interesting. Not sure why an extended POST wouldn't > suffice for that, but I suppose a new method could be an optimization. I believe RENDER is safe and idempotent. I asked him about it at a conference many months ago and I understood what it meant then but am not confident in my memory anymore. Based on this dim recollection I hypothesize that RENDER is about the difference between retrieving a rendition and retrieving the "most semantically rich" version: DocBook rather than HTML, SVG rather than GIF. > MONITOR sounds familiar. 8-) Yes, that will be very interesting. He also mentioned unsolicited responses from servers to clients which is something that HTTP has long needed. > Note that Michael Radwin got the Web services comments backwards; they > don't solve the N^2 problem, they are the N^2 problem. Roy's point is > that a uniform interface drives integration complexity to O(N) (which > was Jeff's earlier comment) I think that the issue is pretty subtle...if the problem is to connect your accounting system to my account auditing system, agreeing on Waka methods and addressing is not going to collapse the problem to O(N). You need many other levels of agreement. The problem with SOAP/WSDL is that they don't standardize the things that CAN be standardized, with the most obvious examples being the addressing model and the GET method. Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > MONITOR sounds familiar. 8-) > > Yes, that will be very interesting. He also mentioned unsolicited > responses from servers to clients which is something that HTTP has long > needed. A response is always solicited due to a request (unless you have multiple responses or something, but there is still a cause). Perhaps this means a response not on the same connection - which implies message correlation. (Implied message correlation via a socket connection was a great enabling simplification, but adding more complexity will increase capability)
> 4. Metadata unable to come after data > I also like the fact that due to the asynchronicity of the protocol, you can interleave data and metadata. > This could be pretty handy if you realized that you needed to issue a Set-Cookie header in the middle of a response. I don't know the details, but this sounds like it may be easier for the server to send a stream of information, but it seems to cause clients to buffer the data until the end of the response which could be disastrous for perceived response time of a UI. It also might hurt the ability to do streaming responses if the metadata affects the processing of the streaming data.
S. Mike Dierken wrote: > ----- Original Message ----- > From: "Paul Prescod" > > >>MONITOR sounds familiar. 8-) > > > >Yes, that will be very interesting. He also mentioned unsolicited > >responses from servers to clients which is something that HTTP has long > >needed. > > A response is always solicited due to a request (unless you have > multiple responses or something, but there is still a cause). From the presentation: Unsolicited Responses Cache invalidation messages Multicast event notices So yes, there was probably a cause, but this particular response is not necessarily correlated with any particular request. Paul Prescod
Paul wrote: > Mark wrote: > > MONITOR sounds familiar. 8-) > > > > Yes, that will be very interesting. He also mentioned unsolicited > > responses from servers to clients which is something that HTTP has > > long needed. I'm not sure I understand the notion of an unsolicited response, but I think MONITOR is a great idea. In spending time trying to think of an approach for RESTful event notifications that simple, honest plain folks would understand, I've concluded that a method like MONITOR is the best approach, since the only alternative seems to be a bunch of state transfers between publisher, message bus, and subscriber. Does "unsolicited responses" refer to the zero or more subsequent state-change notifications that occur from a MONITOR request? Philip ________________________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. TradeWeb reserves the right to monitor all e-mail communications through its networks.
It's just wording, really, but keeping the lingo clean would probably mean using some term other than 'response' to mean unsolicited communiations, and reserving 'response' as the counterpart to a request. But what is solicited becomes grey upon analysis... Walden > -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Thursday, November 21, 2002 4:07 PM > To: S. Mike Dierken > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] fielding talks about waka at apachecon > > > S. Mike Dierken wrote: > > > ----- Original Message ----- > > From: "Paul Prescod" > > > > >>MONITOR sounds familiar. 8-) > > > > > >Yes, that will be very interesting. He also mentioned unsolicited > > >responses from servers to clients which is something that > HTTP has long > > >needed. > > > > A response is always solicited due to a request (unless you have > > multiple responses or something, but there is still a cause). > > From the presentation: > > Unsolicited Responses > Cache invalidation messages > Multicast event notices > > So yes, there was probably a cause, but this particular > response is not > necessarily correlated with any particular request. > > Paul Prescod > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >
----- Original Message ----- From: "Mathews, Walden" <walden.mathews@...> > It's just wording, really, but keeping the lingo clean would > probably mean using some term other than 'response' to mean > unsolicited communiations, and reserving 'response' as the > counterpart to a request. But what is solicited becomes grey > upon analysis... I'd start with 'unsolicited message' until we figure out what kind of message it is - request, response to a request, or event (where 'event' is a new type of message) or 'other'. I did a project where I defined the message types and sequence as: - 1 request - 0-n notifications events indicating interim status of request - 1 response indicating final status of request (closing the request) Events were purely advisory and optional. In HTTP the 202 Accepted response status is like an inital notification, but with no defined means to deliver the final response.
On Thu, Nov 21, 2002 at 11:30:50AM -0800, Paul Prescod wrote: > I think that the issue is pretty subtle...if the problem is to connect > your accounting system to my account auditing system, agreeing on Waka > methods and addressing is not going to collapse the problem to O(N). You > need many other levels of agreement. The problem with SOAP/WSDL is that > they don't standardize the things that CAN be standardized, with the > most obvious examples being the addressing model and the GET method. Sure. Another way of saying that is that, apples-to-apples, looking only at the interfaces, not the data you pass through them, it's O(N) vs. O(NlogN). Much useful data integration is also opaque, and therefore O(N). Any non-processed, aggregate data feed, like typical news & stock quote feeds, is opaque. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap i'll let you draw your own conclusions about this; suffice to say i take anything winer says with a pinch of salt since reading his contributions to the recent RDF flamewar. found here: http://use.perl.org/~gnat/journal/9071
Hmm... why is it that people keep comparing REST to SOAP? This is an apples-to-oranges comparison (possible more like fruit-to-apples). There is no REST toolkit because REST is not an implementable specification, just an architectural style. It seems to me that Dave's comments do nothing more than show he doesn't understand what REST is. I would have given a bit more credit to his opinion if he had instead asked/answered why SOAP isn't RESTful. Interestingly, (while I think that Dave should know better) I think this is one of the bigger stumbling blocks to the acceptance of REST. When I first heard about it, I too thought it was something like SOAP, XML-RPC, etc. This may be due to the fact that few people talk about REST separately from HTTP (at least outside of this list). As a result, I believe many people look at REST as competition instead of just another tool to (possibly) improve what they are working on. Hey, maybe we all need to come up with a single e-mail sig that says something to this effect. If we all use it, maybe people will take notice and get over some of the incorrect notions they have. How about: REST doesn't make the things you use. REST makes the things you use better. :) --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Vincent D Murphy" <vdm@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, November 22, 2002 5:18 AM Subject: [rest-discuss] dave winer on REST vs SOAP > http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap > > i'll let you draw your own conclusions about this; suffice to say i take > anything winer says with a pinch of salt since reading his contributions > to the recent RDF flamewar. > > found here: > http://use.perl.org/~gnat/journal/9071 > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
The value of REST is something akin to that of common sense, which is never a big marketing force, no matter how valuable it may be in practice. While the comparison between REST and SOAP may seem ill conceived to those in the know, it's the first line of distinction that someone embarking on a web services project will encounter, and there _is_ direct conflict between the poorer practices in SOAP use and the *constraints* of REST. So the dichotomy is not entirely fictional. This is a bad few decades for *constraints*, for some reason which I'm not clear on. The people who truly believe "less is more" are, well, few... It would seem. Walden > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@...] > Sent: Friday, November 22, 2002 8:34 AM > To: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] dave winer on REST vs SOAP > > > Hmm... why is it that people keep comparing REST to SOAP? This is an > apples-to-oranges comparison (possible more like > fruit-to-apples). There is > no REST toolkit because REST is not an implementable > specification, just an > architectural style. It seems to me that Dave's comments do > nothing more > than show he doesn't understand what REST is. I would have > given a bit more > credit to his opinion if he had instead asked/answered why SOAP isn't > RESTful. > > Interestingly, (while I think that Dave should know better) I > think this is > one of the bigger stumbling blocks to the acceptance of REST. > When I first > heard about it, I too thought it was something like SOAP, > XML-RPC, etc. > This may be due to the fact that few people talk about REST > separately from > HTTP (at least outside of this list). As a result, I believe > many people > look at REST as competition instead of just another tool to (possibly) > improve what they are working on. > > Hey, maybe we all need to come up with a single e-mail sig that says > something to this effect. If we all use it, maybe people > will take notice > and get over some of the incorrect notions they have. How about: > > REST doesn't make the things you use. REST makes the things > you use better. > > :) > > --- > Seairth Jacobs > seairth@... > > > ----- Original Message ----- > From: "Vincent D Murphy" <vdm@...> > To: <rest-discuss@yahoogroups.com> > Sent: Friday, November 22, 2002 5:18 AM > Subject: [rest-discuss] dave winer on REST vs SOAP > > > > http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap > > > > i'll let you draw your own conclusions about this; suffice > to say i take > > anything winer says with a pinch of salt since reading his > contributions > > to the recent RDF flamewar. > > > > found here: > > http://use.perl.org/~gnat/journal/9071 > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Thu, Nov 21, 2002 at 11:48:50AM -0800, S. Mike Dierken wrote: > > ----- Original Message ----- > From: "Paul Prescod" <paul@...> > > > > MONITOR sounds familiar. 8-) > > > > Yes, that will be very interesting. He also mentioned unsolicited > > responses from servers to clients which is something that HTTP has long > > needed. > A response is always solicited due to a request (unless you have multiple > responses or something, but there is still a cause). > Perhaps this means a response not on the same connection - which implies > message correlation. (Implied message correlation via a socket connection > was a great enabling simplification, but adding more complexity will > increase capability) I could imagine a non-opaque message identifier that when used opaquely, identified message equivalence, but could also be used to correlate messages as part of a single transaction. Or perhaps do that as two separate opaque URIs so that the transaction the message each had their own URI. Haven't thought it through. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Thu, Nov 21, 2002 at 11:52:44AM -0800, S. Mike Dierken wrote: > > > 4. Metadata unable to come after data > > > I also like the fact that due to the asynchronicity of the protocol, you > can interleave data and metadata. > > This could be pretty handy if you realized that you needed to issue a > Set-Cookie header in the middle of a response. > > I don't know the details, but this sounds like it may be easier for the > server to send a stream of information, but it seems to cause clients to > buffer the data until the end of the response which could be disastrous for > perceived response time of a UI. It also might hurt the ability to do > streaming responses if the metadata affects the processing of the streaming > data. Possible. But I'm more concerned with implementation complexity, both of a library, and of applications using the library. Not all of the complexity can be isolated from the app. Are there enough application protocol library developer gurus around that would know how to build such a library? I'd guess there would be an order of magnitude less people qualified to build such a beast. Would that hurt Waka's chance of success? I think it could, even if Roy does lead a libwww-waka project. Knowing Roy, I'm sure he's considered all this. Either he feels that the pros will outweigh the cons, or he's got something in mind for to address the cons. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Mark Baker wrote: > I could imagine a non-opaque message identifier that when used opaquely, > identified message equivalence, but could also be used to correlate > messages as part of a single transaction. Or perhaps do that as two > separate opaque URIs so that the transaction the message each had their > own URI. Haven't thought it through. Please try. This smells suspiciously like the "correlation IDs" from mailbox-and-dispatcher-SOAP that we trashed in a previous thread in this list. Why can't messages that are part of a conversation be related by references to the same URI, identifying a resource that they are conversing about? E.g. hypertext as engine of coordination.
Where does Dave come up with some of this stuff? Ridiculous. jb
Vincent D Murphy wrote: > http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap > > i'll let you draw your own conclusions about this; suffice to say i take > anything winer says with a pinch of salt since reading his contributions > to the recent RDF flamewar. You can't take anything Dave Winer says seriously. First, you can't believe anything he says because he spins like no tomorrow. Second, you can't take it personally because life is too short. If he wants to think we are against GUIs (!?!?!?) then I'll just take a deep breath and let him think what he wants. I was glad to read that Dave believes that SOAP is about taking the Internet and treating it like a LAN. I couldn't have said it better myself. ;) Paul Prescod
Seairth Jacobs wrote: > Hmm... why is it that people keep comparing REST to SOAP? This is an > apples-to-oranges comparison (possible more like fruit-to-apples). > There is no REST toolkit because REST is not an implementable > specification, just an architectural style. It seems to me that > Dave's comments do nothing more than show he doesn't understand what > REST is. I would have given a bit more credit to his opinion if he > had instead asked/answered why SOAP isn't RESTful. On the one hand, it is true that Dave doesn't understand what REST is. On the other hand, he has been told what it is several times, and it would only take a willingness to read his own inbox to understand why the things he said are BS. In fact, I'm sure as he was writing them, he knew what the counter-arguments were. But he sees everything in political terms and REST was not properly designed to be a political technology. It has an unweildy acronym and it is more about telling people to use stuff in the right way rather than selling them something new and improved. > REST doesn't make the things you use. REST makes the things you use > better. I like it. Paul Prescod
On Fri, Nov 22, 2002 at 05:52:15PM -0000, bhaugen32 wrote: > Mark Baker wrote: > > I could imagine a non-opaque message identifier that when used > opaquely, > > identified message equivalence, but could also be used to correlate > > messages as part of a single transaction. Or perhaps do that as two > > separate opaque URIs so that the transaction the message each had > their > > own URI. Haven't thought it through. > > Please try. This smells suspiciously like the "correlation IDs" from > mailbox-and-dispatcher-SOAP that we trashed in a previous thread in > this list. > > Why can't messages that are part of a conversation be related by > references to the same URI, That's what I'm suggesting be done, by identifying the transaction by a URI. For example, we might exchange messages and refer to a transaction that identifies some persistent contract that governs the rules of all messages sent as part of that contract. I recall you using an example like this before. > identifying a resource that they are > conversing about? I think that's a different thing, though perhaps you misspoke, or I'm misinterpreting you. I take that to mean the URI in the HTTP request line, e.g. "GET http://example.org/foo", rather than a URI identifying some context in which the conversation is occuring (while remaining stateless). MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Fri, Nov 22, 2002 at 10:37:38AM -0800, Paul Prescod wrote: > I was glad to read that Dave believes that SOAP > is about taking the Internet and treating it like a LAN. I couldn't have > said it better myself. ;) Yah, exactly. That's what I responded to in my blog; http://www.markbaker.ca/blog/2002/11/21#2002-11-winer-soap-rest MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Mark Baker > > Why can't messages that are part of a conversation be related by > > references to the same URI, > > That's what I'm suggesting be done, by identifying the transaction > by a URI. Ok, I misunderstood. > For example, we might exchange messages and refer to a transaction > that identifies some persistent contract that governs the rules of > all messages sent as part of that contract. I recall you using an > example like this before. Yes, precisely. For example, here is the UN/ECE recommended agreement for Offer-Acceptance transactions: http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf That's what I've been using as my prototype for such things. I think we have demonstrated that it could be RESTified, although I don't think all the details have been worked out yet. Once RESTified, it could be given a computable representation (e.g. XML or RDF, both of which UN/CEFACT is already working on) and referenced in all offer-acceptance transactions governed by that agreement. > > identifying a resource that they are > > conversing about? > > I think that's a different thing, though perhaps you misspoke, or I'm > misinterpreting you. I take that to mean the URI in the HTTP request > line, e.g. "GET http://example.org/foo", rather than a URI identifying > some context in which the conversation is occuring (while remaining > stateless). No, you're right, you misinterpreted me (as I did you above). The context for a transaction would include: * the transaction rules agreement e.g. the UN/ECE recommendation; * any long-term contracts between the trading partners; * the economic resources being traded, e.g. products, services, financial instruments, intellectual property, etc.; Then I think the transaction itself should have a URI, and also each of the speech acts (e.g. Offer and Acceptance or Rejection in an offer-acceptance transaction). If the transaction succeeds (e.g. the offer is accepted), then the trading partners have a new contract (e.g. an Order) which should also have a URI with links to the transaction that created it. So from the Order you would have a full set of legal evidence showing the transaction that created it, the speech acts involved in the transaction, message logs, etc. etc., all hyperlinked to the transaction rules. One could also code up an evaluator that determined if the transaction evidence followed the rules or not. -Bob Haugen
> Seairth Jacobs wrote: > > > Hmm... why is it that people keep comparing REST to SOAP? This is an > > apples-to-oranges comparison (possible more like fruit-to-apples). > > There is no REST toolkit because REST is not an implementable > > specification, just an architectural style. It seems to me that > > Dave's comments do nothing more than show he doesn't understand what > > REST is. I would have given a bit more credit to his opinion if he > > had instead asked/answered why SOAP isn't RESTful. > > On the one hand, it is true that Dave doesn't understand what REST is. > On the other hand, he has been told what it is several times, and it > would only take a willingness to read his own inbox to understand why > the things he said are BS. Truly bad arguments, especially when made by otherwise itnerllgient people, come generally from fear rather than ignorance. > In fact, I'm sure as he was writing them, he knew what the > counter-arguments were. But he sees everything in political terms and > REST was not properly designed to be a political technology. Thank heavens for that! Of course, if a major investment of your intellectual capital has been invested in politics, well ... > It has an unweildy acronym and it is more about telling people to use > stuff in the right way rather than selling them something new and > improved. Nothing wrong with the acronym! A "rest" is just what I want! A rest from all the hype, a rest from "solutions" that don't work, etc. > > REST doesn't make the things you use. REST makes the things you use > > better. > > I like it. > > Paul Prescod > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.gooseworks.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
On Fri, Nov 22, 2002 at 08:10:01PM -0000, bhaugen32 wrote: > So from the Order you would have a full set of legal evidence showing > the transaction that created it, the speech acts involved in the > transaction, message logs, etc. etc., all hyperlinked to the > transaction rules. One could also code up an evaluator that > determined if the transaction evidence followed the rules or not. Right. And as I remember us talking about before, it's very important that all this be done in the context of stateless interaction. How that would look, given the complexity of the stuff you listed, could be quite gnarly. It's the issue about whether the meaning is encapsulated in the identifier, or in what the identifier might resolve to at any given time. Sometimes, it might be necessary to include some of the things you mentioned by *value* in a message, rather than just by reference with a URI. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
bhaugen32 wrote: > Please try. This smells suspiciously like the "correlation IDs" from > mailbox-and-dispatcher-SOAP that we trashed in a previous thread in > this list. I don't read Roy's mind, but the term "transaction ID" strikes me as different than "correlation ID" in the sense that correlation IDs are for identifying conversations whereas I think of converstaions as being composed of transactions. So we might have a conversation spanning hours but a transaction would typically be only the minimal set of messages that must be grouped perhaps for atomicity reasons. Nevertheless, I do see some competition between the notions of statelessness and cross-message transaction identifiers. Paul Prescod
Oh, Dave is just full of Negative Energy(TM) all the time. ----- Original Message ----- From: "Jeff Bone" <jbone@...> To: "Seairth Jacobs" <seairth@...> Cc: <rest-discuss@yahoogroups.com> Sent: Friday, November 22, 2002 10:26 AM Subject: Re: [rest-discuss] dave winer on REST vs SOAP > > Where does Dave come up with some of this stuff? > > Ridiculous. > > jb > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
Mark Baker wrote: > On Fri, Nov 22, 2002 at 08:10:01PM -0000, bhaugen32 wrote: > > So from the Order you would have a full set of legal evidence showing > > the transaction that created it, the speech acts involved in the > > transaction, message logs, etc. etc., all hyperlinked to the > > transaction rules. One could also code up an evaluator that > > determined if the transaction evidence followed the rules or not. > > Right. And as I remember us talking about before, it's very important > that all this be done in the context of stateless interaction. How that > would look, given the complexity of the stuff you listed, could be > quite gnarly. It's the issue about whether the meaning is encapsulated > in the identifier, or in what the identifier might resolve to at any > given time. Sometimes, it might be necessary to include some of the > things you mentioned by *value* in a message, rather than just by > reference with a URI. It would be possible to include things by value, but you could get into conflicts if your included value differed from the reference. One of the simplifications in some of that discussion was Paul's suggestion for the reference to include the hash of the canonical representation of the referenced resource. But do you have any examples in mind of what you think would need to be included by value?
Paul Prescod wrote: > bhaugen32 wrote: > > > Please try. This smells suspiciously like the "correlation IDs" from > > mailbox-and-dispatcher-SOAP that we trashed in a previous thread in > > this list. > > I don't read Roy's mind, but the term "transaction ID" strikes me as > different than "correlation ID" in the sense that correlation IDs are > for identifying conversations whereas I think of converstaions as being > composed of transactions. So we might have a conversation spanning hours > but a transaction would typically be only the minimal set of messages > that must be grouped perhaps for atomicity reasons. Either which way, in business, conversations as well as transactions are about things that could be Web resources with URIs, and likewise speech acts in a conversation could have URIs and be referenced from future speech acts. > Nevertheless, I do > see some competition between the notions of statelessness and > cross-message transaction identifiers. Both conversations and transactions are inherently stateful. But I think the state of the conversation and transaction can be represented by Web resources in very much the ways you have outlined in several articles, unless I really misunderstood. So where do you see the competition coming in?
Has anyone else been receiving message threads in a screwed up order? For instance, the four messages in the "Transactions" thread between MarkB and BobH have come through in the order of "1, 3, 4, 2". There have been several other threads where I have come across the reply to a message before the message itself. Kinda annoying... just wondering if anyone else is experiencing this. :~\ --- Seairth Jacobs seairth@...
From: "Mathews, Walden" <walden.mathews@...> > The value of REST is something akin to that of common sense, > which is never a big marketing force, no matter how valuable > it may be in practice. Hmm. This does bring up the question of whether REST is common sense or not (I know that's not what Walden was actually saying). After all this time, I still have trouble grasping some parts of REST (and still disagree with other parts). From discussions on this list and others, I'm not sure that anyone short of Fielding "totally gets it" (though I could certainly be wrong; apologies to those folks). For those who are steeped in REST, it would be common sense. But to the rest of the world, I feel that REST is anything but common sense. On the other hand, the paradigm of SOAP treating the Internet like a big LAN does fall under the category of "common sense". Most technical and non-technical people immediately understand what that means. Many of those people can conceptualize it with little effort. Does it mean that it's the best way to go? Not necessarily. But the masses (those that make of the "common" sense; Dave Winer included) certainly seem to think so. Heck, I even see the simplicity and appeal to that model. Admittedly, I also see the issues involved as well, which is what got me interested in REST to begin with. While I can see how REST can help resolve some of the issues, it is far from clear to me how it will solve all of the issues. I think the reason is that REST just doesn't make sense overall. And as long as REST is not considered to be common sense, it will have limited acceptance. I don't see it becoming common sense any time soon, esp. when so few actually seem to grasp what it is. --- Seairth Jacobs seairth@...
Seairth Jacobs wrote: > Hmm. This does bring up the question of whether REST is common sense > or not (I know that's not what Walden was actually saying). this is an interesting question. i often wonder how many programmers/developers/whatever you want to call them actually understand the Web itself. i mean, i only really appreciated its fundamental qualities when i read timbl's _weaving the web_ a few times 2+ years ago. i feel there are many people out there who just view HTTP as a request/response mainframe protocol like CICS or whatever, but more graphical. URIs don't really feature in their thinking at all, apart from as a path in the filesystem on the web server. then i hear people with titles such as "web application developer" gush about how flash should replace html (or foo should replace bar), and wonder "what sort of 'web applications' do *you* develop!?" when i first read the RESTWiki (following a link from some oreillynet article a few months ago) i was saying "YES, this makes perfect sense". i had been struggling to build coherent web sites consisting of resources since late 2000 and lots of the theoretical and practical problems i had just evaporated when i read the RESTWiki and the dissertation. the other great thing was that there was a like-minded community to go with REST and i have found that a big help in my efforts. i'm rambling on a bit here, but my main point is that 'common sense' may be a subjective thing. most people would agree that the Web has been a fabulous success so far (so the web being viewed as a Good Thing is 'common sense') but this would not have been 'common sense' in 1992. maybe 'common sense' can be viewed as a function of how much new ground your breaking when introducing a new concept? how much are you challenging people's current way of thinking? in my view REST is 'just' boiling lots of distributed application theory down to a very simple core, but this is a radical step in itself. it seems to me that many distributed application architectures have tried to make the network look like one big computer, where you just call functions on other computers the way you call them on your own. but i think history has taught us that this doesn't work because it ignores the strengths and weaknesses that networks bring to the table. -v
http://www.markbaker.ca/blog//2002/11/17#2002-11-rdf because i have become interested in the relationship between REST and the Semantic Web, i found this intriguing. " The Semantic Web is the Web with an additional architectural constraint that could be called "Explicit Data Semantics"; that data (representations, in the case of the Web) will be constrained to be explicit about its implied semantics. This adds the additional desirable property to the system of partial understanding. " this is one of the simpler definitions of the semantic web that i have seen, and i think this is because it is more or less defined in terms of REST. (i.e. it's just one additional architectural constraint to an otherwise RESTful system.) of course small changes in architecture can imply large changes in their underlying implementations but i digress. i'm trying to ground this theory in the real world. what would it mean say if amazon have a resource for a book, or ebay has a resource for an auction? just imagine for a second that you have these URIs rather than the actual ugly implementation-dependent (asp/cgi/jsp/cfm) querystring-ridden cookie-dependent non-idempotent ones. http://www.ebay.com/auctions/2h4iug29225/ http://www.amazon.com/items/dh75s8d646/ this implies that amazon/ebay actually have well-defined resources for these URIs to identify. in the semantic web: - would the xml representations of these resources look different, or - would there be a completely seperate RDF representation, or - something else? i am involved in similar work to joe gregorio at http://wellformedweb.org ; we're just using different tools, and i haven't published my work yet. i am interested in how RDF can complement this type of work and make our RESTful systems Semantic_Web-ready. TIA, -vincent
On Sat, 23 Nov 2002, Vincent D Murphy wrote: > Seairth Jacobs wrote: > > > Hmm. This does bring up the question of whether REST is common sense > > or not (I know that's not what Walden was actually saying). > > this is an interesting question. > > i often wonder how many programmers/developers/whatever you want to call > them actually understand the Web itself. i mean, i only really > appreciated its fundamental qualities when i read timbl's _weaving the > web_ a few times 2+ years ago. i feel there are many people out there > who just view HTTP as a request/response mainframe protocol like CICS or > whatever, but more graphical. URIs don't really feature in their > thinking at all, apart from as a path in the filesystem on the web server. > > then i hear people with titles such as "web application developer" gush > about how flash should replace html (or foo should replace bar), and > wonder "what sort of 'web applications' do *you* develop!?" You might say that a lot of non-RESTful (I wish I could think of a good acronym for STRESSful ;-) approaches are tring to replace "commonsense" with "proprietary sense" ;-) Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.gooseworks.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
On Sat, Nov 23, 2002 at 02:28:48PM +0000, Vincent D Murphy wrote: > this is one of the simpler definitions of the semantic web that i have > seen, and i think this is because it is more or less defined in terms of > REST. (i.e. it's just one additional architectural constraint to an > otherwise RESTful system.) Glad you like it. > of course small changes in architecture can > imply large changes in their underlying implementations but i digress. It depends what architectural elements the constraint effects. In this case, it's a constraint purely on the data elements so is well isolated. > i'm trying to ground this theory in the real world. what would it mean > say if amazon have a resource for a book, or ebay has a resource for an > auction? just imagine for a second that you have these URIs rather than > the actual ugly implementation-dependent (asp/cgi/jsp/cfm) > querystring-ridden cookie-dependent non-idempotent ones. > > http://www.ebay.com/auctions/2h4iug29225/ > http://www.amazon.com/items/dh75s8d646/ > > this implies that amazon/ebay actually have well-defined resources for > these URIs to identify. in the semantic web: > > - would the xml representations of these resources look different, or > - would there be a completely seperate RDF representation, or > - something else? Potentially all of those. It's your choice. I'd opt for a combo of #1 and #2 if I can, i.e. if no XML schema is mandated. > i am involved in similar work to joe gregorio at > http://wellformedweb.org ; we're just using different tools, and i > haven't published my work yet. i am interested in how RDF can > complement this type of work and make our RESTful systems > Semantic_Web-ready. Just use RDF/XML instead of just XML. I found this article wonderful, both as a guide for how to introduce some RDF into your XML, but also as an intro to RDF (assuming you grok the very basics, i.e. triples); http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Sam Hunting wrote: > You might say that a lot of non-RESTful (I wish I could think of a > good acronym for STRESSful ;-) RESTless?
Mark Baker wrote: > It depends what architectural elements the constraint effects. In > this case, it's a constraint purely on the data elements so is well > isolated. cool. > >- would the xml representations of these resources look different, or > >- would there be a completely seperate RDF representation, or > >- something else? > > Potentially all of those. It's your choice. I'd opt for a combo of > #1 and #2 if I can, i.e. if no XML schema is mandated. i think (after studying the article referenced below again) the XML representation could have RDF merged in to it, or to put it another way, be 'annotated' with RDF. and of course there's nothing to stop you having a seperate RDF representation as well (presuming RDF has its own mime type already). and these do indeed seem to be mutually exclusive, i.e. you can do one without having to do the other. the way i see it, one of the nice things about designing a RESTful system is that you're 'forced' or constrained to consider which things should be resources, which should be properties of resources, etc. thus you end up treating the design of the system as (mostly) a matter of resource modelling. i suspect that RDF will fit in here very nicely because it just models all your resources and properties as a graph. > Just use RDF/XML instead of just XML. I found this article wonderful, > both as a guide for how to introduce some RDF into your XML, but also > as an intro to RDF (assuming you grok the very basics, i.e. triples); > > http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html thanks for the pointers. i think i'm ready to start playing with this now. regards, -vincent
http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM " If you want to make it easy for developers to try out your web service, your absolute best bet is to provide an XML-RPC interface. There's the least variability in what that means, and the greatest wealth of toolkits to choose from that factor out most of the gritty details for you. By and large REST interfaces don't tell you how to serialize and deserialize complex structures, so you kind of start from scratch every time. If they use a SOAP encoding, you get some of that. But there just is nothing simpler than saying "Here's the XML-RPC interface, and some sample code in a few of the popular scripting languages." " i see holes in just about every sentence of this but i wonder is it just me; i have nothing good to say about it so i'll shut up.
Vincent D Murphy wrote: > http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM > > " > If you want to make it easy for developers to try out your web service, > your absolute best bet is to provide an XML-RPC interface. There's the > least variability in what that means, and the greatest wealth of > toolkits to choose from that factor out most of the gritty details for > you. By and large REST interfaces don't tell you how to serialize and > deserialize complex structures, so you kind of start from scratch > every time. If they use a SOAP encoding, you get some of that. But > there just is nothing simpler than saying "Here's the XML-RPC > interface, and some sample code in a few of the popular scripting > languages." > > i see holes in just about every sentence of this but i wonder is it > just me; i have nothing good to say about it so i'll shut up. Let me suggest the following theory about Dave's understanding of XML: his only experience with the "X" in XML has been negative. People extended "his" RSS without his permission. This prevents him from seeing the problem with using a bowlderized XML vocabulary with extremely poor support for independent extensibility. Nevertheless, until he understands this issue, the "market" for XML-RPC-based solutions will be inherently capped. People will deploy a few, say, "yeah, that was fun and easy, but not extensible and scalable" and will just leave to try something else. It is not a flaw that REST applications preserve all of the flexibility of XML and even of MIME! XML-RPC cannot be used for anything as important as SMTP and HTTP while it has such a fixed and limited encoding. I can only presume that this is a major reason that so few reusable XML-RPC abstract service types have arisen...or perhaps it is the lack of a service description language. I'm not sure. Paul Prescod
Paul wrote: > XML-RPC cannot be used for anything as important as > SMTP and HTTP while it has such a fixed and limited > encoding. I can only presume that this is a major > reason that so few reusable XML-RPC abstract service > types have arisen...or perhaps it is the lack of a > service description language. I'm not sure. Since Dave Winer says my advocating REST means I don't actively develop software, I'm not sure if my opinion is valid ;-), but in my experience the quality and consistency of source code and design on the XML-RPC site is poor....it's as if someone threw a mish-mash of hyperlinks onto a single page so they could brag that it was implemented in 19 different languages. This, in addition to my dislike for both Dave *and* his opinion, have led me to the conclusion that he's just not worth my time. In fact, Dave and the XML-RPC site have served as a great example of who *not* to be and what *not* to do. -Philip __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus � Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Vincent D Murphy wrote: > http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM > "If you want to make it easy for developers to try > out your web service, your absolute best bet is to > provide an XML-RPC interface. There's the least > variability in what that means, and the greatest > wealth of toolkits to choose from that factor out > most of the gritty details for you. By and large > REST interfaces don't tell you how to serialize and > deserialize complex structures, so you kind of start > from scratch every time. If they use a SOAP encoding, > you get some of that. But there just is nothing > simpler than saying "Here's the XML-RPC interface, > and some sample code in a few of the popular > scripting languages." > > i see holes in just about every sentence of this but > i wonder is it just me; i have nothing good to say > about it so i'll shut up. Vincent, I think the above text you quote from Dave's Scripting News is a classic example of the "Plain Folks" technique of propaganda [1] used to persuade us to buy into XML-RPC (and hopefully buy his company's software). I've noticed he uses an approach that always smacks of, "...why don't you honest, hard-working folks come down to the bingo hall, press a simple link and kind of try out some plain old web services." I believe it's nothing more a way to cover up the real issues with an RPC approach, and specifically the problems with XML-RPC itself. Politicians often use this technique to challenge the cultural and economic elite, similar to the way it seems that Dave is using it to challenge Microsoft and other giants in the software industry. Philip 1. http://www.propagandacritic.com/articles/ct.sa.plain.html __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus � Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
http://www.eweek.com/article2/0,3959,720306,00.asp This one is pretty funny, calling REST a "new development approach". Most of it is typical FUD. Toivo Lainevool
I read the article - not bad for the media. But, boy, DaveW's comments sure are stupid. I really have to question his understanding of technology. As CEO of a software company, you'd expect more intelligence with regard to software and the people who build it. Mike ----- Original Message ----- From: "Toivo "Deutsch" Lainevool" <tlainevool@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, November 25, 2002 6:31 PM Subject: [rest-discuss] Another REST vs. SOAP article > http://www.eweek.com/article2/0,3959,720306,00.asp > > This one is pretty funny, calling REST a "new development approach". > Most of it is typical FUD. > > > Toivo Lainevool > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
S. Mike Dierken wrote: > I read the article - not bad for the media. > But, boy, DaveW's comments sure are stupid. > I really have to question his understanding of technology. > As CEO of a software company, you'd expect more intelligence with > regard to > software and the people who build it. A year ago, Dave Winer said REST wasn't important because the only people who had heard about it were a few people on FoRK and a couple in the O'Reilly clan. Now he's being asked about it on EWeek and not laughing it off, but attacking it. I've never so clearly seen the steps of: http://www.brainyquote.com/quotes/quotes/m/q103630.html It is too bad that the issues are not reducible to sound bites because we're going to have to withstand more media misunderstanding. In fact, years from now when developers just use hyperlinks, generic interfaces, URIs stateless messaging, and so forth instinctively, the media people will ask: "remember back when it seemed like SOAP was going to be really big and important and there was some other thing? What was that other thing again? I never understood it and now nobody talks about it anymore. I guess it died." If there isn't a working group with a spec and somebody working oa For Dummies book, it will never have an existence these guys can understand. Paul Prescod
You know, the great thing about all of this is... it just doesn't
matter. It's like that old saying: the great thing about facts is
that it doesn't matter if anybody believes them. It doesn't matter if
99.9999% of the industry fails to understand REST (today); it doesn't
matter if Dave Winer ever gets a clue, or if the press fans this
"debate" into such a hypestorm that everybody gets sick of it.
REST is hype-proof. It's idiot-proof. It's debate-free. REST is
about the things that made the Web successful; loose coupling, naming,
generic interfaces, etc. You can't argue with the Web! If you do, you
just end up sounding stupid, like our buddy Dave.
You can't treat the Internet like a LAN. You can't pretend open worlds
are like closed worlds. Tight coupling isn't the same as loose
coupling. Coordination and composition doesn't work the same way in
the wild. That beautiful hothouse flower is gonna get clobbered by the
kudzu if you plant it out in the yard.
Our industry has made several runs at this wall, and failed to get over
it every time; eventually, people will get it --- the key to learning
is repetition. Until then, those who didn't learn any any of the past
{ ONC RPC, DCE, CORBA, DCOM, RMI } attempts will just keep repeating
history...
The only net effect of this is that eventually, when people finally
*get* this thing, some of us will be justified in feeling, maybe just a
little bit, smug. :-)
jb
On Tuesday, November 26, 2002, at 11:11 AM, Dave Winer wrote:
> You guys should read this:
>
> http://www.decafbad.com/news_archives/000332.phtml
>
> And get off your butts and make some toolkits and until you do shut up
> because you're not making any sense.
Two bits, Dave: first, just because something doesn't make sense to
you does *not* mean that it doesn't make sense.
Second: the fallacy of this "SOAP / XML-RPC vs. REST" debate is that
it's apples and oranges; REST is an architectural style, not a
particular integration technology. As such, it's not necessarily the
case that it needs a toolkit. Certainly, it would be nice if tools
mapped better to the model, but make no mistake: every non-SOAP /
non-XMLRPC Web App out there is an existance proof (to a greater or
lesser extent) of REST. You guys are in the minority today.
jb
>
> Dave
>
>
> ----- Original Message -----
> From: "Jeff Bone" <jbone@...>
> To: "S. Mike Dierken" <mdierken@...>
> Cc: <rest-discuss@yahoogroups.com>; <dave@...>
> Sent: Tuesday, November 26, 2002 8:27 AM
> Subject: Re: [rest-discuss] Another REST vs. SOAP article
>
>
>>
>> You know, the great thing about all of this is... it just doesn't
>> matter. It's like that old saying: the great thing about facts is
>> that it doesn't matter if anybody believes them. It doesn't matter if
>> 99.9999% of the industry fails to understand REST (today); it doesn't
>> matter if Dave Winer ever gets a clue, or if the press fans this
>> "debate" into such a hypestorm that everybody gets sick of it.
>>
>> REST is hype-proof. It's idiot-proof. It's debate-free. REST is
>> about the things that made the Web successful; loose coupling,
>> naming,
>> generic interfaces, etc. You can't argue with the Web! If you do,
>> you
>> just end up sounding stupid, like our buddy Dave.
>>
>> You can't treat the Internet like a LAN. You can't pretend open
>> worlds
>> are like closed worlds. Tight coupling isn't the same as loose
>> coupling. Coordination and composition doesn't work the same way in
>> the wild. That beautiful hothouse flower is gonna get clobbered by
>> the
>> kudzu if you plant it out in the yard.
>>
>> Our industry has made several runs at this wall, and failed to get
>> over
>> it every time; eventually, people will get it --- the key to learning
>> is repetition. Until then, those who didn't learn any any of the past
>> { ONC RPC, DCE, CORBA, DCOM, RMI } attempts will just keep repeating
>> history...
>>
>> The only net effect of this is that eventually, when people finally
>> *get* this thing, some of us will be justified in feeling, maybe just
>> a
>> little bit, smug. :-)
>>
>> jb
>>
----- Original Message ----- From: "Dave Winer" <dave@...> > > 2. That's news to me. Ever since Mark and Paul started promoting this thing > it's always been presented as a reason for not doing XML-RPC and SOAP. Until > you manage to convince others to stop spinning it that way (assuming you're > not) you gotta live with it. Well, I think MarkB and PaulP have spent a bunch of time and effort on educating and steering web service standards toward a pattern of use that follows the principals that many people feel made the Web successful. For example, kicking off discussion of using GET in conjunction with WSDL, etc. So from what I've seen, it's about how to use SOAP /better/, not about a replacement. > Sorry, I didn't make it so. No need to apologize, you didn't do anything wrong.
On Tuesday, November 26, 2002, at 12:16 PM, Dave Winer wrote: > Let's end the whining now. Okay, please do. ;-) > I don't really care about REST. You don't really understand REST, Dave. ;-) You just said "I don't really care about the Web." jb
----- Original Message ----- From: "Dave Winer" <dave@...> > Yeah, but the link I sent wasn't about SOAP -- it was about XML-RPC. Would you like us to take a look at XML-RPC & make suggestions for improvements? > > Let's end the whining now. Sorry - didn't mean to sound whining. > I don't really care about REST. Some PC WEEK reporter wanted some soundbites. Hmm. If somebody asks again, could you refer them to this discussion group, or to PaulP or MarkB? We do care & it'll get the reporters off your back in the future.
To compare apples to apples I think we should be comparing REST and SOA (Service Oriented Architecture). REST is typified by HTTP/URI and SOA is typified by UDDI/WSDL/SOAP. I'm not exactly sure where XML-RPC fits in to this mix, probably in place of SOAP in the SOA stack. I think this would be a useful comparison to make. I've tried to broach this subject on the rest-discuss list before, but got slammed pretty hard because of the understandably REST-oriented view of the list. Can anyone suggest an appropriate forum for such a discussion? Is there some mailing list where people would be willing to discuss the merits and shortcomings of both REST and SOA? I don't want to get into a war about this on the rest-discuss list because things would be pretty lopsided. Maybe it would be worthwhile to start some kind of "Machine-to-Machine Architectures for the Internet" group on Yahoo to discuss this? Topics like REST, SOA and Grid Computing could be discussed, with proponents of each approach and neutral people (like me) discussing the issues involved. Or is this just too much of a religious issue for everyone? Toivo Lainevool > -----Original Message----- > From: Jeff Bone [mailto:jbone@...] > Sent: Tuesday, November 26, 2002 9:24 AM > > Second: the fallacy of this "SOAP / XML-RPC vs. REST" debate is that > it's apples and oranges; REST is an architectural style, not a > particular integration technology. As such, it's not necessarily the > case that it needs a toolkit. Certainly, it would be nice if tools > mapped better to the model, but make no mistake: every non-SOAP / > non-XMLRPC Web App out there is an existance proof (to a greater or > lesser extent) of REST. You guys are in the minority today. >
Jeff Bone wrote: > > > Two bits, Dave: first, just because something doesn't make sense to > you does *not* mean that it doesn't make sense. Jeff, Dave is a lost cause. He's a classic dug-in vested interest. I'm struggling to keep this from getting any more personal than Dave has already made it. I don't believe that's how technical discussions should be conducted. XML-RPC will probably continue to be a success for small, simple apps until the next wave of RPC-reinvented overtakes it: SVG-RPC? RDF-RPC? YAML-RPC? In the meantime, I don't think we should begrudge XML-RPC any success in those domains. It works for what it works for and does not work for what it doesn't work for and the market would figure that out without any effort from us. Over the last year, we've seen REST has substantial momentum and a variety of successful applications. Everywhere I go, people come up to me and thank me for articulating what, to them, was always common sense. REST is still the leading way to publish and update complicated datasets using XML or HTML. In that vein, I've finally started a long delayed project, which is to start listing the public REST apps people tell me about when I meet them. I've surely forgotten most of them because I'm just cobbling together the list from memory. http://www.prescod.net/rest/apps As far as REST toolkits: Roy Fielding (a classic example of someone who spends all day talking rather than doing) codified REST and built several "toolkits" around it. One is called Apache. Others that I have experimented with are Quixote, Zope and Microsoft .NET. And as long as we're throwing around case studies: http://effbot.org/zone/rest-vs-rpc.htm He mentions that there were two "aha" moments that lead him from XML-RPC to REST -- before he even knew that the latter has a name: 1. He learned more about XML and how to work with it. 2. He needed to work with binary data and realized that URIs and HTTP were excellent for that. It is my strong sense that the more popular XML becomes the less frightened people will be of using REST. It won't be possible to scare them away by saying: "you might have to parse XML!" Paul Prescod
----- Original Message ----- From: "Toivo "Deutsch" Lainevool" <tlainevool@...> > To compare apples to apples I think we should be comparing REST and SOA > (Service Oriented Architecture). REST is typified by HTTP/URI and SOA > is typified by UDDI/WSDL/SOAP. I'm not exactly sure where XML-RPC fits > in to this mix, probably in place of SOAP in the SOA stack. > > I think this would be a useful comparison to make. I've tried to broach > this subject on the rest-discuss list before, but got slammed pretty > hard because of the understandably REST-oriented view of the list. I'm sorry you got slammed - that really isn't appropriate for a discussion group like rest-discuss. Are you willing to try again? I'll review the old posts & see what the attitude was like - but for me, I would appreciate comparisons between REST and other architectural styles.
On Tuesday, November 26, 2002, at 07:53 PM, Paul Prescod wrote: > Jeff Bone wrote: > >> Two bits, Dave: first, just because something doesn't make sense to >> you does *not* mean that it doesn't make sense. > > Jeff, Dave is a lost cause. He's a classic dug-in vested interest. I'm > struggling to keep this from getting any more personal than Dave has > already made it. I don't believe that's how technical discussions > should be conducted. Personal is often Dave's style. I've faced the wrath of Dave before, Paul. Apparently, around '97 or so, I was "interfering" with the fate of Apple Computer --- and Dave gave me what-for about it. And frankly, he was at least partially right: Apple wasn't dead despite how much I or anybody else thought otherwise. I keep hoping to bring him around on this one, because IME he's brilliant... just under- or mis-informed. (And like, ahem, "certain other people" ;-) he can be quite vocal about it, and doesn't like being told he's under- or mis-informed. ;-) And I figure if a hard case like me deserved enough attention and education from e.g. Mark and Roy back when to bring me around, then Dave deserves at least as much. I just wish Dave would take some of his own medicine. Every time this comes up, he seems to forget that he's asked me the same question, and got the same answer: yes, I've not only looked at XML-RPC, I've used it, on more than one occasion and with more than one language binding. I just wish he'd apply the same diligence to trying to understand the point of REST that the rest of us have, and that he would himself do re: REST the same thing that he encourages in others -wrt- understanding XML-RPC, etc. jb
I've asked few weeks ago about using Jabber as a protocol for a rest- architectural system. I haven't well understood the answer, which was a link to the wikki FAQ. Here are my thoughts about jabber (mainly from "Programming Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest. - Jabber is resources oriented: you can specify a resources for any kind of "things" in the jabber world. For "human users", it could be the client on desktop at work, the client on laptop, the bot logging conference rooms, and so on. For a server agent, it could be any thing you want, e.g. a channel feeding rss, a room for conference transport, etc. - Jabber is full XML, in the protocol, the communications and the data. Even the storage is XML (it could be also a DB or an other kind of persistence system). Moreover, it rely on name spaces. Therefore it is fully extensible. - Resource management is based on few methods, such as "get" and "set" - All resources are "browsable", that is you can "query" a resource to know some kind of metadata about it. For a service for example, it return the fields to fill to subscribe. It could be parameters required to submit a query, or whatever. In many clients, forms are dynamically built according to this feature. - The connection can be server initiated (i.e. push) which can't be done with http. This can be useful in many context, specially in asynchronous systems. - Use management and subscription (and authentication) is built-in. Authentication is included in HTTP, but the subscription stage left to the implementation. - As in http, communication can be secured with ssl Reading jabber stuff, I thought about other suitable things, but i can't remember them right now. It seems to me that all HTTP feature can be managed with jabber, but with other built-in cool added possibilities. Another approach... Does anyone here has implemented (or tested, or at least thought about) a rest architecture above Gnutella? I've recently learned that Gnutella is actually extended Http. It could solve the "push" problem, and other aspect that I wanted delegate to Jabber :) I know that HTTP is one of the foundations of Rest, but take the time to think about these ideas. I hope I'm not too presumptuous, and I certainly miss something. So please explain... :) Thanks in advance ------------------------------- Yannick Loiseau mailto:yloiseau@... -------------------------------
Hi Yannick - I'd certainly like to get the lists opinion on this too. I have ( as have others in the Jabber community ) wondered about Jabbers' place in the REST world. Jabber appears to have some of the key components for REST with URIs and a few of the RESTian verbs. Is it actually necessary for a toolset to implement all features of REST, or would the REST community be willing to endorse toolsets to a level of REST support? all food for thought IMHO. Cheers. On Wed, Nov 27, 2002 at 11:29:55AM +0100, Yannick Loiseau wrote: > > > I've asked few weeks ago about using Jabber as a protocol for a rest- > architectural system. I haven't well understood the answer, which was a link > to the wikki FAQ. Here are my thoughts about jabber (mainly from "Programming > Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest. > - Jabber is resources oriented: you can specify a resources for any > kind of "things" in the jabber world. For "human users", it could be the > client on desktop at work, the client on laptop, the bot logging conference > rooms, and so on. For a server agent, it could be any thing you want, e.g. a > channel feeding rss, a room for conference transport, etc. > - Jabber is full XML, in the protocol, the communications and the > data. Even the storage is XML (it could be also a DB or an other kind of > persistence system). Moreover, it rely on name spaces. Therefore it is fully > extensible. > - Resource management is based on few methods, such as "get" and "set" > - All resources are "browsable", that is you can "query" a resource to > know some kind of metadata about it. For a service for example, it return the > fields to fill to subscribe. It could be parameters required to submit a > query, or whatever. In many clients, forms are dynamically built according to > this feature. > - The connection can be server initiated (i.e. push) which can't be > done with http. This can be useful in many context, specially in asynchronous > systems. > - Use management and subscription (and authentication) is built-in. > Authentication is included in HTTP, but the subscription stage left to the > implementation. > - As in http, communication can be secured with ssl > Reading jabber stuff, I thought about other suitable things, but i can't > remember them right now. > It seems to me that all HTTP feature can be managed with jabber, but with > other built-in cool added possibilities. > > Another approach... Does anyone here has implemented (or tested, or at least > thought about) a rest architecture above Gnutella? I've recently learned that > Gnutella is actually extended Http. It could solve the "push" problem, and > other aspect that I wanted delegate to Jabber :) > I know that HTTP is one of the foundations of Rest, but take the time to think > about these ideas. I hope I'm not too presumptuous, and I certainly miss > something. So please explain... :) > Thanks in advance > > ------------------------------- > Yannick Loiseau > mailto:yloiseau@... > ------------------------------- > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
----- Original Message ----- From: "Yannick Loiseau" <yloiseau@...> > > > I've asked few weeks ago about using Jabber as a protocol for a rest- > architectural system. I haven't well understood the answer, which was a link > to the wikki FAQ. I'd like to see some more discussion comparing features of Jabber with aspects of REST also. > Here are my thoughts about jabber (mainly from "Programming > Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest. > - Jabber is resources oriented: you can specify a resources for any > kind of "things" in the jabber world. For "human users", it could be the > client on desktop at work, the client on laptop, the bot logging conference > rooms, and so on. For a server agent, it could be any thing you want, e.g. a > channel feeding rss, a room for conference transport, etc. Can you access all of those 'things' with common operations? Is it possible to write a Jabber Spider that cruises all the information and learns something about each? > - Jabber is full XML, in the protocol, the communications and the > data. Even the storage is XML (it could be also a DB or an other kind of > persistence system). If Jabber is a protocol, what does it need to define storage for? Maybe certain apps on top of Jabber use XML storage? > Moreover, it rely on name spaces. Therefore it is fully extensible. Not necessarily. Namespaces provide one kind of capability, but there are a lot of really smart people that think namespaces don't do anything to solve other integration and extensibility problems. (Don't have links handy right now...) > - Resource management is based on few methods, such as "get" and "set" > - All resources are "browsable", that is you can "query" a resource to > know some kind of metadata about it. For a service for example, it return the > fields to fill to subscribe. It could be parameters required to submit a > query, or whatever. In many clients, forms are dynamically built according to > this feature. > - The connection can be server initiated (i.e. push) which can't be > done with http. This can be useful in many context, specially in asynchronous > systems. How does a server initiate a connection to a node that is behind a firewall? Whatever is used can also be used to initiate a connection that then transitions to plain HTTP with the firewalled node becoming the logical 'server'. > - Use management and subscription (and authentication) is built-in. What kind of user management is built-in? I'll look for this... > Authentication is included in HTTP, but the subscription stage left to the > implementation. > - As in http, communication can be secured with ssl > Reading jabber stuff, I thought about other suitable things, but i can't > remember them right now. > It seems to me that all HTTP feature can be managed with jabber, but with > other built-in cool added possibilities. > > Another approach... Does anyone here has implemented (or tested, or at least > thought about) a rest architecture above Gnutella? Not that I know of, but it sure sounds interesting. > I've recently learned that Gnutella is actually extended Http. Interesting. I wonder how much is extended according to 'extension' specifications - and how much of the 'extensions' were actually necessary (often people don't think HTTP can do some things and so assume they need to invent a new way of doing it.) > It could solve the "push" problem, and other aspect that I wanted delegate to Jabber :) It won't solve the push problem. The 'push' problem can be solved with any TCP/IP protocol by having the server initiate a persistent connection to a routing/dispatching proxy. That is basically how many systems do it. Nobody has yet shipped a reference implementation that is as 'pure http' as possible yet. But that might change soon. > I know that HTTP is one of the foundations of Rest, but take the time to think > about these ideas. I hope I'm not too presumptuous, and I certainly miss > something. So please explain... :) Keep up the good questions.
On Wed, Nov 27, 2002 at 02:37:48PM +0000, Piers Harding wrote:
> Hi Yannick - I'd certainly like to get the lists opinion on this too. I
> have ( as have others in the Jabber community ) wondered about Jabbers'
> place in the REST world.
>
> Jabber appears to have some of the key components for REST with URIs and
> a few of the RESTian verbs.
I haven't looked at the Jabber protocol in any detail in quite some
time, but REST is an architectural style that is extremely constraining.
A system doesn't "conform" to REST's constraints by accident, it has to
be intentionally designed to do so.
Jabber, like pretty much every other system out there, can be engulfed
by the Web, in the same way that FTP and email/SMTP were absorbed; by
constraining interactions with that system to uniform interface
semantics, and mapping the space of identifiable things in that system
into URI space (often requiring a new URI scheme).
> Is it actually necessary for a toolset to implement all features of
> REST, or would the REST community be willing to endorse toolsets to a
> level of REST support?
I'm not sure what that means ("level of REST support"). Do you have an
example?
MB
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Will distribute objects for food
----- Original Message ----- From: "Piers Harding" <piers@...> > Is it actually necessary for a toolset to implement all features of > REST, or would the REST community be willing to endorse toolsets to a > level of REST support? I think the current REST community is an education-oriented group & the members aren't really 'endorsing' things. There are a lot of people that are more than willing to look at designs, tools, and technology & make suggestions for improvements based on aspects of REST, and often based on HTTP implementation details. So it's more of a "We're here to help." rather than "You're not a member of the club" type of thing. Endorsement comes from the community using the tools and from the tools following community developed specifications (like HTTP, SMTP, DNS, etc).
Toivo "Deutsch" Lainevool wrote: > To compare apples to apples I think we should be comparing REST and > SOA (Service Oriented Architecture). REST is typified by HTTP/URI and > SOA is typified by UDDI/WSDL/SOAP. I'm not exactly sure where XML-RPC > fits in to this mix, probably in place of SOAP in the SOA stack. Except that XML-RPC is hardly ever used with UDDI or WSDL. > I think this would be a useful comparison to make. I've tried to > broach this subject on the rest-discuss list before, but got slammed > pretty hard because of the understandably REST-oriented view of the > list. Cananyone suggest an appropriate forum for such a discussion? > Is there some mailing list where people would be willing to discuss > the merits and shortcomings of both REST and SOA? You could try "distributed objects". > I don't want to get into a war > about this on the rest-discuss list because things would be pretty > lopsided. Maybe it would be worthwhile to start some kind of > "Machine-to-Machine Architectures for the Internet" group on Yahoo to > discuss this? Topics like REST, SOA and Grid Computing could be > discussed, with proponents of each approach and neutral people (like > me) discussing the issues involved. Or is this just too much of a > religious issue for everyone? I would not be surprised if it continually degraded into flame wars but you could give it a try. I'll start the flaming by saying that I have never understood, from even before I had heard of REST, why it makes sense to distinguish some resources as "services" and treat them differently than other resources. Most of the justifications here: http://www.developer.com/db/article.php/1010451 seem illogical to me. Paul Prescod
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> > > > Another approach... Does anyone here has implemented (or tested, or at > least > > thought about) a rest architecture above Gnutella? > Not that I know of, but it sure sounds interesting. > > > I've recently learned that Gnutella is actually extended Http. > Interesting. I wonder how much is extended according to 'extension' > specifications - and how much of the 'extensions' were actually necessary > (often people don't think HTTP can do some things and so assume they need to > invent a new way of doing it.) It looks like the 'query' aspect is the non-HTTP part, file retrieval is pure HTTP GET. The information space will be (poorly) organized based on each region's interpretation of a query. Some machines will treat ".mp3" differently than others. A single query will return qualitatively different results. This is also true of pure HTTP, but the addition of <FORM> helped create richer queries (names and values). For example, if today's Gnutella queries look like ".mp3", changing this to "name=*.mp3" may help servers return more relevant results. > > > It could solve the "push" problem, and other aspect that I wanted delegate > to Jabber :) > It won't solve the push problem. The 'push' problem can be solved with any > TCP/IP protocol by having the server initiate a persistent connection to a > routing/dispatching proxy. That is basically how many systems do it. Nobody > has yet shipped a reference implementation that is as 'pure http' as > possible yet. But that might change soon. This is interesting - a Gnutella node behind a firewall can't respond to GET, but it can respond to a request to 'push the content' to you. If a node can respond to /anything/ at all, then you can do a GET via a proxy, but HTTP has problems with this since it is connection oriented. More thought needed. Regarding Gnutella - here is an excellent introduction: http://www.rixsoft.com/Knowbuddy/gnutellafaq.html#overview Relevant paragraphs: === Searching Searching works similarly to connecting: you send out a search request, it is propagated through the network, and each servent that has matching terms passes back its result set. Each servent handles the search query in its own way. The simple query ".mp3" could be handled in different ways by different servents: one servent might take it literally, matching anything with ".mp3" in it, while another might interpret it as a regular expression and match any character followed by "mp3". To save on bandwidth, a servent does not have to respond to a query if it has no matching items. The servent also has the option of returning only a limited result set, so that it doesn't have to return 5000 matches when someone searches for "mp3". Since all of the searches are to the local servent's database, the servent sees what everyone else is searching for. Using this, most clients have a Search Monitor that allows the user to see, in real time, the searches that their servent is responding to. Downloading For file sharing, each servent acts as a miniature HTTP web server. Since the HTTP protocol is well established, existing code libraries can be used. When you find a search result that you want to download, you just connect to the servent in the same way your web browser would connect to a web server, and you are good to go. Of course, the servent has this built-in, so your normal web browser never has to enter the picture. Servents are also smart enough to compensate for firewalls. If you are behind a firewall that can only connect to the outside world on certain ports (80, for instance) you will just need to find a servent running on port 80. Since the servents can serve on any port, you are likely going to find one that is serving on a firewall-friendly port. Also, if you are trying to download a file from a servent that is behind a firewall, you can ask the firewalled servent to push the file to you since you will not be able to connect to it directly. The only thing the protocol cannot compensate for is file transfers between two servents behind two different firewalls. In such a case, there really isn't anything that can be done. ===
> I'll start the flaming by saying that I have never understood, from even > before I had heard of REST, why it makes sense to distinguish some > resources as "services" and treat them differently than other resources. > Most of the justifications here: > > http://www.developer.com/db/article.php/1010451 > > seem illogical to me. > > Paul Prescod I don't think the article made a good case for the difference between a service and a resource either, so I'll take a stab at it. One of the major differences between SOA and REST is that SOA systems are Distributed System and REST systems are Network-Based System. (See http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_ 2_1_1 for the distinction). So a "service" is something that SOA toolkits hide behind a local proxy, trying to shield as much as possible the fact that a message is going out over the network. This is why an SOA based system needs to include a interface definition language like WSDL. This allows services to be defined in a way that, for example, allows a Java based SOAP middleware product to present the service to the end user as a Java interface. This isn't necessarily the case when using REST. Of course you can always wrap something around a RESTful network message to make it transparent to the end user, but this isn't something that the architecture itself tries to impose. The interface to a resource is baked into the system itself (e.g. HTTP's Get, Put, Post, Delete). To summarize, one of the big differences is that a resource has an interface that is defined by the architecture itself, while a service has a user definable interface. Toivo Lainevool
Well, as Yannick has allready stated - the Jabber protocol supports some
verbs with the IQ element ( a conversation fragment ) and there are
fragment types of get, set, result, and error. The 'to' attribute
specifies a URI that can be directed to a specific presence ( or
unspecific ) of a client ( typically an IM user, but certainly doesnt
have to be ), or a component with or without a resource specification ( a
component can be local or remote - it doesn't matter ) eg.
somebody@.../work-desk-5 ( client ) or
some.host/browse-component/whateverIcaretoputhere.
Within the IQ (info-query) element the payload definition, and behaviour
can be specified - by behaviour I mean type of query being undertaken,
eg. jabber:iq:browse states that the payload is a browse request to a
given jid ( to address ) to discover information about/from that
end-point.
The point of this all being, that there are some obvious parts to this
protocol that could lend itself to facilitating some passable (portion)
of a REST implementation ( or so it seems to me ).
It would help if people in general debated the merits of this ( at least
for me ), to help clear up whether or not there is some merit in using
some or all of what Jabber has to offer in a REST based architecture.
Cheers.
On Wed, Nov 27, 2002 at 12:07:08PM -0500, Mark Baker wrote:
> On Wed, Nov 27, 2002 at 02:37:48PM +0000, Piers Harding wrote:
> > Hi Yannick - I'd certainly like to get the lists opinion on this too. I
> > have ( as have others in the Jabber community ) wondered about Jabbers'
> > place in the REST world.
> >
> > Jabber appears to have some of the key components for REST with URIs and
> > a few of the RESTian verbs.
>
> I haven't looked at the Jabber protocol in any detail in quite some
> time, but REST is an architectural style that is extremely constraining.
> A system doesn't "conform" to REST's constraints by accident, it has to
> be intentionally designed to do so.
>
> Jabber, like pretty much every other system out there, can be engulfed
> by the Web, in the same way that FTP and email/SMTP were absorbed; by
> constraining interactions with that system to uniform interface
> semantics, and mapping the space of identifiable things in that system
> into URI space (often requiring a new URI scheme).
>
> > Is it actually necessary for a toolset to implement all features of
> > REST, or would the REST community be willing to endorse toolsets to a
> > level of REST support?
>
> I'm not sure what that means ("level of REST support"). Do you have an
> example?
>
> MB
> --
> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
>
> Will distribute objects for food
Sorry - that certainly wasn't my meaning - by endorsing I guess it was more along the lines of "actively thinking/investigating/colaborating with the Jabber community, to determine what each has to offer the other, if the technology is found to be appropriate" - endorse just seemed a lot shorter ;-) . One of my favourite catch phrases is that Jabber isn't just IM - it has a whole lot more to offer a lot of varied groups/requirements - I believe that this is one of those areas (REST) that should be looked at to see if there is some kind of "fit". Cheers. On Wed, Nov 27, 2002 at 09:36:43AM -0800, S. Mike Dierken wrote: > > ----- Original Message ----- > From: "Piers Harding" <piers@...> > > > Is it actually necessary for a toolset to implement all features of > > REST, or would the REST community be willing to endorse toolsets to a > > level of REST support? > I think the current REST community is an education-oriented group & the > members aren't really 'endorsing' things. There are a lot of people that are > more than willing to look at designs, tools, and technology & make > suggestions for improvements based on aspects of REST, and often based on > HTTP implementation details. > > So it's more of a "We're here to help." rather than "You're not a member of > the club" type of thing. > Endorsement comes from the community using the tools and from the tools > following community developed specifications (like HTTP, SMTP, DNS, etc). > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ >
Piers Harding wrote: > Hi Yannick - I'd certainly like to get the lists opinion on this too. > I have ( as have others in the Jabber community ) wondered about > Jabbers' place in the REST world. I'm sure you've heard that the hard-line REST point of view is that IM functionality should be rolled into HTTP (or HTTP-NG or Waka) or built on top of HTTP (or ...). That sounds very intolerant even to me but there are important principles that we're trying to encourage. A major one is that there should be a single address space for objects so that any component can talk to any other component in a unified way. By the way, this means that I would only support Waka if I were convinced that it could completely replace HTTP or work beside it so seamlessly that it didn't fragment the network. I'm probably not going to convince you that most existing protocols can and should be collapsed into one address space and protocol and you aren't going to convince me that the price is acceptable for the advantages that the Jabber protocol (as opposed to the Jabber architecture and implementation). But there are certainly productives avenue of cooperation. Jabber is designed to go through firewalls bidirectionally and asynchronously. I could imagine a gateway that would allow me to access an asynch P2P REST-based service running on my laptop by contacting me through a HTTP->Jabber->HTTP proxy. Until we've got the pieces in place to do easy bidirectional, cross-firewall asynch in a designed-for-REST protocol, I'm certainly not going to say anything against Jabber. If people are building and installing bidirectional asynch services I think that's a good thing. Probably HTTP could help Jabber in similar ways. Obviously there are already some HTTP->Jabber bridges if only for tunnelling out through firewalls, but I'm not sure how sophisticated they are. Does anyone run a service that allows Jabber URIs to embed HTTP URIs so that a "get" on the URI? Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > Piers Harding wrote: > > > Hi Yannick - I'd certainly like to get the lists opinion on this too. > > I have ( as have others in the Jabber community ) wondered about > > Jabbers' place in the REST world. > > I'm sure you've heard that the hard-line REST point of view is that IM > functionality should be rolled into HTTP (or HTTP-NG or Waka) or built > on top of HTTP (or ...). The discussions on this forum have shown that it is doable and existing approaches by IM clients to work through firewalls can be applied to work with HTTP as well - I think we ended up with using the 'Upgrade' header or something. The KnowNow technology does something a lot like this, but not as clean as I can imagine. I even once wrote an AIM clone with just HTML and JavaScript (buddy lists, messages, chat, invites, etc.) The neat thing about it was that it was HTML & javascript - /anybody/ could modify & extend it, not just the propeller heads. KnowNow recently put some technology out as open source on sourceforge (mod_pubsub) & I'm thinking about re-writing the KnowBuddy app (unless I can get KN to opensource that too)
Toivo "Deutsch" Lainevool wrote: > To summarize, one of the big differences is that a resource has an > interface that is defined by the architecture itself, while a service > has a user definable interface. I agree that this is a difference between REST and a traditional distributed objects system but I think that a service oriented architecture tends to be special in that many objects are encapsulated into a single service. And you do discovery on the service, not the objects. Paul Prescod
On Wed, Nov 27, 2002 at 04:19:08PM -0800, Paul Prescod wrote: > I agree that this is a difference between REST and a traditional > distributed objects system but I think that a service oriented > architecture tends to be special in that many objects are encapsulated > into a single service. And you do discovery on the service, not the objects. Yep, I think that's the key difference. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
On Wed, Nov 27, 2002 at 08:31:23PM +0000, Piers Harding wrote: > The point of this all being, that there are some obvious parts to this > protocol that could lend itself to facilitating some passable (portion) > of a REST implementation ( or so it seems to me ). > > It would help if people in general debated the merits of this ( at least > for me ), to help clear up whether or not there is some merit in using > some or all of what Jabber has to offer in a REST based architecture. Oh ok, I wasn't aware that you were looking at it that way. My personal opinion is, no, I'm not aware of any part of Jabber that has anything to offer REST. That's not a shot at Jabber, just an observation; I think Jabber is quite cool, and we use it at work, and even integrated it into Idokorro's HTTP routing platform and product suite. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
> -----Original Message----- > From: Mark Baker, Wednesday, November 27, 2002 7:49 PM > > On Wed, Nov 27, 2002 at 04:19:08PM -0800, Paul Prescod wrote: > > I agree that this is a difference between REST and a traditional > > distributed objects system but I think that a service oriented > > architecture tends to be special in that many objects are encapsulated > > into a single service. And you do discovery on the service, not the > objects. > > Yep, I think that's the key difference. > Hmmmm.... I'm not really sure I see what you mean by this. In regular usage of a Java SOA toolkit you would take one object and create a WSDL doc from it. The WSDL doc is a single service. I would say that means one service represents one object. Toivo Lainevool
----- Original Message ----- From: "Toivo "Deutsch" Lainevool" <tlainevool@...> > I'm not really sure I see what you mean by this. In regular usage of a > Java SOA toolkit you would take one object and create a WSDL doc from > it. The WSDL doc is a single service. I would say that means one > service represents one object. Perhaps we should clarify whether we are talking 'object', 'class' or what. When you use the term 'object' when talking about Java, I think of it as an instance. So "...many objects are encapsulated into a single service. And you do discovery on the service, not the objects." probably uses the term 'object' to mean 'instance'. I hope this clarifies things. As a note, this discussion is interesting because I see REST as being an 'instance' heavy approach, whereas many OO languages have 'class' and 'instance' as primary concepts.
Paul Prescod wrote: > Until we've got the pieces in place to do easy bidirectional, > cross-firewall asynch in a designed-for-REST protocol, I'm certainly > not going to say anything against Jabber. i think one of the pieces might be a BEEP-based protocol, with a profile for GET, POST, PUT, DELETE, etc. i said this before on rest-discuss but the idea has stewed in my mind a little since so i'll offer it once again in its regurgitated form. one of the objections to BEEP is that it multiplexes TCP, which itself multiplexes IP. two of the attractions are that it has a TUNNEL profile which allows it to cross firewall boundaries in a controlled manner, and its very extensible; need a new method, e.g. an enchanced GET for advanced queries (like GetData in TAPache)? just define a new profile. of course it shouldn't be *too* easy to define a new method, as we know so well. :) however, even if a BEEP-based REST application protocol were ready to be deployed, the erosion of end-to-end connectivity on the contemporary Internet (thru NAT etc.) would thwart efforts to do completely asynchronous messages. that said, BEEP enables the server to become the client and vice versa very very easily so asynch would probably be doable during the same session. i don't know whether you could bootstrap a BEEP-based protocol off the HTTP Upgrade header. i also don't know whether it adheres to KISS, and whether its part of the protocol stack can be implemented by Mere Mortals. http://www.beepcore.org/
Toivo "Deutsch" Lainevool wrote: > Hmmmm.... > > I'm not really sure I see what you mean by this. In regular usage of a > Java SOA toolkit you would take one object and create a WSDL doc from > it. You take an object with static method and expose the static methods. You can't take a family of objects with instance methods and expose the instances. > The WSDL doc is a single service. I would say that means one > service represents one object. Now go the other way. I have a hundred instances being created an destroyed at runtime. Whta does the WSDL for that look like? http://www.blogstream.com/pauls/1032521623/index_html Paul Prescod
Hmmm. Not exactly the response I was hoping for, but not a complete wash out :-) Possibly the greatest virtue of the Jabber protocol is that it implements the truest form of "push technology" (that I know of) to date. One aspect of this is (and arguably its most powerful use) is presence management - just simply being able to subscribe to a service, and know when it is available (without polling) is a very valuable thing (for example - I could subscribe to several similar services, but know which ones are available right now, when I want to choosing one to use). The Jabber community is allready looking at the use of http for file related transfer "out of band", where by a URL is transmitted and the client chooses when and how to access the data. This lends itself very nicely to event notification for things like business workflow. Also, the resource part of a jid can be anything, so it is a prime target for embedding http style uri's if you so desired. So where does this leave us? Not much further along, but perhaps I can convince one or two people to have a closer look at Jabber, and I think we could concentrate on how to do the bridging between XMPP (the JSF name of the Jabber Protocol), and the HTTP requirements of REST? Cheers. On Wed, Nov 27, 2002 at 02:22:09PM -0800, Paul Prescod wrote: > Piers Harding wrote: > > > Hi Yannick - I'd certainly like to get the lists opinion on this too. > > I have ( as have others in the Jabber community ) wondered about > > Jabbers' place in the REST world. > > I'm sure you've heard that the hard-line REST point of view is that IM > functionality should be rolled into HTTP (or HTTP-NG or Waka) or built > on top of HTTP (or ...). That sounds very intolerant even to me but > there are important principles that we're trying to encourage. A major > one is that there should be a single address space for objects so that > any component can talk to any other component in a unified way. By the > way, this means that I would only support Waka if I were convinced that > it could completely replace HTTP or work beside it so seamlessly that it > didn't fragment the network. > > I'm probably not going to convince you that most existing protocols can > and should be collapsed into one address space and protocol and you > aren't going to convince me that the price is acceptable for the > advantages that the Jabber protocol (as opposed to the Jabber > architecture and implementation). > > But there are certainly productives avenue of cooperation. Jabber is > designed to go through firewalls bidirectionally and asynchronously. I > could imagine a gateway that would allow me to access an asynch P2P > REST-based service running on my laptop by contacting me through a > HTTP->Jabber->HTTP proxy. > > Until we've got the pieces in place to do easy bidirectional, > cross-firewall asynch in a designed-for-REST protocol, I'm certainly not > going to say anything against Jabber. If people are building and > installing bidirectional asynch services I think that's a good thing. > > Probably HTTP could help Jabber in similar ways. Obviously there are > already some HTTP->Jabber bridges if only for tunnelling out through > firewalls, but I'm not sure how sophisticated they are. Does anyone run > a service that allows Jabber URIs to embed HTTP URIs so that a "get" on > the URI? > > Paul Prescod
OK, I see what you mean now, and agree completely. There is no way in a typical SOA system to pass references to objects around, while REST is all about passing around individual instances of resources via URI. That is a big difference. Toivo Lainevool > > > The WSDL doc is a single service. I would say that means one > > service represents one object. > > Now go the other way. I have a hundred instances being created an > destroyed at runtime. Whta does the WSDL for that look like? > > http://www.blogstream.com/pauls/1032521623/index_html > > Paul Prescod
Toivo "Deutsch" Lainevool wrote: > OK, I see what you mean now, and agree completely. There is no way in > a typical SOA system to pass references to objects around, while REST > is all about passing around individual instances of resources via URI. > That is a big difference. I claim this is a big deal because where a service-oriented interface tends to combine a bunch of separate things into one interface, REST tends to push towards very componentized resources. This helps interoperability because it means that if you and I can agree on the syntax for a purchase order across two domains we don't ALSO have to agree on (for example) the API for querying purchase orders (which might be different because different people have different querying needs), or even fetching purchase orders (because it is hard coded to be GET). I predict that there will be a movement against monolithic interfaces in a few years, REST or not. It is very reminicent of the Windows 3.1 API, where the first function parameter is a handle for the thing you're supposed to work on. Only problem is...there is no way to pass a handle to data+methods which is the essence of OOP. Is anyone brave enough to stand up for monolithic services? ;) Even as a devil's advocate? Paul Prescod
Hi, I recently read an article by Timothy Appnel(http://www.oreillynet.com/pub/wlg/2360). Here he mentioned RSS as a web service and since RSS follows RESTian approach, I am wondering if RSS is really a web service or not. Please let me know if I am getting it right or not? Thanks, Deepak http://www.webjives.com
Deepak Sharma wrote: > Hi, > > I recently read an article by Timothy > Appnel(http://www.oreillynet.com/pub/wlg/2360). Here > he mentioned RSS as a web service and since RSS > follows RESTian approach, I am wondering if RSS is > really a web service or not. Please let me know if I > am getting it right or not? The term web service has no widely agreed definition. I think that Timothy's description is good: " * Any site with information and news lacking RSS support. Whether it is just assumed or simply overlooked, RSS is the most widely deployed Web service across the Internet. Granted, most RSS feeds have very simple interfaces with almost as simple backends that are unlike the Web services that usually come to mind. (Who says Web services need to be complex or sophisticated anyhow?) Under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Consider that any site search engine becomes a Web service if it could emit results in RSS and the format's potential in the realm of Web services becomes more apparent." He's right, RSS has not yet been fully exploited and it is likely to be the "killer app" for the integration of XML and REST until another XML vocabulary becomes big. Paul Prescod
----- Original Message ----- From: "Piers Harding" <piers@...> > > Possibly the greatest virtue of the Jabber protocol is that it > implements the truest form of "push technology" (that I know of) to > date. One aspect of this is (and arguably its most powerful use) is > presence management - just simply being able to subscribe to a service, > and know when it is available (without polling) is a very valuable thing > (for example - I could subscribe to several similar services, but know > which ones are available right now, when I want to choosing one to use). Whenever a piece of software receives an unsolicited message it's 'push'. Which means that Web servers that receive unsolicited POST messages are being 'pushed' the data. Put a Web server on every desktop & you've got a 'push based Web'. (This is where my phrase 'The Web works both ways' comes from) If you can't open a connection to the desktop - and Jabber I'm assuming doesn't do this either - then have the desktop open a connection to the server (or Jabber server, or HTTP proxy, or whatever) and then wait for incoming messaging. The use of HTTP after the socket is opened provides for clear, simplified and rich application semantics that work with many many tools. I'm spending some time thinking about the details of a client add-on & server add-on to do this extra socket connection handoff stuff. I call it Appster & my first experiment will be to do similar things as the Gnutella protocol does, but with pure HTTP for discovery and queries. > > So where does this leave us? Not much further along, but perhaps I can > convince one or two people to have a closer look at Jabber, and I think > we could concentrate on how to do the bridging between XMPP (the JSF > name of the Jabber Protocol), and the HTTP requirements of REST? Okay, somebody should look into that. But I'm going to look at providing HTTP/URI/XML access everywhere & then move on to Web native pub/sub. Mike
S. Mike Dierken wrote: > Whenever a piece of software receives an unsolicited message it's > 'push'. Which means that Web servers that receive unsolicited POST > messages are being 'pushed' the data. > Put a Web server on every desktop & you've got a 'push based Web'. > (This is where my phrase 'The Web works both ways' comes from) Yes, but don't forget the other half. With Jabber and most other P2P systems, I can "log on" as me anywhere in the world and messages are forwarded to me. That's because there is an always-on intermediary that stands in for me. The lack of these intermediaries is a big problem for HTTP-based P2P and is the second major reason (beyond firewalls) that HTTP is not seen as much of a P2P solution. > If you can't open a connection to the desktop - and Jabber > I'm assuming doesn't do this either - then have the desktop open a > connection to the server (or Jabber server, or HTTP proxy, or > whatever) and then wait for > incoming messaging. Well it probably doesn't make that much sense to connect to a true "data server" and wait for it to send you messages. I'm not going to open a connection to Google and Slashdot and a dozen Weblogs and just sit there. More likely I have a single trusted intermediary with a single socket open for me. It either polls those other sites or accepts notifications for me. It needs to do the message redirecting for me and it might as well have store and forward and presence capabilities at the same time. Getting the trusted intermediaries out there and available involves a little bit of a bootstrapping problem. Paul Prescod
Recalling Fielding's dissertation, he specifically says that REST is based on the client-server model. He also makes a quick point that you could acheive P2P by having both a client and a server on both ends. However, I have seen several discussions here in which people are talking about the server pushing to the client. It even seems that Fielding's own Waka contains features like this. Wouldn't such an approach be non-RESTful? --- Seairth Jacobs seairth@... p.s. Happy Thanksgiving for those who celebrate it (and a happy Thursday for those who don't).
> Recalling Fielding's dissertation, he specifically says that REST is based > on the client-server model. He also makes a quick point that you could > acheive P2P by having both a client and a server on both ends. However, I > have seen several discussions here in which people are talking about the > server pushing to the client. It even seems that Fielding's own Waka > contains features like this. Is there a difference between "having both a client and a server on both ends", and "the server pushing to the client"? Does the server pushing to the client constitute messages following a request which are not direct responses to that request? Michael
----- Original Message ----- From: "Paul Prescod" <paul@...> > Yes, but don't forget the other half. With Jabber and most other P2P > systems, I can "log on" as me anywhere in the world and messages are > forwarded to me. That's because there is an always-on intermediary that > stands in for me. The lack of these intermediaries is a big problem for > HTTP-based P2P and is the second major reason (beyond firewalls) that > HTTP is not seen as much of a P2P solution. Then we will build them. > > Well it probably doesn't make that much sense to connect to a true "data > server" and wait for it to send you messages. I'm not going to open a > connection to Google and Slashdot and a dozen Weblogs and just sit > there. Never said it would. > More likely I have a single trusted intermediary with a single > socket open for me. Eventually, you could choose from many, and with dynamic DNS have your URI's mapped back to whatever IP and device you are using. But initially, a single one is fine. Like the way Hotmail is a single trusted intermediary. > It either polls those other sites or accepts notifications for me. It won't poll those other sites or accept notifications. It accepts requests, and the client provides responses. Just like every other part of the Web. If the request is a POST that is a notification, sure. > > It needs to do the message redirecting for me and it might as well have > store and forward and presence capabilities at the same time. You are correct sir. > > Getting the trusted intermediaries out there and available involves a > little bit of a bootstrapping problem. Yep.
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > I have seen several discussions here in which people are talking about the > server pushing to the client. It depends on what is being pushed. If it is a request, then the pusher is a 'client'. If it is a response, then you are doing request/response outside a single TCP/IP connection - which is fine but I haven't seen anybody do it yet (you'll need correlation ids in messages, etc). Push is a really bad term. Trust me.
From: "Paul Prescod" <paul@...> > The lack of these intermediaries is a big problem for > HTTP-based P2P and is the second major reason (beyond firewalls) that > HTTP is not seen as much of a P2P solution. > A simple solution could just be a directory server (ldap) in wich the mapping user/ip is done, juste like isp servers for NetMeeting (which are actually ldap), or DynDNS-like services.
> -----Original Message----- > From: Paul Prescod, Sent: Thursday, November 28, 2002 12:00 PM > > Toivo "Deutsch" Lainevool wrote: > > > OK, I see what you mean now, and agree completely. There is no way in > > a typical SOA system to pass references to objects around, while REST > > is all about passing around individual instances of resources via URI. > > That is a big difference. > > I claim this is a big deal because where a service-oriented interface > tends to combine a bunch of separate things into one interface, REST > tends to push towards very componentized resources. > > Is anyone brave enough to stand up for monolithic services? ;) Even as a > devil's advocate? > > Paul Prescod I wouldn't stand up for monolithic services, but I will try to defend the SOA approach a little. (Keep in mind that I'm not arguing that one of the approaches is "better", I think both have their appropriate uses. To me there is no clear winner. When deciding which is better to use in a particular system you have a lot of context to keep in mind. I'm just trying to get a better handle on some criteria to help me make this decision.) One of the hardest things to do when designing networked systems is choosing the right abstractions (e.g. resources or services) at the right level of granularity. Systems that have abstractions that are too coarse grained end up pushing around a lot of unneeded data across the wire. If the granularity is too fine, too many messages go back and forth across the network. I don't think service interfaces need to be "monolithic". This just seems like an issue of picking the right abstractions and granularity. To me it seems like picking the right abstractions and granularity would be more difficult with REST that with services. This is because resources are restricted to the HTTP verbs for interacting with the outside world, where with the service interface you are free to make up any verbs you want. So if you had a bank account that you were modeling, with a service interface you could do something like: Service: Account Has operation: deposit( account_number, amount ) Has operation: withdrawal( account_number, amount ) Has operation: calculateInterest( account_number ) I wouldn't call this "combining a bunch of separate things". I would say this is grouping a set of related operation together in a cohesive unit. How would model these same behaviors in a REST system? Can you have one cohesive unit that model all these behaviors in a way that would be obvious to a user? It's probably because I've been using OO for a long time now, and haven't had nearly as much experience with REST, but it seems easier and more natural to do this the service oriented way. Toivo Lainevool (ducking in anticipation of the flames)
----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>
>
> Service: Account
> Has operation: deposit( account_number, amount )
> Has operation: withdrawal( account_number, amount )
> Has operation: calculateInterest( account_number )
> How would model these same behaviors in a REST system?
Here's one approach using verbs from HTTP:
server.post("accounts/account_number/credits",amount);
server.post("accounts/account_number/debits",amount);
server.get("accounts/account_number/interest");
S. Mike Dierken wrote:
> Here's one approach using verbs from HTTP:
>
> server.post("accounts/account_number/credits",amount);
> server.post("accounts/account_number/debits",amount);
> server.get("accounts/account_number/interest");
yep, but (nit-picking) your POST URLs could just as easily be:
accounts/account_number/deposits
accounts/account_number/withdrawals
or whatever you want for that matter.
for the POSTs, i also use a /credits/transaction_id (or equivalent) URL
which gets returned in a "201 Created" response.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2
i call these resources 'sub-resources' because they're only relevant in
the context of one particular account. they're also containers because
they are basically the subset of all credits/debits/whatever associated
with a particular account. this makes the semantics for POSTing to them
crystal clear IMHO. compare/contrast with POSTing to
account/account_number and trying to distinguish whether it is a credit
or a debit that is being POSTed. it seems to me that this is the part
of resource modelling that corresponds to one-to-many relationships in
ER/database modelling.
Can anyone think of a reason (and possibly example) why you would use PUT and POST on the same URI? Does such a thing even make sense? --- Seairth Jacobs seairth@...
Toivo "Deutsch" Lainevool wrote: > I wouldn't stand up for monolithic services, but I will try to defend > the SOA approach a little. (Keep in mind that I'm not arguing that one > of the approaches is "better", I think both have their appropriate uses. > To me there is no clear winner. When deciding which is better to use in > a particular system you have a lot of context to keep in mind. I'm just > trying to get a better handle on some criteria to help me make this > decision.) I think I could be convinced that a "generic objects" model has some advantages over a REST model in some circumstances but I really cannot see _any_ virtue in the service oriented model over the generic objects model. It seems to me to be just a "dumbed down" version of OOP (where objects have a uniform addressing scheme and can be created and destroyed at runtime). Perhaps that dumbing down has useful sociological effects. Clearly SOAP and XML-RPC seem not to have suffered in popularity for leaving out the concept of "dynamic objects" but it seems a serious omission to me. > One of the hardest things to do when designing networked systems is > choosing the right abstractions (e.g. resources or services) at the > right level of granularity. Systems that have abstractions that are > too coarse grained end up pushing around a lot of unneeded data across > the wire. If the granularity is too fine, too many messages go back > and forth across the network. I'm not convinced that there is a correspondance between granularity of addressing and granularity of messaging. One message could influence thousands of addressable objects or thousands of messages could have only a small effect on a single object. > I don't think service interfaces need to be "monolithic". This just > seems like an issue of picking the right abstractions and granularity. > To me it seems like picking the right abstractions and granularity > would be more difficult with REST that with services. This is because > resources are restricted to the HTTP verbs for interacting with the > outside world, where with the service interface you are free to make > up any verbs you want. So if you had a bank account that you were > modeling, with a service interface you could do something like: Despite what I said above, I can see how REST makes it harder to have precise control over the granularity of messaging. You can't reasonably have a method called "UpdateNThings" in REST, though you could emulate it by POSTing an "UpdateNThingsRequest" resource. I would actually rather compare SOA to "traditional, arbitrary methods OOP" because the delta between that and SOA is smaller. > Service: Account > Has operation: deposit( account_number, amount ) > Has operation: withdrawal( account_number, amount ) > Has operation: calculateInterest( account_number ) > > I wouldn't call this "combining a bunch of separate things". I would > say this is grouping a set of related operation together in a cohesive > unit. You call the service Account but it is really AccountManager in that it does not represent any particular account. That is nothing like OOP. In OOP it would be: Service: AccountManager Has operation: listAccounts() -> Account Has operation: findAccount(account_number) -> Account Has operation: findAccount(branch, customer_id) -> Account Has operation: findAccounts(customer_name) -> Account[] Has operation: createAccount(account_number, AccountData) -> Account Has operation: destroyAccount(account_number) Service: Account Has operation: deposit(amount) Has operation: withdraw(amount) Has operation: calculateInterest() This is a proper separation of concerns. Now we do not even have to agree upon an account query model to share accounts. Similarly in a Java program, you don't have to know how I created an InputStream to use it as an InputStream. One library doesn't need to know the full details of another library's interface to share objects. It only needs to know the interfaces _of the objects_. The mapping to REST is basically: listAccounts -> GET /accounts findAccount(s) -> GET /accounts?customer_name=... createAccount -> POST /accounts returns /accounts/some_account destroyAccount -> DELETE /accounts/some_account deposit -> POST /accounts/credits (as per Dierkin) withdraw -> POST (arguably those could be the same method) calculateInterest -> (should this be a client service or embedded in the server business logic???) > It's probably because I've been using OO for a long time now, and > haven't had nearly as much experience with REST, but it seems easier > and more natural to do this the service oriented way. If you're used to OO then I would expect the service oriented way to feel odd to you. A 1970s Lisp or COBOL would totally understand the service oriented interface as a functional interface. The key to OO is integrating the data and the methods into separably addressable objects with polymorphism. REST has that and more traditional web services techniques do not. Paul Prescod
Seairth Jacobs wrote: > Can anyone think of a reason (and possibly example) why you would use PUT > and POST on the same URI? Does such a thing even make sense? i haven't found a situation where it has made sense so far. it's a phenomenon i have observed in practice; i've been meaning to ask rest-discuss but hadn't got around to it. i think this is because most of the time when you would want to POST to a resource that you can already PUT to (e.g. /accounts/[id]), you are probably better off POSTing to a 'sub-resource' which is a collection instead (e.g. /accounts/[id]/withdrawals). (cf. my post from yesterday.) i have used this fact to implement a browser workaround or hack. Because browsers can't send PUT, e.g. as the method of a form submit, I 'pre-process' the request at the server so that the POST is changed to a PUT. i then continue with processing as normal. this means I can use the same code for browsers and machine clients (modulo differences between representations, but i'm working on seperating that concern cleanly as well, and joe gregorio has already done a nice job with RESTlog). it also means that i can support PUT operations using HTML forms, which is important for my app. when i saw REST first i wondered, "but how the hell can REST work when browsers don't send PUT"? (using client-side XMLHttpRequest-ish objects doesn't count, IMO.) but it seems to be mostly a non-issue because you can effectively overload the semantics of POST to include PUT for broken user agents, depending on the URI in question.
Seairth Jacobs wrote: > Can anyone think of a reason (and possibly example) why you would use PUT > and POST on the same URI? Does such a thing even make sense? Let's say a URI represents a log for a chat session. PUT would overwrite the log and start again. POST would add some text to the bottom. Paul Prescod
> From: Seairth Jacobs [mailto:seairth@...] > Sent: Sunday, December 01, 2002 2:50 AM > To: rest-discuss > Subject: [rest-discuss] POST/PUT to the same URI? > > > Can anyone think of a reason (and possibly example) why you would use PUT > and POST on the same URI? Does such a thing even make sense? I can image an authorable server that lets you create POST-accepting-resources using PUT (for instance, followed by a PROPPATCH setting some server-internal live properties that make the already existing "plain" resource an acceptor for POSTs). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message----- > From: Paul Prescod, Sent: Saturday, November 30, 2002 5:57 PM > > I think I could be convinced that a "generic objects" model has some > advantages over a REST model in some circumstances but I really cannot > see _any_ virtue in the service oriented model over the generic objects > model. It seems to me to be just a "dumbed down" version of OOP (where > objects have a uniform addressing scheme and can be created and > destroyed at runtime). Perhaps that dumbing down has useful sociological > effects. Clearly SOAP and XML-RPC seem not to have suffered in > popularity for leaving out the concept of "dynamic objects" but it seems > a serious omission to me. I think one advantage the "generic object" approach has over REST is that it can still be modeled with standard OO notation, and it can easily be mapped to OO programming languages via toolkits. Ease of use is an important architectural aspect to consider. There is dissonance that developers feel when switching between OO and REST. In other words switching between OO and REST is a major paradigm shift. Switching between "dynamic objects" and "generic objects" is not that big a deal. > > > I'm not convinced that there is a correspondance between granularity of > addressing and granularity of messaging. One message could influence > thousands of addressable objects or thousands of messages could have > only a small effect on a single object. > > Despite what I said above, I can see how REST makes it harder to have > precise control over the granularity of messaging. You can't reasonably > have a method called "UpdateNThings" in REST, though you could emulate > it by POSTing an "UpdateNThingsRequest" resource. I would actually > rather compare SOA to "traditional, arbitrary methods OOP" because the > delta between that and SOA is smaller. Makes sense. > > > You call the service Account but it is really AccountManager in that it > does not represent any particular account. That is nothing like OOP. In > OOP it would be: > > Service: AccountManager > Has operation: listAccounts() -> Account > Has operation: findAccount(account_number) -> Account > Has operation: findAccount(branch, customer_id) -> Account > Has operation: findAccounts(customer_name) -> Account[] > Has operation: createAccount(account_number, AccountData) -> Account > Has operation: destroyAccount(account_number) > > Service: Account > Has operation: deposit(amount) > Has operation: withdraw(amount) > Has operation: calculateInterest() > > This is a proper separation of concerns. Now we do not even have to > agree upon an account query model to share accounts. Similarly in a Java > program, you don't have to know how I created an InputStream to use it > as an InputStream. One library doesn't need to know the full details of > another library's interface to share objects. It only needs to know the > interfaces _of the objects_. In a service oriented system this can be modeled as: Service: Accounts Has operation: listAccounts() -> Account Has operation: findAccount(account_number) -> Account Has operation: findAccount(branch, customer_id) -> Account Has operation: findAccounts(customer_name) -> Account[] Has operation: createAccount(account_number, AccountData) -> Account Has operation: destroyAccount(account_number) Service: IndividualAccount Has operation: deposit(account_number, amount) Has operation: withdraw(account_number, amount) Has operation: calculateInterest(account_number) This still has all the goodness of separation of concerns and fully defined query model. Sure it's not full blown "dynamic objects", but it looks familiar to anyone who knows OO. > > The mapping to REST is basically: > > listAccounts -> GET /accounts > findAccount(s) -> GET /accounts?customer_name=... > createAccount -> POST /accounts returns /accounts/some_account > destroyAccount -> DELETE /accounts/some_account > deposit -> POST /accounts/credits (as per Dierkin) > withdraw -> POST (arguably those could be the same method) > calculateInterest -> (should this be a client service or embedded in > the server business logic???) > This model seems to introduce some incidental complexity (see http://www.computer.org/proceedings/icre/0565/05650130abs.htm). Instead of just representing an account as a single abstraction, we now have an account resource, an account-credit abstraction and an account-debit abstraction. This is getting interesting. Its making me think that if there were a good Object->REST mapping language we could have the best of both worlds: a fully "dynamic object" model (that allows OO notation and easy mapping to OOPLs) with a REST based messaging taking caring of the networking aspects. I might noodle on this for a bit and see if I can come up with something. Toivo Lainevool
----- Original Message ----- From: "Toivo "Deutsch" Lainevool" <tlainevool@...> > > This model seems to introduce some incidental complexity (see > http://www.computer.org/proceedings/icre/0565/05650130abs.htm). Instead > of just representing an account as a single abstraction, we now have an > account resource, an account-credit abstraction and an account-debit > abstraction. Would you consider that the account-credit abstraction is just transfering complexity of the 'deposit()' concept to a different place in the design? So it's not so much an addition as a transfer?
> -----Original Message----- > From: S. Mike Dierken > > > > > This model seems to introduce some incidental complexity (see > > http://www.computer.org/proceedings/icre/0565/05650130abs.htm). Instead > > of just representing an account as a single abstraction, we now have an > > account resource, an account-credit abstraction and an account-debit > > abstraction. > Would you consider that the account-credit abstraction is just transfering > complexity of the 'deposit()' concept to a different place in the design? > So it's not so much an addition as a transfer? I think it does add complexity, though. With a new resource you have a new URI to keep track of, and you have to know which methods are valid for it (what happens if I "get" from this resource?), the parameters it accepts, what each of the methods returns, etc. That's not a whole lot of extra over a method name, parameter list and return type; but in a large system those little things add up. Toivo Lainevool
"Toivo \"Deutsch\" Lainevool" wrote: > > > -----Original Message----- > > From: S. Mike Dierken > > > > > > > This model seems to introduce some incidental complexity (see > > > http://www.computer.org/proceedings/icre/0565/05650130abs.htm). > Instead > > > of just representing an account as a single abstraction, we now have > an > > > account resource, an account-credit abstraction and an account- debit > > > abstraction. > > Would you consider that the account-credit abstraction is just > transfering > > complexity of the 'deposit()' concept to a different place in the > design? > > So it's not so much an addition as a transfer? > > I think it does add complexity, though. With a new resource you have a > new URI to keep track of, and you have to know which methods are valid > for it (what happens if I "get" from this resource?), the parameters it > accepts, what each of the methods returns, etc. I intend to revert to the human-understandable version here, that is, deposits and withdrawals. (Debit and credit require me to buy into accounting jargon.) I want each of my deposits and withdrawals to have its own identity. If I am working with my account (like balancing my checkbook), I want to be able to work with each item individually. I think it is the same with any other composite object model: each of the sub-objects in the composite has its own identity. For example, in orders, I want to be able to work with each line item independently sometimes. Likewise each delivery and payment. Whether modeled as resources or objects or database tables, each element will have its own identity as well as being represented in representations of "the whole", e.g. the state of the account or order. I can't think of any business object models I've worked with, where the sub-objects were not also first-class objects with their own identity. And with objects, using the Composite pattern, every object in the composite has the same set of methods. In other words, I don't see such a great divide between objects and REST resources. I see a much bigger divide between REST and RPC- style SOAP, which reminds me more of C. -Bob Haugen
Hi all, I have recently discovered REST for myself and I glad I did. For quite sometime I thought that WebServices should be more URI based, so I was glad to find that there is the whole theory behind that :). While I am trying to catch up with the REST literature I have a question of a more practicle nature. I am wondering if there is an outgoing Open Source effort(s) which have a goal to build a web services infrustucture around REST principles. Thanks Alexi.
Toivo "Deutsch" Lainevool wrote: > In a service oriented system this can be modeled as: > > Service: Accounts > Has operation: listAccounts() -> Account > Has operation: findAccount(account_number) -> Account > Has operation: findAccount(branch, customer_id) -> Account > Has operation: findAccounts(customer_name) -> Account[] > Has operation: createAccount(account_number, AccountData) -> > Account > Has operation: destroyAccount(account_number) > > Service: IndividualAccount > Has operation: deposit(account_number, amount) > Has operation: withdraw(account_number, amount) > Has operation: calculateInterest(account_number) Yes but WHY???? Why introduce an extra layer of "pass the object identifer as the first parameter"? Do you realize that this means that rahter than passing around opaque pointers to account objects (URIs in the Web, 32-bit numbers in C++) I now have to pass around a URI to the IndividualAccount service AND an account number. Logic would dictate that your life would be simpler if you put them together into an opaque tuple: (http://machine/Account, 234324) Logically that would be encoded as: http://machine/Account/234324 Somebody please tell me what the advantage of the service-oriented version is! I don't understand why our industry would move in that direction after ten years of OOP. > This model seems to introduce some incidental complexity (see > http://www.computer.org/proceedings/icre/0565/05650130abs.htm). Instead > of just representing an account as a single abstraction, we now have an > account resource, an account-credit abstraction and an account-debit > abstraction. Arguably you could combine them. A domain expert would probably have to say. But anyhow, in a real banking app, every credit or debit is a unique, persistent object that can be referenced. It should be possible to list all credits for a particular day, etc. > This is getting interesting. Its making me think that if there were a > good Object->REST mapping language we could have the best of both > worlds: a fully "dynamic object" model (that allows OO notation and easy > mapping to OOPLs) with a REST based messaging taking caring of the > networking aspects. I might noodle on this for a bit and see if I can > come up with something. I started something like that with WRDL but I hold out hope that WSDL can be reformed to work. Paul Prescod
alexi wrote: > Hi all, > > I have recently discovered REST for myself and I glad > I did. For quite sometime I thought that WebServices > should be more URI based, so I was glad to find that > there is the whole theory behind that :). While I am > trying to catch up with the REST literature I have a > question of a more practicle nature. I am wondering > if there is an outgoing Open Source effort(s) which > have a goal to build a web services infrustucture > around REST principles. REST web services are the natural intersection of HTTP and perhaps its successor protocol and various data encoding strategies like RSS, the semantic web, SVG and XML in general. Any toolkit that combines the most appropriate data encoding for your problem domain with HTTP functionality is an open source REST tool. Examples include Zope, Quixote, Redfoot, Mason and the various J2EE tools. I'm not saying that there is no room for new toolkits but my personal opinion is that if you combine a perfect toolkit for your data format (e.g. an RSS parser or RDF engine) with the perfect HTTP platform for your language, you get a REST toolkit out of the combination "for free." And further, it is somewhat dangerous (not entirely wrong, but somewhat dangerous) to try to tie the encoding and architecture/protocol more closely. http://www.prescod.net/rest/encoding Perhaps an XML+HTTP+URIs package would be a good idea regardless. But it wouldn't be a REST toolkit unless it also supported totally unstructured data. Paul Prescod
On Sun, Dec 01, 2002 at 08:12:07AM -0800, Toivo Deutsch Lainevool wrote: > I think one advantage the "generic object" approach has over REST is > that it can still be modeled with standard OO notation, and it can > easily be mapped to OO programming languages via toolkits. Ease of use > is an important architectural aspect to consider. There is dissonance > that developers feel when switching between OO and REST. In other words > switching between OO and REST is a major paradigm shift. Switching > between "dynamic objects" and "generic objects" is not that big a deal. My experience is exactly the opposite. I was never comfortable with the CORBA style SOA based architecture. Whenever I did any substantial work in it, I always found so many integration problems due to the different assumptions about each object's internal exposed through its interface; failure model, concurrency, etc.. When I realized what the Web was, and that "all" I was doing was ensuring that each object had the same interface, I immediately "got it" because I realized just how easy it was going to make my job as developer of distributed objects. IMO, REST is more "OO" (whatever exactly that means - things with behaviour, state, identity, I say) than SOAs. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Will distribute objects for food
Paul Prescod wrote: > Toivo "Deutsch" Lainevool wrote: >>In a service oriented system this can be modeled as: >> >>Service: Accounts >> Has operation: listAccounts() -> Account >> Has operation: findAccount(account_number) -> Account >> Has operation: findAccount(branch, customer_id) -> Account >> Has operation: findAccounts(customer_name) -> Account[] >> Has operation: createAccount(account_number, AccountData) -> >>Account >> Has operation: destroyAccount(account_number) >> >>Service: IndividualAccount >> Has operation: deposit(account_number, amount) >> Has operation: withdraw(account_number, amount) >> Has operation: calculateInterest(account_number) > > [...] > Somebody please tell me what the advantage of the service-oriented > version is! I don't understand why our industry would move in that > direction after ten years of OOP. I don't understand the terminology in this thread at all. To me, OOP is about managing dependencies in sofware by using jumptables. I don't see how the service oriented example above is not OOP. Whether it's a well conceived solution to a particular problem is another matter. Bill de h�ra
> Is anyone brave enough to stand up for monolithic services? > ;) Even as a > devil's advocate? > > Paul Prescod Not sure what you mean by 'monolithic' in this setting. I usually think of it as meaning indivisible. Is there such a thing as a monolithic interface? I'm afraid I'm not visualizing this very well. Walden
> -----Original Message----- > From: S. Mike Dierken [mailto:mdierken@...] > Sent: Friday, November 29, 2002 3:19 AM > To: rest-discuss > Subject: Re: [rest-discuss] Server push and REST > > > > ----- Original Message ----- > From: "Seairth Jacobs" <seairth@...> > > > > I have seen several discussions here in which people are > talking about the > > server pushing to the client. > It depends on what is being pushed. If it is a request, then > the pusher is a > 'client'. If it is a response, then you are doing > request/response outside a > single TCP/IP connection - which is fine but I haven't seen > anybody do it > yet (you'll need correlation ids in messages, etc). > > Push is a really bad term. Trust me. I do. Implicit Request and Persistent Request are better terms. Implicit request means that as long as you're there and I'm here and you have class X of data, I want it. Persistent Request means I want each and every piece of it, without having to ask for each and every piece. Of course, you can elaborate on those themes. Most of my career I've worked on "push" based market data systems. It's an optimization of the more familiar client-server model in which requests are explicit. Walden > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> > Get 128 Bit SSL Encryption! > http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM > -------------------------------------------------------------- > -------~-> > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Paul Prescod wrote: > Seairth Jacobs wrote: > > > Can anyone think of a reason (and possibly > > example) why you would use PUT and POST on the > > same URI? Does such a thing even make sense? > > Let's say a URI represents a log for a chat session. > PUT would overwrite the log and start again. POST > would add some text to the bottom. Here is another example: one user POSTs a representation of an empty container resource named 'b' to the container resource at /a, then POSTs representations of new resources named 'c' and 'd' to /a/b. 1. POST to /a representation of b 2. POST to /a/b representation of c 3. POST to /a/b representation of d Another user might take care of the whole thing in one PUT request by sending a representation of a container resource named b, with its subordinates c and d already POSTed to it, into the container resource at /a. 1. POST to b representation of c 2. POST to b representation of d 3. PUT to /a/b representation of b This shows that POST and PUT can happen to the same URI. The first user POSTed representations of c and d to /a/b. Yet in the second case b was PUT to /a/b with c and d already POSTed to it. In both cases new resources will exist at /a/b, /a/b/c and /a/b/d. Philip __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
> This shows that POST and PUT can happen to the same > URI. The first user POSTed representations of c and d > to /a/b. Yet in the second case b was PUT to /a/b > with c and d already POSTed to it. In both cases new > resources will exist at /a/b, /a/b/c and /a/b/d. > > Philip > There's something a little strange going on here. How can the 'b' of the PUT (a representation) have had things POSTed to it? POST is defined as a resource method, not a way to compose representations. Do I miss the boat? Walden
On 11/30/2002 at 3:41 PM alexi wrote: >Hi all, > >I have recently discovered REST for myself and I glad >I did. For quite sometime I thought that WebServices >should be more URI based, so I was glad to find that >there is the whole theory behind that :). While I am >trying to catch up with the REST literature I have a >question of a more practicle nature. I am wondering >if there is an outgoing Open Source effort(s) which >have a goal to build a web services infrustucture >around REST principles. Not as such, at least as far as I am aware, but there are webapp infrastructures that are better or worse suited for REST development. For example, Apache Jakarta Struts, while being a very popular and robust MVC infrastructure, is completely ill-suited for REST since the URL and actual contents of a resource may have no relation to one another (struts overuses the servlet RequestDispatcher API). Apache Cocoon, for another example, is reasonably useful for REST - it uses a sitemap to map urls to pipelines of processing components. On the other hand, it's aimed more at web sites than webapps, thus may not be suitable as a "web services" infrastructure. What other webapp infrastructures have people used for REST projects that turned out well or poorly? - donald
> > What other webapp infrastructures have people used for REST projects that > turned out well or poorly? In particular, Zope? Sam Hunting eTopicality, Inc. --------------------------------------------------------------------------- "Turn your searching experience into a finding experience."(tm) Topic map consulting and training: www.etopicality.com Free open source topic map tools: www.gooseworks.org XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley, ISBN 0-201-74960-2. ---------------------------------------------------------------------------
Walden Mathews wrote: > > This shows that POST and PUT can happen to the > > same URI. The first user POSTed representations > > of c and d to /a/b. Yet in the second case b was > > PUT to /a/b with c and d already POSTed to it. > > In both cases new resources will exist at > > /a/b, /a/b/c and /a/b/d. > > There's something a little strange going on here. > How can the 'b' of the PUT (a representation) have > had things POSTed to it? POST is defined as a > resource method, not a way to compose > representations. Do I miss the boat? Thanks for the question. For the second example you're asking about, I assumed the requestor created a resource with subordinates c and d, then a representation of the whole thing was transferred to /a/b via PUT. But there's nothing stopping you from only constructing representations of b containing representations of c and d on the fly and transferring that instead. The difference between the two approaches is that you can either transfer representations taken from existing resources, or construct and transfer your own representations (e.g., telnet to the node and literally type out the PUT request and its XML) without relying on an existing (non-vacuous) resource. I've coded my toolkit project under this philosophy. Please let me know if there is a flaw in my thinking. Thanks, Philip __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Bill de h�ra wrote:
> I don't understand the terminology in this thread at all. To me, OOP
> is about managing dependencies in sofware by using jumptables.
> I don't see how the service oriented example above is not OOP.
To me, OOP is about objects, and objects are things with identity, state
and behaviour. If we put aside static type checking for a second, any
object in an OOPL may refer to any other object in a consistent way
(void *x, Object x, etc).
When you use the "handle as first parameter hack", you now have to have
two addresses for each object. The address of the service (usually an
HTTP URI) and the "handle" which is really just another address. In my
opinion, this is not proper OOP programming. It would be very rare to
see a Java interface like:
class IndividualAccount{
function debit(accountNumber, val);
function credit(accountNumber, val);
}
Because this makes it _impossible_ to pass a reference to an account as
a standard Java object reference. Instead, you would much more often do:
class AccountManager{
function getAccount(number);
}
class Account{
function debit(val);
function credit(val);
}
Now the account is a first-class object which can be passed around
without reference to the query interface. i.e. it has identity, state
and behaviour. As an example of how its identity might be important, you
might have different access controls on different accounts. This could
be done in a language or system with per-object access controls. Even in
such a system, it is not straightforward if you've hacked static methods
to _emulate_ instance objects in a manner that is opaque to your
infrastructure.
Paul Prescod
Terminology strikes again. Object models and object oriented
programming have separate lives, according to what I read. Bill
is talking about polymorphic method resolution, which is one
feature of OO (the programming thing), while Paul's description
of "identity, state and behavior" is the /sine qua non/ of the
object model.
That's my take...
Walden
> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Monday, December 02, 2002 2:28 PM
> To: Bill de hra
> Cc: Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Another REST vs. SOAP article
>
>
> Bill de hra wrote:
>
> > I don't understand the terminology in this thread at all. To me, OOP
> > is about managing dependencies in sofware by using jumptables.
>
> > I don't see how the service oriented example above is not OOP.
>
> To me, OOP is about objects, and objects are things with
> identity, state
> and behaviour. If we put aside static type checking for a second, any
> object in an OOPL may refer to any other object in a consistent way
> (void *x, Object x, etc).
>
> When you use the "handle as first parameter hack", you now
> have to have
> two addresses for each object. The address of the service (usually an
> HTTP URI) and the "handle" which is really just another
> address. In my
> opinion, this is not proper OOP programming. It would be very rare to
> see a Java interface like:
>
> class IndividualAccount{
> function debit(accountNumber, val);
> function credit(accountNumber, val);
> }
>
> Because this makes it _impossible_ to pass a reference to an
> account as
> a standard Java object reference. Instead, you would much
> more often do:
>
> class AccountManager{
> function getAccount(number);
> }
>
> class Account{
> function debit(val);
> function credit(val);
> }
>
> Now the account is a first-class object which can be passed around
> without reference to the query interface. i.e. it has identity, state
> and behaviour. As an example of how its identity might be
> important, you
> might have different access controls on different accounts.
> This could
> be done in a language or system with per-object access
> controls. Even in
> such a system, it is not straightforward if you've hacked
> static methods
> to _emulate_ instance objects in a manner that is opaque to your
> infrastructure.
>
> Paul Prescod
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
Mathews, Walden wrote: > >Is anyone brave enough to stand up for monolithic services? > >;) Even as a > >devil's advocate? > > > > Paul Prescod > > > Not sure what you mean by 'monolithic' in this setting. I usually > think of it as meaning indivisible. Is there such a thing as a > monolithic interface? I'm afraid I'm not visualizing this very > well. I think of "atomic" as individible. Monolithic means "not divided when it should be." dictionary.com says: "Constituting or acting as a single, often rigid, uniform whole" To me, a "monolithic interface" is a network-addressable object that contains many "logical" objects which are not directly addressable themselves. e.g. purchase orders that do not have URIs themselves, but instead have purchase order numbers that must be submitted to the monolitic service in order to manipulate the acutal purchase order. A properly factored service would give each logical object a first-class URI address. Paul Prescod
Paul Prescod wrote: > > >Is anyone brave enough to stand up for monolithic services? > > >;) Even as a devil's advocate? > Monolithic means "not divided when > it should be." dictionary.com says: > "Constituting or acting as a single, > often rigid, uniform whole" > > To me, a "monolithic interface" is a network-addressable object > that contains many "logical" objects which are not > directly addressable themselves. > e.g. purchase orders that do not have URIs themselves, > but instead have purchase order numbers that must be > submitted to the monolitic service in order to > manipulate the acutal purchase order. > A properly factored service would give each logical object > a first-class URI address. Ok, I will attempt a very limited defense of the bad monolithic design from the viewpoints of: (a) incremental evolution and (b) paranoia. Note: this is a very limited defense of EDI-mailbox-style SOAP, not RPC-style SOAP. (a) Incremental evolution: we already have everything in place to do EDI-mailbox-style interactions, in fact, we do EDI. So now we will do Web-EDI using pretty much all the same internal mechanisms, including the exact same integration with our internal business apps. (b) Paranoia: You want me to do what? Give Web URIs to all my valuable business deal info? Are you out of your mind? Did you see (latest cracker scare story...)? (Remember that I am personally trying to evolve from EDI-mailbox- style ebXML to REST...) -Bob Haugen
> -----Original Message----- > From: Paul Prescod [mailto:paul@...] > Sent: Tuesday, December 03, 2002 12:43 PM > To: Mathews, Walden > Cc: Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Another REST vs. SOAP article > > > Mathews, Walden wrote: > > > >Is anyone brave enough to stand up for monolithic services? > > >;) Even as a > > >devil's advocate? > > > > > > Paul Prescod > > > > > > Not sure what you mean by 'monolithic' in this setting. I usually > > think of it as meaning indivisible. Is there such a thing as a > > monolithic interface? I'm afraid I'm not visualizing this very > > well. > > I think of "atomic" as individible. Monolithic means "not > divided when > it should be." dictionary.com says: "Constituting or acting > as a single, > often rigid, uniform whole" > > To me, a "monolithic interface" is a network-addressable object that > contains many "logical" objects which are not directly addressable > themselves. e.g. purchase orders that do not have URIs > themselves, but > instead have purchase order numbers that must be submitted to the > monolitic service in order to manipulate the acutal purchase order. A > properly factored service would give each logical object a > first-class > URI address. > > Paul Prescod Okay, in that case I'm not going to stand up for monolithic interfaces, even as devil's advocate, but it's not a bravery issue. Clean delegation is a key design concept. Now if only my boss understood that... Walden >
bhaugen32 wrote: > (b) Paranoia: You want me to do what? > Give Web URIs to all my valuable business deal info? > Are you out of your mind? > Did you see (latest cracker scare story...)? > > (Remember that I am personally trying to evolve from EDI-mailbox- > style ebXML to REST...) I've heard that reaction many times, but it seems to me to reflect a misunderstanding. Data is either on the Internet or it isn't. If there is some configuration of message bits that will get the data, then you need to make sure your cracker can't send you those bits (i.e. use passwords). What does it matter whether you use a standardized addressing mechanism (URIs) versus a non-standard one? I've argued in the past (and would rather not do it again) that using a standarized mechanism is actually better because your infrastructure understands what is going on better and can provide more support (e.g. ACLs on resource types). Paul Prescod
----- Original Message ----- From: "Paul Prescod" <paul@...> > > > (b) Paranoia: You want me to do what? > > Give Web URIs to all my valuable business deal info? > > Are you out of your mind? > > Did you see (latest cracker scare story...)? > > > > (Remember that I am personally trying to evolve from EDI-mailbox- > > style ebXML to REST...) > > I've heard that reaction many times, but it seems to me to reflect a > misunderstanding. Data is either on the Internet or it isn't. Security through obscurity is an illogical, but comfortable, reaction by many people. And yes, it does stem from misunderstanding the issues. If /they/ can't see how to get the information out (i.e. it needs programming), then probably it can't get out. Wrongheaded, but nobody said people are logical.
Paul Prescod wrote: > bhaugen32 wrote: > > > (b) Paranoia: You want me to do what? > > Give Web URIs to all my valuable business deal info? > > Are you out of your mind? > > Did you see (latest cracker scare story...)? > > > > (Remember that I am personally trying to evolve from EDI-mailbox- > > style ebXML to REST...) > > I've heard that reaction many times, but it seems to me > to reflect a misunderstanding. I agree. I hope it's clear that I am relating defenses I hear, from an evolutionary-next-step viewpoint. I am not arguing for their engineering validity. But I think those are two reasons why people who now do EDI (or think in terms of EDI) find EDI-mailbox-style Soap a more-convenient evolutionary next step than REST. REST may seem like a scarey leap into the unknown. > Data is either on the Internet or it isn't. If there > is some configuration of message bits that will get the data, then you > need to make sure your cracker can't send you those bits (i.e. use > passwords). What does it matter whether you use a standardized > addressing mechanism (URIs) versus a non-standard one? I've argued in > the past (and would rather not do it again) that using a standarized > mechanism is actually better because your infrastructure understands > what is going on better and can provide more support (e.g. ACLs on > resource types). I agree. But again, somebody who is now doing EDI will already have control mechanisms in place for EDI-style interaction, and so will feel like they are covered. (Regardless of the actual strength of their coverage.) And the standardized mechanisms for protecting Web resources may be new to them. It's the best I could do to respond to your challenge. -Bob Haugen
bhaugen32 wrote: > I agree. I hope it's clear that I am relating defenses I hear, from > an evolutionary-next-step viewpoint. I am not arguing for their > engineering validity. Yep, that's cler. Paul Prescod
Donald Ball wrote: > What other webapp infrastructures have people used for REST projects that > turned out well or poorly? I've used Quixote. It is quite REST-ful. You can have container objects that dispatch to other objects etc. I've also used .NET, which has very convenient XML parsing code (for XML with a schema). Paul Prescod
Mathews, Walden wrote: > Terminology strikes again. Object models and object oriented > programming have separate lives, according to what I read. Bill > is talking about polymorphic method resolution, which is one > feature of OO (the programming thing), while Paul's description > of "identity, state and behavior" is the /sine qua non/ of the > object model. I've always seen polymorphism as being the core feature of the "behaviour" part of Identity, State, Behaviour. Objects carry around their behaviour. Structs, XML documents, RDF graphs and other "pure data structures" do not. Paul Prescod
-----Original Message----- From: Paul Prescod To: Mathews, Walden Cc: Bill de hra; Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com Sent: 12/4/2002 8:43 PM Subject: OOP and object models Mathews, Walden wrote: >> Terminology strikes again. Object models and object oriented > programming have separate lives, according to what I read. Bill > is talking about polymorphic method resolution, which is one > feature of OO (the programming thing), while Paul's description > of "identity, state and behavior" is the /sine qua non/ of the > object model. >I've always seen polymorphism as being the core feature of the "behaviour" part of Identity, State, Behaviour. Objects carry around their behaviour. Structs, XML documents, RDF graphs and other "pure data structures" do not. Paul Prescod Yes, I shouldn't have said "polymorphic", strictly speaking. Jump tables are about dispatching to some method in a code inheritance hierarchy, and it's something we can ignore if we're mainly interested in runtime behaviors and properties, a la software architectures. Certainly the idea of different "shapes" lurking behind a single abstract interface is a 'behavioral' concept, not a code reuse one. Walden
Paul Prescod wrote:
Hi Paul,
> When you use the "handle as first parameter hack", you now have
to have
> two addresses for each object. The address of the service
(usually an
> HTTP URI) and the "handle" which is really just another address.
In my
> opinion, this is not proper OOP programming.
You see, I don't think your opinion holds for all cases, only for
the web case.
Arguably hiding things can be 'proper' OOP, depending on whether we
want to use encapsulation to simplify an interface: see Hide
Delgate, Remove Middle Man [1], and Facade [2].
It's very probably the the case that common encapsulation patterns
and idioms used in OOP are inappropriate for Web programming (I have
no end of bother with the Front Controller, a Facade variant that is
popular for designing websites). But that's not what I'm hearing
from you.
>It would be very rare to
> see a Java interface like:
>
> class IndividualAccount{
> function debit(accountNumber, val);
> function credit(accountNumber, val);
> }
>
> Because this makes it _impossible_ to pass a reference to an
account as
> a standard Java object reference.
If I can pass accountNumber as a value to a method, I must have got
it from somwhere, so I can make an Object for it:
Integer accno = new Integer(accountNumber);
...
not impossible then, but pretty useless.
>
> class AccountManager{
> function getAccount(number);
> }
>
> class Account{
> function debit(val);
> function credit(val);
> }
But don't stop there! In REST it's much more like:
class AccountManager:
def post(uri): ...
def get(uri): ...
class Account:
def post(uri): ...
def get(uri): ..
Any number of OO folks will tell you they don't like coarse
grained/uniform interfaces (or where method names are passed around
as keys). The reasons I've been given are:
1) it skirts around/tunnels through, the type system of the language.
2) it makes the the resulting code unclear.
(note that these are to do with code comprehension and maintainance,
rather than some technical bound on uniform interfaces).
The OO world values having non-standard interfaces. Then again, much
OOP is done for the local (machine or administrative) case, where
this view might make sense. It pays to remember that for many J2EE
and .NET developers it will not always be clear that what works well
for the local case won't work so well over the network - fine
grained data transfer and latent returns being obvious examples.
So I'm very wary of saying without qualification that the REST style
is *more* or *proper* OOP with respect to the services style (if
indeed there is such a thing as the services style).
I suspect that the problem you have with the services style is that
it constitutes a collection of antipatterns for distributed OOP. If
so, let's document what the risks of that style are. Communicating
to the OOP world through patterns/antipatterns is a great way to
make the case for the REST style - with the added bonus the claims
for REST will seem less grand.
> Now the account is a first-class object which can be passed around
> without reference to the query interface. i.e. it has identity,
state
> and behaviour.
I don't dispute this is important, but a large part of what is
supposed to be valuable about OO is encapsulation (particulary of
state that would otherwise be global). Not all objects want to be
exposed. Agian, why this needs to rethought for the web needs
explaining.
> This could
> be done in a language or system with per-object access controls.
Even in
> such a system, it is not straightforward if you've hacked static
methods
> to _emulate_ instance objects in a manner that is opaque to your
> infrastructure.
I didn't understand this bit. I think you're saying using globals to
manage state is a bad idea; if so I agree with you.
Bill de h�ra
[1] Refactoring, Martin Fowler
[2] Design Patterns, Gamma et al
I have a new article I wrote for Linux magazine designed for people who have never heard of REST. It shows the migration of a simple XML-RPC service to REST, demonstrating both the costs and benefits of the conversion. Paul
On Thu, 2002-12-05 at 17:21, Paul Prescod wrote: > I have a new article I wrote for Linux magazine designed for people > who > have never heard of REST. It shows the migration of a simple XML-RPC > service to REST, demonstrating both the costs and benefits of the > conversion. Does the article have a URI? Jason
> I suspect that the problem you have with the services style is that
> it constitutes a collection of antipatterns for distributed OOP. If
> so, let's document what the risks of that style are.
Ick, terminology is being misused. OOP is a programming structure
paradigm dependent on such things as classes and inheritance. There
is no such thing as distributed OOP. Object-based systems is what you
get when you take OOD and distribute the objects. It is called
object-based (instead of object-oriented) because we are talking
about architecture, rather than source code structure, and architecture
doesn't have classes and inheritance.
> Communicating
> to the OOP world through patterns/antipatterns is a great way to
> make the case for the REST style - with the added bonus the claims
> for REST will seem less grand.
That is difficult to do. The OOPSLA community took the architectural
concept of patterns and expanded it into anything with a recipe for
implementation. I use the original notion of patterns, which came
from Alexander watching human behavior as people live/work/move within
a space. The closest analogy in computing is how data moves within an
architecture. In other words, I do explain REST as a pattern, but
what people call patterns now is tuned more for programming idioms
rather than understanding system behavior.
Architectural styles and architectural patterns are fairly consistent,
but as you noted the purpose of REST is to force the developer into a
less object-specific architecture, which is contrary to most of the
OOD patterns. Whether that is good or bad depends on what is
being implemented.
Cheers,
Roy T. Fielding, Chief Scientist, Day Software
2 Corporate Plaza, Suite 150
Newport Beach, CA 92660-7929 fax:+1.949.644.5064
(roy.fielding@...) <http://www.day.com/>
Co-founder, The Apache Software Foundation
(fielding@...) <http://www.apache.org/>
Sorry. I meant to add: "email me to get it". I've done that a few times before on the list so it is implied for some old-timers. Jason Diamond wrote: > On Thu, 2002-12-05 at 17:21, Paul Prescod wrote: > > >I have a new article I wrote for Linux magazine designed for people > >who > >have never heard of REST. It shows the migration of a simple XML-RPC > >service to REST, demonstrating both the costs and benefits of the > >conversion. > > > Does the article have a URI? > > Jason > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
Hi, How to specify the intent of a POST? I believe Mark Baker has covered this topic in the past, but what was the conclusion? Michael
On Tue, Dec 10, 2002 at 03:33:57PM +1100, Michael Day wrote: > > Hi, > > How to specify the intent of a POST? I believe Mark Baker has covered this > topic in the past, but what was the conclusion? The only attempts I know of anybody trying to standardize on this, are with the "PEP" header in PEP, the SOAPAction header in SOAP 1.1, and the "action" media type attribute in SOAP 1.2. It pretty much needs a mandatory extension framework, which is why you can't just run out and define an HTTP header to do this. You could use RFC 2774 I suppose, but nobody implements that AFAIK. It's a shame that the only practical way to do this today is with SOAP, which brings in a lot of other baggage, doesn't have a PUT binding, etc.. I assume Waka will handle this no problem. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
I didn't realize I was going to be quoted verbatim (well, until later in the process), but here ya go; http://webservices.devchannel.org/article.pl?sid=02/12/10/1849249 Though not a very good way to win friends and influence people, I especially like my description of how we got to where we are today; So in a "if you pat my back, I'll pat yours" self-congratulatory frenzy, we arrived where we are today; lots of agreement on the core specs, yet very few services on the Internet." 8-) MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Given the broad experience around these parts, any thoughts? jb
Hi all, Here is a little (may be stupid) question: I've got a uri to a container. a GET return the contain of the container, and a POST (in a form-encoded format) add an element to the container. I'd like to generate a "dynamic form" to POST data, in a Jabber-query like maner. Indeed, in the jabber framework, an empty query return a description of the fields to feel to submit the query, allowing clients to create submission forms without knowing anything about the ressource. In a Rest env, does it make sens to answer to an empty post in such a maner, e.g. with an XForm doc, or is it better to use an other uri, to which POST add element and GET return the XForm ? I think the first solution is the most suitable, but in this case, which status/header should be return ? is 400 Bad Request ok ?
Jeff Bone wrote: > Given the broad experience around these parts, any thoughts? i suggest that you read the recent (nov. 30) slashdot thread arising from the release of postgresql 7.3. it has lots of postgresql vs mysql threads, and some of them have interesting observations. http://slashdot.org/article.pl?sid=02/11/30/1815200 from my POV postgresql is the more capable database, but IMO its website and online documentation is really really bad (vis-a-vis mysql's, that is). i've never before seen such a great product with such a terrible online 'image'. the mailing lists aren't archived that well either. i should probably do something about these points rather than whine about them, but i have seen these points voiced elsewhere, and this is what i believe to be the current situation. HTH, -vincent
On Tue, Dec 10, 2002 at 03:46:42PM -0500, Mark Baker wrote:
> I didn't realize I was going to be quoted verbatim (well, until
> later in the process), but here ya go;
>
> http://webservices.devchannel.org/article.pl?sid=02/12/10/1849249
qq{
"Decentralization" is actually the opposite side of the same coin as "low coordination costs." The need for registries with Web Services is a sure sign that you're not decentralized.
}
I'm curious about this. Registries are not required for Web Services but are
useful. But the same could surely be said for RESTian services too?
Am I misunderstanding something?
dj
http://www.pipetree.com/qmacro
What does this mean: "Web Services don't scale past *one* trust boundary, for the same reason above, visibility; they're an Intranet-only solution." Do you dispute the existence of the Google, Amazon and Blogger RPC APIs? I am totally in your corner that Web services don't scale in the sense that the web does (they are a collection of disjoint information systems, rather than a single information system) but it seems to me that you are overstating the case. Paul Prescod
1. Tim Bray gave a very positive Plenary talk on REST and Web Architecture. He didn't slam RPC-based Web Services (as he did when he spoke to our more intimate group in Vancouver) but nevertheless he was clearly pro-REST. His only references to other ways of doing things were oblique: "Some people do not give things URIs. This means that those things are not on the Web. That should be self-evidently a bad thing." 2. I spoke with Jeff Barr from Amazon. He says their REST interface is popular (no numbers) and some people have found ways to do things with it that are literally not possible with the SOAP interface. You can make an HTTP hyperlink to an Amazon XML page parameterized with an XSLT stylesheet. Amazon runs the stylesheet on the server side. This means that with nothing more than an HTML document and a stylesheet on geocities (no CGI!), you can generate a pretty sophisticated web storefront. People who think that REST and other ways of doing things are mostly the same because you can make them look the same with glue code totally miss the fact that there environments where there is _nowhere to put the glue code_. The continued rise of XML and XSLT makes REST more and more of a "no-brainer" and vice versa. That was also a theme of Tim's talk...that XML was the cure for many of the Web's weak points (machine to machine communication, internationalization, metadata, ...) Considering where we were a year ago, REST's current status is actually amazing considering the subtlety of the ideas. Paul Prescod
Jeff Bone wrote: > Given the broad experience around these parts, any thoughts? Whay Vincent said, also it depends out what you're doing. If you're just serving up content, or basically looking for a file system + indexing you can speak SQL with, mySQL is probably a good bet - and it's fast. PostgresSQL comes into its own when you need transactions or ACID capabilities. Bill de h�ra
Paul Prescod wrote, > People who think that REST and other ways of doing things are mostly > the same because you can make them look the same with glue code > totally miss the fact that there environments where there is _nowhere > to put the glue code_. Umm ... well, XSLT is code and it's executed at the client (presumably Amazon don't apply the stylesheet serverside). I'm not sure I can see what's new here (not that being new matters all that much). Cheers, Miles
On Wed, Dec 11, 2002 at 05:50:39AM -0500, Paul Prescod wrote: > What does this mean: > > "Web Services don't scale past *one* trust boundary, for the same reason > above, visibility; they're an Intranet-only solution." > > Do you dispute the existence of the Google, Amazon and Blogger RPC APIs? > I am totally in your corner that Web services don't scale in the sense > that the web does (they are a collection of disjoint information > systems, rather than a single information system) but it seems to me > that you are overstating the case. That RPC based services like Google exist, doesn't mean they scale. HTTP gets past firewalls because it's trusted and visible; its "API" was rigorously reviewed in the IETF process. Google's API wasn't, and isn't known to be secure, so other organizations exposing or using search services will be wary of using/reusing that API. The scaling problem is that it's prohibitively expensive to review every single API that might be created. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
On Wed, Dec 11, 2002 at 11:47:45AM +0000, DJ Adams wrote:
> qq{
> "Decentralization" is actually the opposite side of the same coin as "low coordination costs." The need for registries with Web Services is a sure sign that you're not decentralized.
> }
>
> I'm curious about this. Registries are not required for Web Services but are
> useful. But the same could surely be said for RESTian services too?
>
> Am I misunderstanding something?
Well, there's registries, and then there's registries. Unfortunately
I was asked to be brief, so I couldn't elaborate much in the interview.
I'm referring to the "link database" form of registry, where to even
create a service requires registration, rather than registries for
things like media types which are just trusted identifiers published by
an authority to demonstrate that it meets some minimum level of quality
(e.g. text/html vs. text/x-foofoo).
FWIW, the prevalence of WSDL-over-GET, despite the push for UDDI, shows
how strong the forces of decentralization can be.
MB
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Mark Baker wrote: > That RPC based services like Google exist, doesn't mean they scale. > HTTP gets past firewalls because it's trusted and visible; its "API" was > rigorously reviewed in the IETF process. Google's API wasn't, and isn't > known to be secure, so other organizations exposing or using search > services will be wary of using/reusing that API. > > The scaling problem is that it's prohibitively expensive to review every > single API that might be created. The Web Services industry _is_ amazingly poor at reusing service interfaces. It is even worse than the XML industry (which tends to have five schemas for every problem). I'm not sure I completely buy your argument about the source of the problem but I do observe the problem.. BTW, my last message probably came across the wrong way. I had one nit (or probably misunderstanding) but overall I loved the article! Paul
Miles Sabin wrote: > Paul Prescod wrote, > > >People who think that REST and other ways of doing things are mostly > >the same because you can make them look the same with glue code > >totally miss the fact that there environments where there is _nowhere > >to put the glue code_. > > > Umm ... well, XSLT is code and it's executed at the client (presumably > Amazon don't apply the stylesheet serverside). > > I'm not sure I can see what's new here (not that being new matters all > that much). Yes, Amazon does apply the stylesheet on the server side. I was surprised that they would commit those computational resources but it seems to work. Paul Prescod
Paul Prescod wrote, > Yes, Amazon does apply the stylesheet on the server side. I was > surprised that they would commit those computational resources but it > seems to work. Wow! That's brave ... Still, that doesn't affect my point, such as it was: there's code, and there's somewhere for it to go. Cheers, Miles
How well suited is WSDL in it's current form for describing REST-style services? Is it necessary at all, or could the OPTION method be used to return a valid schema describing the data that could be accepted at that URI?
On Wed, Dec 11, 2002 at 08:23:23AM +0100, Yannick Loiseau wrote: > Hi all, > Here is a little (may be stupid) question: > I've got a uri to a container. > a GET return the contain of the container, and a POST (in a form-encoded Presumably you mean "contents of the container"? > format) add an element to the container. > I'd like to generate a "dynamic form" to POST data, in a Jabber-query like > maner. You could put it in the list of things that are returned, or perhaps link to a form from what's returned on a GET to the container. > Indeed, in the jabber framework, an empty query return a description > of the fields to feel to submit the query, allowing clients to create > submission forms without knowing anything about the ressource. > In a Rest env, does it make sens to answer to an empty post in such a maner, > e.g. with an XForm doc, or is it better to use an other uri, to which POST > add element and GET return the XForm ? I'd say the latter. The former is a private agreement between client and server, plus it seems a safe operation to me so should use GET anyhow. ... if I understood you correctly. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Yannick Loiseau wrote: > I'd like to generate a "dynamic form" to POST data, in a Jabber-query like > maner. Indeed, in the jabber framework, an empty query return a description > of the fields to feel to submit the query, allowing clients to create > submission forms without knowing anything about the ressource. i don't know much about jabber, but maybe this will be of some use to you anyway. i have a URI for the form. if we were talking about bank accounts, the URI would be /accounts/form/ to get the form i do a GET on this URI. the target of the returned form representation is the container URI. i also have people editing a single resource which is not a container using something that looks like /accounts/1234/form/ you could say these forms are 'sub-resources' of the 'accounts' or 'account' resource. i don't know whether that makes much sense; this was just a good (enough) way for me to load already-populated forms. > I think the first solution is the most suitable, but in this case, which > status/header should be return ? > is 400 Bad Request ok ? i'm not sure what case you're referring to here so i'll try cover every angle i am aware of. in my system the POST response would be a "201 Created", the GET is just a normal "200 OK". as for input which is lexically or semantically invalid, i just use "400 Bad Request", but only because i'm not sure whether there is something more specific i should be using. i wonder whether it should be 4xx Bad *Representation* (because it's not like there's something wrong with the HTTP headers or anything) but i digress. HTH, -vincent
----- Original Message ----- From: "Miles Sabin" <miles@...> > > Umm ... well, XSLT is code and it's executed at the client (presumably > Amazon don't apply the stylesheet serverside). > Actually, I'm pretty sure they do apply it on Amazon's servers. I wonder if they allow extension functions...
> > a GET return the contain of the container, and a POST (in a form-encoded > Presumably you mean "contents of the container"? yes... sorry for my english > You could put it in the list of things that are returned, or perhaps > link to a form from what's returned on a GET to the container. [...] > it seems a safe operation to me so should use GET > anyhow. but the GET is supposed to return the contents, and not the form, and using an other uri to GET the form or POST the data to is less meaningful than posting to the container uri (if I have well understood the semantic of POST)...
----- Original Message -----
From: "Yannick Loiseau" <yloiseau@...>
> > You could put it in the list of things that are returned, or perhaps
> > link to a form from what's returned on a GET to the container.
> [...]
> > it seems a safe operation to me so should use GET
> > anyhow.
>
> but the GET is supposed to return the contents, and not the form, and
using
> an other uri to GET the form or POST the data to is less meaningful than
> posting to the container uri (if I have well understood the semantic of
> POST)...
With HTTP, you either provide a blended view of data and acceptable
operations (the form) or you have different resources for the data and the
form. The form can still reference the container as the target of the POST
though.
You could also use different content-type representations of the container
resource (the client uses the Accept header) one for the data and one for
the description of how to interact with it.
If the form is retrievable separately from the data, there are different
ways to reference between the two:
- a response header that identifies the resource that describes the
acceptable interactions for that resource
- a separate resource that identifies the data resource and the
input/schema resources, there may be more than one acceptable input to the
same resource. For example:
<manufacturer>
<products>
<product type='shoes'
resource-location='http://shoesRus.com/shoes/'
service-description='http://shoesRus.com/shoes/services''>
</products>
</manufacturer>
I like the approach of mixing the data and the accepatable interactions -
kind of how HTML did it.
On Wed, Dec 11, 2002 at 08:47:36PM +0100, Yannick Loiseau wrote: > but the GET is supposed to return the contents, and not the form, Well, if your data format supports it, you could do both. If you're defining the format, you should consider including a "meta", "header", or similar section where stuff like this can be communicated. > and using > an other uri to GET the form or POST the data to is less meaningful than > posting to the container uri (if I have well understood the semantic of > POST)... Ideally, sure, but it's not etched in stone. It depends on the flow of your application. Most web apps don't support GET on the resource they POST to, but the application steered the client to that first URI, so all is well. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
I hadn't seen this before - kudos to Alex Klevitsky. === http://www.e-servicescorp.com/html/REST_Technology_PR.html MIB Deploys REST Technology for XML Web Service (WESTWOOD, MA. October 17, 2002) - MIB Group, Inc. announced today the availability of a set of Web services that extend in-house IT business solutions to clients by providing software functionality directly via the Web versus a standalone application. Included are MIB's Security Alert Entity Look-up Utility and Security Alert ID Look-up Utility, both research companions to MIB's Security Alert Services (SAS) compliance solution for the USA PATRIOT Act (OFAC) and OSFI Canadian regulations. These Web services retrieve all available information on specific "denied parties" directly from the OFAC or OSFI web sites, on a manual or fully integrated basis. MIB Web services use an architectural style called REST (Representational State Transfer) that employs standard Internet technologies (XML, URI and HTTP) to provide quick, simple integration with a customers' existing business systems. Accessing MIB's Web services is easy, and users have the option of receiving formatted HTML or native XML. The Web services also ensures that users of MIB's Security Alert Services compliance reports are seeing the most up-to-date information available from both OFAC and OSFI. "We evaluated all available Web service architectural solutions and found that URI-centric REST is simple, elegant and based entirely on HTTP. Our customers will enjoy the ease of getting XML output from this service by using conventional URLs and by sending HTTP requests to the specified MIB Web address," states Alex Klevitsky, MIB's Enterprise Systems Architect. "MIB Web services characterizes a company-wide effort towards a service-oriented architecture, providing a universal integration platform for MIB clientele. This is an important move forward in the next generation Internet delivering tighter business relationships and more efficient business processes," says Robert L. DiAngelo, MIB's Chief Information Officer. Both Klevitsky and DiAngelo see Web services based on REST, along with its Simple Object Access Protocol (SOAP) counterpart, playing major roles as MIB continues to reengineer core business systems and deploy new functionality to clients. About MIB Group, Inc. MIB Group, Inc., headquartered in Westwood, Massachusetts, is the premier provider of Internet-based information and knowledge services to the global risk management market space, and is a leading facilitator of electronic insurance commerce via dedicated networks and Internet-based systems. MIB member companies underwrite more than 95 percent of the premium dollars of individual life insurance written in the United States and Canada. More information about MIB Group, Inc. is available at www.mib.com.
Miles Sabin wrote: > Paul Prescod wrote, > > >Yes, Amazon does apply the stylesheet on the server side. I was > >surprised that they would commit those computational resources but it > >seems to work. > > > Wow! That's brave ... > > Still, that doesn't affect my point, such as it was: there's code, and > there's somewhere for it to go. At some high enough level of abstraction that may be a meaningful thing to say, but at the coding level there is a big difference between XSLT and "ordinary code". For one thing, XSLT was designed specifically to work with XML input, output and the flat namespace model used in REST web services. No other language has that characteristic. Let's turn the question around. If there is really no difference between their REST and SOAP versions of the Web Service then why do you think that the REST one has this feature while the SOAP one does not? How would you even propose to implement a similar feature for a SOAP RPC interface? "Upload Javascript using a SOAP library and we'll run it on our server?" That seems quite unlikely, inefficient, hard to secure and generally ugly. Paul Prescod
Jeffrey Winter wrote: > How well suited is WSDL in it's current form for describing REST-style > services? Not very: http://www.blogstream.com/pauls/1032521623/index_html http://www.prescod.net/rest/wsdlhttp.html > Is it necessary at all, or could the OPTION method be used to return a > valid schema describing the data that could be accepted at that URI? Interesting idea...a HEAD-retrieved header could also be used. Paul Prescod
Paul Prescod wrote, > Let's turn the question around. If there is really no difference > between their REST and SOAP versions of the Web Service I didn't mean to imply that there was no difference between the two versions. I was merely commenting on your comment, > People who think that REST and other ways of doing things are mostly > the same because you can make them look the same with glue code > totally miss the fact that there environments where there is _nowhere > to put the glue code_. which I read as a claim that REST could do exciting things without needing glue code or anywhere to put it. My quibble was that the XSLT was the code, and (as it turns out) Amazon provide an execution environment for it. As I said, not all that much of a quibble ... just a reminder that whatever the merits of REST, it can't do magic. As it happens, with an "XSLT execution environment provider" you probably could do something very similar with the SOAP service without a great deal of difference in the complexity or overhead either on the client or the server. But that's a different can'o'worms. Hmm ... mobile XSLT, the new Java? ;-) Cheers, Miles
Has anyone heard any more about Fielding's Waka? I'd be interested in an up-to-date link, or anything comparing it to WebDAV and HTTPEvents. RFC yet? Duncan Cragg.
The most up to date info Roy's presented is here; http://www.apache.org/~fielding/waka/ The presentation there has a lot of good stuff in it. Maybe at next year's ApacheCon, he'll have a demo. 8-) MB On Thu, Dec 12, 2002 at 04:47:26PM +0000, Duncan Cragg wrote: > Has anyone heard any more about Fielding's Waka? > > I'd be interested in an up-to-date link, or anything comparing it to > WebDAV and HTTPEvents. > > RFC yet? > > > Duncan Cragg. > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
I talked to Amazon folks about this when they first came out with the service. They support doing XSLT on the server (to my amazement -- it opens up a whole can of worms I don't think they considered). No support for installing extension functions on their servers, but with the document() function, you can call external services via http requests. I know, it's not the same, but then what do you want for free... (:-) Ramin -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Wednesday, December 11, 2002 9:20 AM To: rest-discuss Subject: Re: [rest-discuss] REST tidbits from XML 2002 ----- Original Message ----- From: "Miles Sabin" <miles@...> > > Umm ... well, XSLT is code and it's executed at the client (presumably > Amazon don't apply the stylesheet serverside). > Actually, I'm pretty sure they do apply it on Amazon's servers. I wonder if they allow extension functions... To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Ramin Firoozye wrote, > I talked to Amazon folks about this when they first came out with the > service. They support doing XSLT on the server (to my amazement -- it > opens up a whole can of worms I don't think they considered). No > support for installing extension functions on their servers, but with > the document() function, you can call external services via http > requests. They allow arbitrary user-supplied stylesheets to make arbitrary outgoing HTTP requests from their servers???!!!! Wow! That's an accident waiting to happen ... who needs a bunch of IRC zombies when you can hijack Amazons boxes for a DDoS. Paul, I suggest that until they fix it you _don't_ flag it up as an exemplar. Do you have a contact at Amazon? Cheers, Miles
----- Original Message ----- From: "Miles Sabin" <miles@...> > They allow arbitrary user-supplied stylesheets to make arbitrary > outgoing HTTP requests from their servers???!!!! Only GETs, but that is sufficient to cause a lot of trouble. I think you have to be an affiliate or some other semi-trusted entity to get in though.
That's true. If you do a bunch of 100MB XML transfers via document(), sooner or later I imagine they'll yank your associate ID. Still, pretty gutsy of them to leave it open... Ramin -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Thursday, December 12, 2002 11:41 AM To: rest-discuss Subject: Re: [rest-discuss] REST tidbits from XML 2002 ----- Original Message ----- From: "Miles Sabin" <miles@...> > They allow arbitrary user-supplied stylesheets to make arbitrary > outgoing HTTP requests from their servers???!!!! Only GETs, but that is sufficient to cause a lot of trouble. I think you have to be an affiliate or some other semi-trusted entity to get in though. To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Great to see the enthusiasm building around this; when I mentioned it in this forum a few weeks ago, it got panned as "oh that; it's been around for a while". Is this a sign of something real, then? Walden PS - just to let you all know that I'm jobless since last Friday, and employment leads are appreciated. ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "Duncan Cragg" <rest@...> Cc: <rest-discuss@yahoogroups.com> Sent: Thursday, December 12, 2002 12:33 PM Subject: Re: [rest-discuss] Waka > The most up to date info Roy's presented is here; > > http://www.apache.org/~fielding/waka/ > > The presentation there has a lot of good stuff in it. Maybe at next > year's ApacheCon, he'll have a demo. 8-) > > MB > > On Thu, Dec 12, 2002 at 04:47:26PM +0000, Duncan Cragg wrote: > > Has anyone heard any more about Fielding's Waka? > > > > I'd be interested in an up-to-date link, or anything comparing it to > > WebDAV and HTTPEvents. > > > > RFC yet? > > > > > > Duncan Cragg. > > > > > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Web architecture consulting, technical reports, evaluation & analysis > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
On Thu, Dec 12, 2002 at 03:41:17PM -0500, Walden Mathews wrote: > Great to see the enthusiasm building around this; when I mentioned it > in this forum a few weeks ago, it got panned as "oh that; it's been > around for a while". Is this a sign of something real, then? Just because Roy's been talking about it for a while, doesn't mean I wasn't excited about it. He just hadn't said much about it until this most recent ApacheCon. Yah, I think it sounds really good. The better self-describing nature of the messages should make for interesting uses, especially in routing, as it will be obvious what a representation on-the-wire will be for. Currently, the difference between a POST response and a GET response requires context from the connection on which the request was made. Decoupling that further will be nice, though, like I said before, implementation complexity could get nasty. > Walden > > PS - just to let you all know that I'm jobless since last Friday, and > employment leads are appreciated. Sorry to hear that, Walden. 8-( MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
> I like the approach of mixing the data and the accepatable interactions - > kind of how HTML did it. Me too. I like implicit resources like "room schedule" from the little conference room application I was prototyping with when the axe fell, in which a GET on /rooms/demo/schedule defaults to the current week's schedule in the demo room, but its representation includes links to the next week's schedule, the previous week's schedule, and also includes a form for sending up the date spec for the week(s) schedule you're actually after, in case it's not proximal. I think this is consisten with the idea of "here's some information now, and there's more available", i.e., the perceived latency of the application is low as long as relevant info and links are being sent back, and that info helps the client decide what to do next. Comments?
(decloaking) With the recent unveiling of the Blogger 2 API there has been a great deal of discussion regarding its shortcomings and best route going forward. We're all aware of the issues of XML-RPC based interfaces -- it was just discussed a few weeks ago. It seems if ever there was a tool/medium that needed a RESTful API it's weblogging. Joe Gregorio has been developing a prototype with such an API and made this post for feedback. (My response never made it to the list however I did make a weblog post.[1]) It's been nearly a month since this post was made and now seems like an appropriate time to raise it again. Joe and I have been continuing to discuss the notion in private emails. Rather then debate amongst ourselves, Joe and I opened a mailing list for a community discussion of web service interfaces using REST for enabling collaborative authoring and content tools based. Some examples of existing initiatives that would be an appropriate topic for discussion include (but are not limited to) RESTLog, Extremely Simple Syndication (XSS) format and TrackBack. All are welcome and encouraged to join the discussion. http://groups.yahoo.com/group/ucapi-discuss/ <tim/> [1] http://www.mplode.com/tima/archives/000153.html --- In rest-discuss@yahoogroups.com, Joe Gregorio <joe@b...> wrote: > I am working on a REST based weblog interface, described here: > > http://wellformedweb.org/RESTLog.cgi/5 > > the design of which is heavily influenced by: > > http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger > > Before I get too far along I want to make > sure I haven't wandered off into the weeds. > Any feedback would be greatly appreciated. > > Thanks, > -joe > > -- > http://BitWorking.org > http://WellFormedWeb.org
Miles Sabin wrote: > > > >People who think that REST and other ways of doing things are mostly > >the same because you can make them look the same with glue code > >totally miss the fact that there environments where there is _nowhere > >to put the glue code_. > > > which I read as a claim that REST could do exciting things without > needing glue code or anywhere to put it. REST can do exciting things without needing glue code or anywhere to put it. I can extract an integer data element out of an Amazon REST resource without a single line of code (unless you count an XPointer as "code"). > As it happens, with an "XSLT execution environment provider" you > probably could do something very similar with the SOAP service without > a great deal of difference in the complexity or overhead either on the > client or the server. But that's a different can'o'worms. The client is a web browser. Heck, it could be Lynx or the command line browser. The complexity is in forcing the end-user to install a SOAP client. That's a great deal of difference. Paul Prescod
I would imagine they have customized whatever XSLT engine they are using on the server-side to lock down what document() is capable of. Mozilla 1.x's XSLT engine for example does not allow cross-domain access at all so my Xoomle-Amazon demo can't work directly in that browser. I've used a version of this at work to demonstrate the potential power of REST: http://www.xefer.com/demo.html It's hardly earth-shattering, but it begins to prove a point. ----- Original Message ----- From: Ramin Firoozye To: rest-discuss Sent: Thursday, December 12, 2002 3:07 PM Subject: RE: [rest-discuss] REST tidbits from XML 2002 That's true. If you do a bunch of 100MB XML transfers via document(), sooner or later I imagine they'll yank your associate ID. Still, pretty gutsy of them to leave it open... Ramin -----Original Message----- From: S. Mike Dierken [mailto:mdierken@...] Sent: Thursday, December 12, 2002 11:41 AM To: rest-discuss Subject: Re: [rest-discuss] REST tidbits from XML 2002 ----- Original Message ----- From: "Miles Sabin" <miles@...> > They allow arbitrary user-supplied stylesheets to make arbitrary > outgoing HTTP requests from their servers???!!!! Only GETs, but that is sufficient to cause a lot of trouble. I think you have to be an affiliate or some other semi-trusted entity to get in though. To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. To unsubscribe from this group, send an email to: rest-discuss-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
So I skipped a talk because the title did not strike my fancy: "Web-Services API for a Government Procurement Application". The hype around Web Services can get kind of nauseating and it doesn't comfort me that taxpayer money is used to fund development based on the standards relatively uncritically. But it turned out that the talk was actually about a REST based system: "Following the REST style, Procurement Desktop Defence entities such as purchase requests, awards and line items are, like Web pages, given URL�s. API clients will use HTTP methods to create, select, update and delete these entities, which are represented using an XML vocabulary based on the existing client/server PD� vocabulary, extended to incorporate PD e information and constructs described by this architecture and XML standards�XML Namespaces, XML Base, XLink, XPointer and XInclude. To interact with the Public API requires only a platform capable of TCP/IP communication (to send HTTP messages) and string processing (to process XML)." Paul Prescod
http://www.googlefight.com/cgi-bin/compare.pl?q1=REST&q2=SOAP&B1=Make+a+fight%21&compare=1&langue=us (short version: http://makeashorterlink.com/?W1B5517C2 ) === Number of results on Google for the keywords REST and SOAP: REST (26 100 000 results) versus SOAP (6 170 000 results) The winner is: REST === Disclaimer: SOAP and REST are not competing technologies. But if they were, REST would clearly be the most popular as you can see above. Note how I used two interesting facets of Web architecture in this very message: query strings and redirects! Paul Prescod
Paul,
you wrote the following in your private mail, but my question might
be of interest for others, so I turn to the list.
[Paul Prescod:]
> [...] Let's say that there is a topic map for famous physicists.
> The publisher of that topic map could say: "Use this URI to browse our
> topic map in HTML for web browsrs and there is an XML version served
> from this other URI for machine processing and perhaps for newer
> XML-aware browsers."
Does that mean that I don't have to rely on content negotiation for
choosing the format of the response? So, it would be RESTful to have
those two URIs for example
http://www.physicists.org/html/list-of-physicists
http://www.physicists.org/xml/list-of-physicists
although the representations they return are
representations of the same resource (concept) and only differ
in the markup language used ?
Jan
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@...
Web: http://www.topicmapping.com
Jan Algermissen wrote: > Does that mean that I don't have to rely on content negotiation for > choosing the format of the response? So, it would be RESTful to have > those two URIs for example > > http://www.physicists.org/html/list-of-physicists > http://www.physicists.org/xml/list-of-physicists > > although the representations they return are > representations of the same resource (concept) and only differ > in the markup language used ? the trouble (IMHO) with this is that you have different representations of the same resource using different URIs. i wouldn't say it's not RESTful, but i do think it dilutes the RESTfulness. because most UAs, be they RSS aggregators or web browsers, seem to be brain-damaged when it comes to content negotiation, i believe the best compromise is to use a query-string parameter to do the content-negotiation instead. i see that joe gregorio uses this technique for RSS representations in RESTLog[0]. you can use /RESTLog.cgi?rss for example. i prefer to use a more explicit query-string, i.e. ?_type=xml. the underscore before type is to reduce the potential for a namespace collision with a 'real' query parameter name. the reason to use a query-string name/value pair is to ease integration with URIs that have 'legitimate' query-strings. for content-negotiation-capable UAs, you just leave that querystring parameter out. i think this is more RESTful than having a different URI for every single representation. i think it would be useful if people building RESTful systems used a standard querystring parameter for this purpose (the same way google uses ?q=foo for a keyword search and others have copied this) so content-negotiation capable UAs know they can discard it, keeping a 'cleaner' URI. -vincent references: 0. http://wellformedweb.org/
Vincent D Murphy wrote:
>because most UAs, be they RSS aggregators or web browsers, seem to be
>brain-damaged when it comes to content negotiation, i believe the best
>compromise is to use a query-string parameter to do the
>content-negotiation instead. i see that joe gregorio uses this
>technique for RSS representations in RESTLog[0]. you can use
>/RESTLog.cgi?rss for example.
>
A small point of clarification, RESTLog does conneg but also supplies
the query parameter for those situations where the client doesn't do conneg.
>
>i prefer to use a more explicit query-string, i.e. ?_type=xml. the
>underscore before type is to reduce the potential for a namespace
>collision with a 'real' query parameter name. the reason to use a
>query-string name/value pair is to ease integration with URIs that have
>'legitimate' query-strings.
>
I like that suggestion. I suppose I would have run into the problem when
I added search to RESLog :)
-joe
--
http://bitworking.org
http://wellformedweb.org
Joe Gregorio wrote: > A small point of clarification, RESTLog does conneg but also supplies > the query parameter for those situations where the client doesn't do > conneg. noted. i left that out inadvertently; i actually see the query parameter as a mechanism for 'overriding' conneg, therefore when the parameter is left out, one falls back to normal conneg, or failing that, default behaviour. -vincent PS conneg is a nice abbreviation, hadn't seen that before now.
Vincent D Murphy wrote: > Joe Gregorio wrote: > > >A small point of clarification, RESTLog does conneg but also supplies > >the query parameter for those situations where the client doesn't do > >conneg. > > > noted. i left that out inadvertently; i actually see the query > parameter as a mechanism for 'overriding' conneg, therefore when the > parameter is left out, one falls back to normal conneg, or failing > that, default behaviour. I think that your conventions are quite reasonable as a workaround for the current situation. Paul Prescod
When Sam and I discussed this face-to-face, I told him that content negotiation is the correct way to do it in theory but in practice browsers and some HTTP libraries are not very intelligent about giving any control over content negotiation. So there is a purity/practicality trade-off there. You can actually do it both ways without hurting anything so that people who can't get their browser/library to do conneg can fall back to the URIs. Paul Prescod
> for content-negotiation-capable UAs, you just leave that querystring > parameter out. i think this is more RESTful than having a different URI > for every single representation. This all sounds good, but pedantically aren't these *different* URIs: http://foo.com/bar http://foo.com/bar?abc=123 Michael
> > for content-negotiation-capable UAs, you just leave that querystring > > parameter out. i think this is more RESTful than having a different URI > > for every single representation. > > This all sounds good, but pedantically aren't these *different* URIs: > > http://foo.com/bar > http://foo.com/bar?abc=123 The way I have been using query strings (which is not neccessarily the same view shared by the RFCs) is that "http://foo.com/bar" is the resource, and "?abc=123" is a filter on that resource. For example: http://foo.com/bar?_type=xml Means the resource http://foo.com/bar filtered by "_type=xml" -- in other words, converted to an XML representation. This world-view works very well for me in cases of querying a large resource: http://foo.com/bars?style=blue Returns a subset of http://foo.com/bars, that in which "style" is "blue". (Whatever that may mean to the app) -Andrew
> The way I have been using query strings (which is not neccessarily the same > view shared by the RFCs) is that "http://foo.com/bar" is the resource, and > "?abc=123" is a filter on that resource. It would be interesting to have more discussion on this point, as I have been experimenting with various resource classifications and it makes a big difference whether the query string is a filter or is a sub-resource (for example, /foo or ?foo could each be used as a filter in an underlying CGI application, but what implications does that have for what resources are and what URIs identify?). On the same topic, do the URIs _?a=b&b=c and _?b=c&a=b identify the same resource, or different resources? (One of the issues with saying that query strings identify sub-resources rather than filters...) Michael
----- Original Message ----- From: "Vincent D Murphy" <vdm@...> > > i prefer to use a more explicit query-string, i.e. ?_type=xml. the > underscore before type is to reduce the potential for a namespace > collision with a 'real' query parameter name. I've done the same thing, but I've used the same names and values as from the HTTP RFC, such as http://www.example.com/topicmaps/?do:Accept=text/xml So this uses "do:" as a qualifier (the ':' character might be a problem) and the same names as the HTTP headers, in order to easily point developers to an existing specification for details and documentation.
----- Original Message ----- From: "Andrew Tipton" <atipton@...> > The way I have been using query strings (which is not neccessarily the same > view shared by the RFCs) is that "http://foo.com/bar" is the resource, and > "?abc=123" is a filter on that resource. That may be how your internal system views things, but from the URI & HTTP specs, they are two separate resources and all external clients will/can treat them as separate & you cannot requires agents to understand the site-specific internal application use. One of the tricks with REST is to have your internal implementation do cool things with query terms, yet have all external agents treat them opaquely.
Tim Bray wrote: > Lots > of: schema-languages, topic maps, databases, Web Services. Not much of: > graphics, RDF, publishing. -Tim Actually, there was a lot of content management. http://makeashorterlink.com/?F2E8218C2 And electronic business (UBL, ebXML, xBRL) as distinguished from web services. The proceedings are available here: * http://www.idealliance.org/papers/xml02/dx_xml02/index.html There is some good stuff in there. Worth browsing. REST is also starting to get some representation. Tim talked about it somewhat in his plenary, and then there were these three regular talks: * http://www.idealliance.org/papers/xml02/dx_xml02/papers/03-02-03/03-02-03.html * http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-00-13/06-00-13.html * http://makeashorterlink.com/?P3F8528C2 Considering that a year ago the number of people who had heard about REST could fit in a Mini, that's good progress. We're up to a couple of city buses. Paul Prescod
Michael Day wrote: > On the same topic, do the URIs _?a=b&b=c and _?b=c&a=b identify the same > resource, or different resources? (One of the issues with saying that > query strings identify sub-resources rather than filters...) This question applies to any two URIs, that it, I wouldn't like to treat URIs with query strings as a special case. Given that many URIs can map to one resource, the answer seems to be possibly. But I'm not sure how you'd go about declaring that. This is also an (important) issue for RDF folks who want to merge two or more graphs. Bill de h�ra
Michael Day wrote: > This all sounds good, but pedantically aren't these *different* URIs: > > http://foo.com/bar > http://foo.com/bar?abc=123 Yes, but they may (or may not) denote the same resource. Bill de h�ra
Jan Algermissen wrote: > > Does that mean that I don't have to rely on content negotiation for > choosing the format of the response? So, it would be RESTful to have > those two URIs for example > > http://www.physicists.org/html/list-of-physicists > http://www.physicists.org/xml/list-of-physicists > > although the representations they return are > representations of the same resource (concept) and only differ > in the markup language used ? I think Mike's argument applies here. You can't assume that clients outside your system (ie most of them) will understand the processing assumptions built into your URIs; in the HTTP case, the protocol provides somewhat for obtaining representations based on a mimetype. But it does once again highlight the difficulty of the URI opacity axiom (cue Jeff Bone), tho' I /think/ I saw TBL describe it as merely being a good practice recently; maybe it's been downgraded. Bill de h�ra
Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis' (i.e., as opposed to getting /all/ the data back as /soon/ as it's requested)? Example 1. Using HTTP/1.1 as a P2P protocol - the search for the Resource could take some time, so either the Response takes a minute and keeps the Request open (risking proxy timeout), or the line is 'pinged' with void chunks while the peer is waiting. (GET http://p2psystem/britney32541) Example 2. Using HTTP/1.1 as a media streaming protocol: there is /never/ any content length - the channel just goes on and on, sending chunks... (GET http://britney-radio/) Example 3. The Resource being fetched is not a simple file, but comes from a user interface (GET http://turing-test/is-it-britney?favourite+colour) Example 4. The Resource is a user typing into a chat field at random times (GET http://britney-oracle/what-she-says-now) I'm as interested in 'REST compliance' as HTTP/1.1 compliance in the above. | Related issues in HTTP/1.1 context : | | (a) Was chunked transfer encoding designed for streaming media, or is that usage a hack? | (b) Are proxies actually required to remove transfer encodings in HTTP/1.1? | (c) What does HTTP/1.1 say about request-response timeouts? | (d) What about inter-chunk timeouts? (OK, you can redirect me to an HTTP list for these!! I couldn't find anything about the above from scanning RFC2616.) Hope this all makes sense and I'm not being too demanding with a big list of questions, coming up to holiday time... :-) Duncan Cragg
Hi there, I'm trying to get a better feeling of the right way to RESTify an interface to a set of services, coming from existing SOAP and XML-RPC interfaces. I'm a newcomer to REST and I just discovered this list, please pardon me if I'm naive. The documents I exchange with the REST interface are mainly server configuration, status and statistics, for multiple profiles. A first issue is handling the collection of profiles, similar to how a REST style blogger interface would handle a collection of posts: http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger POSTing to the container might be a solution, which I first read in Philip Eskelin's mail: http://groups.yahoo.com/group/rest-discuss/message/2974 This seems to be kind of bending the semantics of POST -- sort of assuming that the path is just a selector in a super document -- but works well as an alternative to having to GET the latest profile identifier and to PUT to the next profile ID (handling race conditions, overwriting existing profiles, etc). Browsing around for inspiration, I stepped into Mark Baker's article on PUT vs. SET: http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put If I get this right, if PUTting a document has side effects, then PUT isn't the right method to use, you should be using a (to be proposed) SET method. I'm currently updating profile cofniguration and status via PUT, would the use of SET be more appropriate? (the clients to this interface probably wouldn't be browsers) I view POST as "PUT but in append", so for the creation of new profiles would there be a need for a "SET but in append" method? Thanks, Duncan -- http://duncan.focuseek.com
On Mon, Dec 16, 2002 at 11:03:15AM +0100, Duncan Wilcox wrote: > Browsing around for inspiration, I stepped into Mark Baker's article on > PUT vs. SET: > > http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put > > If I get this right, if PUTting a document has side effects, then PUT > isn't the right method to use, you should be using a (to be proposed) > SET method. > > I'm currently updating profile cofniguration and status via PUT, would > the use of SET be more appropriate? (the clients to this interface > probably wouldn't be browsers) SET is PUT plus a hook to a processing model. The only reason I'm even considering documenting it is for use with SOAP. I don't think it's useful to you here. > I view POST as "PUT but in append", so for the creation of new profiles > would there be a need for a "SET but in append" method? POST is just "hand over this data". Unlike PUT/SET, you have no idea what the state of the resource to which you're POSTing will be after it's completed. That's why the container abstraction represents POST so well, I've found, since all you know when you're dealing with a container is that the data was added/submitted to it. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
> SET is PUT plus a hook to a processing model. The only reason I'm even > considering documenting it is for use with SOAP. I don't think it's > useful to you here. So would say that "side effects" in the server (e.g. a service starting or stopping) as a legitimate consequence of a PUT? Thanks, Duncan
On Mon, Dec 16, 2002 at 04:11:29PM +0100, Duncan Wilcox wrote: > > SET is PUT plus a hook to a processing model. The only reason I'm even > > considering documenting it is for use with SOAP. I don't think it's > > useful to you here. > > So would say that "side effects" in the server (e.g. a service starting or > stopping) as a legitimate consequence of a PUT? Definitely, but I'd caution that it's best practice with PUT to restrict the scope of the the side-effects to those specifically request by the message. i.e. to "start a service", use something like; PUT "on" to /my-service/run-status rather than having it be a "surprise" consequence of doing something else with PUT, like; PUT "My Service" to /my-service/name IMO, it makes better use of the HTTP contract, so is more visible to intermediaries. But if doing doing it that way is too much of a pain, no biggie; there's no rule saying PUT side effects have to be limited to the resource being interacted with. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
> Mark Baker wrote: > > SET is PUT plus a hook to a processing model. The only reason > I'm even considering documenting it is for use with SOAP. Could you explain why this would be so specific to SOAP? My understanding was that "SET" would be a way of storing or updating a resource in a way that is not as document-centric as PUT. This would be useful even in a pure XML/HTTP context and not just with SOAP.
Hmm... and I thought that SET was the ability to update a resource without replacing the entire thing (as PUT does). Of course, now that I think about this some more, this would require some form of processing of the request to determine how to update the resource... which sounds like POST processing. I know differences between SET and PUT have been discussed, but what about the differences between SET and POST? The only thing I can think of is that SET allows the direct creation of a resource at a given URI, while POST does not. And I suppose that SET could always be implemented via PUT by providing sufficiently fine grained URIs to the sub-resource(s). Okay... so maybe there isn't a need for a SET after all. Within SOAP and similar RPC specs, use of a SET would make more sense since you would not have all of the URIs. Or do I just have SET all wrong? --- Seairth Jacobs seairth@... ----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> To: "Duncan Wilcox" <duncan@...>; "Mark Baker" <distobj@...> Cc: <rest-discuss@yahoogroups.com> Sent: Monday, December 16, 2002 10:42 AM Subject: Re: [rest-discuss] PUT vs. POST (vs. SET?) > > Mark Baker wrote: > > > > SET is PUT plus a hook to a processing model. The only reason > > I'm even considering documenting it is for use with SOAP. > > Could you explain why this would be so specific to SOAP? My > understanding was that "SET" would be a way of storing or updating > a resource in a way that is not as document-centric as PUT. > > This would be useful even in a pure XML/HTTP context and not just > with SOAP. > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
----- Original Message ----- From: "Duncan Cragg" <rest@...> To: <rest-discuss@yahoogroups.com> Sent: Monday, December 16, 2002 2:02 AM Subject: [rest-discuss] Time axis in GET: P2P and Media > Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis' > (i.e., as opposed to getting /all/ the data back as /soon/ as it's > requested)? Oh yes, definitely. This is what KnowNow does. In a somewhat proprietary way (meaning it isn't an RFC or fully header based) their system lets you 'get' past and future events for a resource via a query term 'do_max_age'. Larger positive numbers indicate older events - farther into the past. For example, I wrote a sample app that polls Amazon (via their XML over HTTP interface) to get popular sales items and post events to a messaging server. A simple client subscribes to this stream of events using a 'max_age' to only get recent events. It's an IE5+ app, but its a 'live events in the browser' thing... http://www.topiczero.com:8000/kn_apps/amazonpop/ > > Example 1. Using HTTP/1.1 as a P2P protocol - the search for the > Resource could take some time, so either the Response takes a minute and > keeps the Request open (risking proxy timeout), or the line is 'pinged' > with void chunks while the peer is waiting. (GET > http://p2psystem/britney32541) It doesn't keep the Request open, it keeps the connection open. If a Response could be sent on a separate connection, then you wouldn't risk proxy timeouts. Adding some way to correlate request message and response message is an increase in complexity but it pays of in increased functionality. This list discussed ways to do the correlation (and provide callback location in the request, etc.) sometime in the past... I'm interested in pursuing the p2p angle with pure http. I've looked at Gnutella & I see some obvious ways to use GET for much of the node discovery and searching aspects - but I'm not sure what aspects of the behavior of Gnutella are important to preserve. I need to frame these questions & ask LucasG/etc. on the decentralization list... sometime. > > Example 2. Using HTTP/1.1 as a media streaming protocol: there is > /never/ any content length - the channel just goes on and on, sending > chunks... (GET http://britney-radio/) > Yes, that would work too. > Example 3. The Resource being fetched is not a simple file, but comes > from a user interface (GET > http://turing-test/is-it-britney?favourite+colour) > Huh? > Example 4. The Resource is a user typing into a chat field at random > times (GET http://britney-oracle/what-she-says-now) > If the 'what-she-says-now' has state of what she said in the past N minutes, then doing a GET for a snapshot would work. But if it is a buffer that gets cleared out pretty fast, doing a GET would result in getting from an empty buffer. It's easy to model the chat session as a resource and get message. Once again, see KnowNow's stuff.
Mark Baker wrote: > On Mon, Dec 16, 2002 at 11:03:15AM +0100, Duncan Wilcox wrote: > >>Browsing around for inspiration, I stepped into Mark Baker's article on >>PUT vs. SET: >> >>http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put >> >>If I get this right, if PUTting a document has side effects, then PUT >>isn't the right method to use, you should be using a (to be proposed) >>SET method. >> >>I'm currently updating profile cofniguration and status via PUT, would >>the use of SET be more appropriate? (the clients to this interface >>probably wouldn't be browsers) > > > SET is PUT plus a hook to a processing model. The only reason I'm even > considering documenting it is for use with SOAP. I don't think it's > useful to you here. Is there a reason not to just hook the processing off of a PUT with content-type: application/soap+xml? -joe -- http://BitWorking.org http://WellFormedWeb.org
On Mon, Dec 16, 2002 at 10:42:41AM -0500, Jeffrey Winter wrote: > > Mark Baker wrote: > > > > SET is PUT plus a hook to a processing model. The only reason > > I'm even considering documenting it is for use with SOAP. > > Could you explain why this would be so specific to SOAP? My > understanding was that "SET" would be a way of storing or updating > a resource in a way that is not as document-centric as PUT. That's right. I'm just saying that SOAP requires it, which provides the impetus necessary for me to proceed with it. For regular XML/HTTP use, you can always manage to get by with just PUT. > This would be useful even in a pure XML/HTTP context and not just > with SOAP. Sure. Joe asks; > Is there a reason not to just hook the processing off > of a PUT with content-type: application/soap+xml? The media type is just opaque representation metadata that is also just "stored", as far as PUT is concerned; it isn't used for dispatch at all. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
On Mon, Dec 16, 2002 at 12:44:42PM -0500, Seairth Jacobs wrote: > Or do I just have SET all wrong? Yep. 8-) SET is just PUT with the added capability of being able to process the representation prior to the "store" happening. i.e. you could do; PUT "1" > http://example.org/foo1 then invoke GET and see; "one" MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
From: "Mark Baker" <distobj@...> > > On Mon, Dec 16, 2002 at 12:44:42PM -0500, Seairth Jacobs wrote: > > Or do I just have SET all wrong? > > Yep. 8-) > > SET is just PUT with the added capability of being able to process > the representation prior to the "store" happening. > > i.e. you could do; > > PUT "1" > http://example.org/foo1 > > then invoke GET and see; > > "one" Other than the fact that PUT/SET can create a mapping between URI and resource, why couldn't your example be done with a POST? --- Seairth Jacobs seairth@...
On Mon, Dec 16, 2002 at 02:33:55PM -0500, Seairth Jacobs wrote: > Other than the fact that PUT/SET can create a mapping between URI and > resource, why couldn't your example be done with a POST? Because a valid response from a GET after the POST could be "two", "three", or "j234q;il2j4oj34dq;324dq234". With POST, you *never* have an expectation about the state of the resource after it's been invoked (other than you should assume that it's changed). With PUT/SET, you *always* do. That's the dividing line. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Paul Prescod wrote: > electronic business (UBL, ebXML, xBRL) as distinguished from web > services. Speaking of ebXML, last week I attended a meeting of UN/CEFACT, one of the parent orgs. They originally intended ebXML to be an implementation of their UN Modeling Methodology, which they intend to be a technology-neutral specification for electronic business collaborations. (Needless to say, the reality deviated somewhat from the intent, but the family resemblence remains.) Anyway, I mentioned that I wanted to develop a REST implementation. Last year, I got flamed as a traitor to ebXML for the same suggestion. This year, I got enthusiastic interest from people who knew what REST means. Now, I have no idea if and when I can afford the time to do it, but the different in attitude over a year was striking. I attribute it to good propaganda work. P.S. Paul, I had a side conversation with Duane Nickull who is now the official UNCEFACT rep to the W3C ws-architecture project, who mentioned your name and that you both live in Vancouver...
I've written a bit on workflow and hypermedia systems, and used BPEL4WS as my whipping boy. 8-) I haven't finished the Pick section yet since I'm waiting on an answer to a question about it, but the rest is mostly intact. All feedback is appreciated; http://www.markbaker.ca/2002/12/HypermediaWorkflow/ MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
> > Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis' > > (i.e., as opposed to getting /all/ the data back as /soon/ as it's > > requested)? > A simple client subscribes to this stream of events using a 'max_age' to > only get recent events. It's an IE5+ app, but its a 'live events in the > browser' thing... So new events update the browser? Why don't all news services use it? Why, indeed, do we need the comparatively over-done and bloated HTTPEvents, even??!! Surely the semantics of chunks like 'part 1 of 10, part 2 of 10, ...' versus 'all current state, update to current state, update to current state' are so different that no normal browser would know what to do? There's nothing in the HTTP/1.1 spec that says what the semantics of chunking is, as far as I can see! > > Example 1. Using HTTP/1.1 as a P2P protocol - the search for the > > Resource could take some time, so either the Response takes a minute and > > keeps the Request open (risking proxy timeout), or the line is 'pinged' > > with void chunks while the peer is waiting. (GET > > http://p2psystem/britney32541) <http://p2psystem/britney32541%29> > It doesn't keep the Request open, it keeps the connection open. If a > Response could be sent on a separate connection, then you wouldn't risk > proxy timeouts. Adding some way to correlate request message and response > message is an increase in complexity but it pays of in increased > functionality. This list discussed ways to do the correlation (and provide > callback location in the request, etc.) sometime in the past... > > I'm interested in pursuing the p2p angle with pure http. I've looked at > Gnutella & I see some obvious ways to use GET for much of the node > discovery > and searching aspects - but I'm not sure what aspects of the behavior of > Gnutella are important to preserve. I need to frame these questions & ask > LucasG/etc. on the decentralization list... sometime. OK > > > > > Example 2. Using HTTP/1.1 as a media streaming protocol: there is > > /never/ any content length - the channel just goes on and on, sending > > chunks... (GET http://britney-radio/) <http://britney-radio/%29> > > > Yes, that would work too. OK > > > > Example 3. The Resource being fetched is not a simple file, but comes > > from a user interface (GET > > http://turing-test/is-it-britney?favourite+colour) > <http://turing-test/is-it-britney?favourite+colour%29> > > > Huh? I mean that you GET on my machine here, and I see your request and type something in for you to render on your browser!! There is a delay before I notice that you've requested my wisdom. I was just using it as a rather odd example of time-dependency or time-axis-in-GET. Sorry. Should've explained better. > > > Example 4. The Resource is a user typing into a chat field at random > > times (GET http://britney-oracle/what-she-says-now) > <http://britney-oracle/what-she-says-now%29> > > > If the 'what-she-says-now' has state of what she said in the past N > minutes, > then doing a GET for a snapshot would work. But if it is a buffer that > gets > cleared out pretty fast, doing a GET would result in getting from an empty > buffer. > It's easy to model the chat session as a resource and get message. Once > again, see KnowNow's stuff. > What I'm saying is, not the state in the past N minutes, but the state from the point the GET was received, onwards. So it would indeed be nothing at the time, and would be an HTTP/1.1 chunk per pearl of wisdom from then on, as it was cast. Would you be kind enough to elaborate a little on this (the what KnowNow does, chat part)? Again, chunking is just dividing up a single big data item, isn't it? Not for (a) 'time-staked' events or (b) updates to previously sent data. After all, there's no standard page update syntax (chunk number 7: "this line, and this line only, has changed") So, anyway, just 'cos KnowNow does it, doesn't mean it's pure as newly-laid snow to rest-discussers...... !! The poor reaction to my email either indicates it's OK and REST-assured, or everyone is shaking their heads in dismay... :-) Finally, assuming we can OK it with HTTP HQ, is such use of chunking to update state also cool with REST Centraal Kontrol?? MarkB? PaulP? Duncan Cragg
> Does that mean that I don't have to rely on content negotiation for > choosing the format of the response? So, it would be RESTful to have > those two URIs for example > > http://www.physicists.org/html/list-of-physicists > http://www.physicists.org/xml/list-of-physicists > > although the representations they return are > representations of the same resource (concept) and only differ > in the markup language used ? Those are two different resources. If a person wishes to identify the XML representation of a concept, an HTML response to that resource would not be a valid representation even though it may have essentially the same content. If the resource is a concept independent of representation format, then its URI must not have any aspect that is specific to the representation format. Having that aspect in the URI (as interpreted by the origin server) implies that the resource semantics includes the format. BTW, for server-contructed URI, there is no effective difference between query and path info -- both distinguish a resource. It is only when the URI is client-constructed (as in GET forms or ISINDEX or the old server-side image maps) that the client has any way to distinguish the non-query path as a resource, and even then the various URI with the query info tagged-onto the end identify separate resources. A resource is defined not by its implementation, but by a user's expectation of results from future actions on that resource. If two URI are expected to respond to GET differently, then they must identify different resources. ....Roy
----- Original Message ----- From: "Duncan Cragg" <rest@...> > Surely the semantics of chunks like 'part 1 of 10, part 2 of 10, ...' > versus 'all current state, update to current state, update to current > state' are so different that no normal browser would know what to do? > There's nothing in the HTTP/1.1 spec that says what the semantics of > chunking is, as far as I can see! Chunking has no app-level semantic - it is purely for transport optimization (streaming without knowing length in advance). The chunks could be arbitrarily resized by intermediaries & it would 'still work'.
----- Original Message ----- From: "Duncan Cragg" <rest@...> > So new events update the browser? Why don't all news services use it? Because uses don't sit in front of www.cnn.com and wait for news to happen. The frequency of events is way too low to be captivating for a human audience. Automation apps (aggregators, agents, etc), however, don't care.
On Wed, Dec 18, 2002 at 12:12:43AM +0000, Duncan Cragg wrote: > Finally, assuming we can OK it with HTTP HQ, is such use of chunking to > update state also cool with REST Centraal Kontrol?? MarkB? PaulP? You may have noticed that Roy just subscribed, so we have actual authority to appeal to now. 8-) My view is that chunking is a transfer issue; it's just a means of, well, chunking a stream into individual chunks. But that said, it's a good idea for the server to send chunks that are optimally sized for incremental processing/rendering to reduce effective latency as seen by the client application. This is what KnowNow does, as I understand it, where each chunk is an event notification. I have no problem with it whatsoever, though from an XML POV, it's slightly flawed because the composite stream (what you get when you concatenate all the chunks) is not well-formed XML because there's no "root container", like <event-stream> .. </event-stream>. But I'm ok with that. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Roy T. Fielding wrote:
>
> BTW, for server-contructed URI, there is no effective difference
> between query and path info -- both distinguish a resource. It is
> only when the URI is client-constructed (as in GET forms or ISINDEX
> or the old server-side image maps) that the client has any way to
> distinguish the non-query path as a resource, and even then the
> various URI with the query info tagged-onto the end identify separate
> resources.
2396 is not clear about that. It says:
"3.4. Query Component
The query component is a string of information to be interpreted by
the resource."
Paul Prescod
----- Original Message ----- From: "Mark Baker" <distobj@...> > This is what KnowNow does, as I understand it, where each chunk is an > event notification. I have no problem with it whatsoever, though from > an XML POV, it's slightly flawed because the composite stream (what you > get when you concatenate all the chunks) is not well-formed XML because > there's no "root container", like <event-stream> .. </event-stream>. > But I'm ok with that. Just grin & say they are 'xml fragments' and don't claim they are 'documents'. (I think Jabber is exactly the same - a stream of fragments. I don't know if they use a PI to separate the logical documents though)
> 2396 is not clear about that. It says: > > "3.4. Query Component > > The query component is a string of information to be interpreted by > the resource." Yes, but it doesn't say that the resource is identified by what comes before the query component. ....Roy
----- Original Message ----- From: "Duncan Cragg" <rest@...> > > > > Example 4. The Resource is a user typing into a chat field at random > > > times (GET http://britney-oracle/what-she-says-now) > > <http://britney-oracle/what-she-says-now%29> > > > > > If the 'what-she-says-now' has state of what she said in the past N > > minutes, > > then doing a GET for a snapshot would work. But if it is a buffer that > > gets > > cleared out pretty fast, doing a GET would result in getting from an empty > > buffer. > > It's easy to model the chat session as a resource and get message. Once > > again, see KnowNow's stuff. > > > > What I'm saying is, not the state in the past N minutes, but the state > from the point the GET was received, onwards. So it would indeed be > nothing at the time, and would be an HTTP/1.1 chunk per pearl of wisdom > from then on, as it was cast. > > Would you be kind enough to elaborate a little on this (the what KnowNow > does, chat part)? What KN does is provide a resource that is a set of past and future events. Using query terms the client can specify what range they would like - including 'all future events'. I think of it as a GET on the future. They have multiple types clients, including a JavaScript in the browser client. You can see a live example at http://www.topiczero.com:8000/kn_apps/amazonpop/ - its an example I wrote that monitors the top selling items on Amazon. The page listens to a particular topic for incoming events. There is an 'add comment' on the top right of the page & when a new comment shows up, I put it on the screen using IE5 nifty node.innerHTML stuff. > > So, anyway, just 'cos KnowNow does it, doesn't mean it's pure as > newly-laid snow to rest-discussers...... !! What KN does isn't always very RESTful but it is very useful.
On Tue, Dec 17, 2002 at 05:27:56PM -0800, S. Mike Dierken wrote: > Just grin & say they are 'xml fragments' and don't claim they are > 'documents'. > (I think Jabber is exactly the same - a stream of fragments. I don't know if > they use a PI to separate the logical documents though) That's it, over the course of a single (e.g.) client-to-server connection, two documents are exchanged over time, one sent fragment by fragment from the client to the server, and the other the in the other direction. No PIs are used for separation, but the chunking is at the 'whole element' level rather than the potentially more random transport-level. One advantage of a single document over time is that you're not instantiating a parser every time you receive an element. dj http://www.pipetree.com/qmacro
Mark Baker wrote:
>>Finally, assuming we can OK it with HTTP HQ, is such use of chunking to
>>update state also cool with REST Centraal Kontrol?? MarkB? PaulP?
>>
>>
>
>You may have noticed that Roy just subscribed, so we have actual
>authority to appeal to now. 8-)
>
>
Hi! Roy! Welcome to rest-discuss!
(I'm a newbie here, too (joined last week) so we can share
experiences... ;-)
So I suppose you actually just got tired of reading the list with
interleaved adverts on the website, huh?
Anyway, I hope you jump in and put us all straight from time to time....
>My view is that chunking is a transfer issue; it's just a means of,
>well, chunking a stream into individual chunks. But that said, it's a
>good idea for the server to send chunks that are optimally sized for
>incremental processing/rendering to reduce effective latency as seen by
>the client application.
>
Right, that's how I read the HTTP RFC.
>This is what KnowNow does, as I understand it, where each chunk is an
>event notification. I have no problem with it whatsoever, though from
>an XML POV, it's slightly flawed because the composite stream (what you
>get when you concatenate all the chunks) is not well-formed XML because
>there's no "root container", like <event-stream> .. </event-stream>.
>But I'm ok with that.
>
Well that's OK: just open the wrapping <event-stream> tag and forget to
close it! And use a stream parser.
Anyway - this gets to the core of the issue: that GET semantics are
different if you introduce the time-staking interpretation of chunks -
they cease to be just a transfer technology, and become timely events or
data updates. It's the difference between:
<Stuff>
<Big-Pile-Of-CDATA length="10000">
:
</Big-Pile-Of-CDATA>
<!-- end of chunk one-->
:
<Big-Pile-Of-CDATA length="10000">
:
</Big-Pile-Of-CDATA>
<!-- end of chunk two-->
</Stuff>
<!--EOT-->
And:
<event-stream>
<All-The-Data-In-One>
:
</All-The-Data-In-One>
<!-- end of chunk one-->
:
<!-- tum tee tum, twiddle fingers -->
:
<Update>
<insert at-elem-number="12">
<new-piece att="val">
</insert>
</Update>
<!-- end of chunk two-->
:
:
<!-- still no close event-stream tag... -->
As discussed before:
http://groups.yahoo.com/group/rest-discuss/message/600
http://groups.yahoo.com/group/rest-discuss/message/656
So if the latter, open-ended XML and the use of chunking
in this way is OK, then *great* - we can dispose of
MONITOR/HTTPEvents!!! :-)
Did the list reach a consensus back then? It seems,
judging by responses so far, that KnowNow and
open, dangling, time-chunk-semantics, 'subscriber'
GETs are OK.
But what about the cacheing issues? You need
intermediaries to understand the difference between
'this is /all/ the data, in chunks' and 'this /chunk/ is all
the data and subsequent chunks keep it up-to-date'.
Which requires a little too much understanding of
some random update syntax by dumb proxies... Not that
I object to intermediaries being replaced by first-class
peers: at least they'd be more use to us.
Roy?!!! :-)
Duncan Cragg
Roy T. Fielding wrote, > > 2396 is not clear about that. It says: > > > > "3.4. Query Component > > > > The query component is a string of information to be interpreted > > by the resource." > > Yes, but it doesn't say that the resource is identified by what comes > before the query component. True, but puzzling. If the resource is identified by the whole URI then, 1. http://www.example.com/foo?bar and, 2. http://www.example.com/foo?baz identify two distinct resources R1 and R2, in which case there doesn't seem to be very much "interpretation" to be done: "?bar" is encoded into the identifier for R1 and "?baz" is encoded into the identifier for R2, so any further inspection of the query component by either resource would be redundant. Whatever the currently preferred understanding of the relationship between URIs, resources and representations, 3.4 only really makes any sense if we treat the prefix, http://www.example.com/foo as identifying a _process_ and the query component as specifying an argument to be provided to that process. But that pretty clearly isn't your currently preferred understanding, which, even if it's not strictly speaking inconsistent with 3.4, certainly seems to be in tension with it. So maybe 3.4 needs tweaking? Cheers, Miles
Mark Baker wrote: > I've written a bit on workflow and hypermedia systems, and used BPEL4WS > as my whipping boy. 8-) > All feedback is appreciated; > > http://www.markbaker.ca/2002/12/HypermediaWorkflow/ Mark, I really appreciate where you and Paul are going with all of these excursions into "hypermedia as the engine of application state". I'll study your latest more deeply when I get time, but here are some immediate responses: 1. I really like this part: "a critical point is that the choreography application model requires that implementation details (the business process rules) be exposed as part of the interface. This will make them very brittle should they need to change, as well as drastically increasing the coordination costs of implementing a multi-party process (since the more parties that are in the process, the more agreement that will need to be made). By keeping process implementation details hidden behind the interface, none of those problems exist." Incidentally, in UN/CEFACT we have proposed as a hypothesis that all multi-party business scenarios can be decomposed into sets of two- party interactions with all coordination activities being the *internal* responsibility of any party with dependent commitments with multiple other parties. We have a set of test cases to explore: (a) all-or-nothing orders with dependent requirements from multiple parties (b) domestic and international shipping involving many parties (c) distributed meeting-time negotiation. (a) was completed at a meeting in Washington DC last week. Documentation is in process. (b) domestic shipping was sketched out informally at the same meeting. (c) remains to be done. Other test cases are welcome. 2. As a corollary, I am very skeptical of the examples that BPEL et al use for their multi-party business scenarios. They seem to tailor them to demonstrate their multi-party choreography capabilities, rather than figuring out what is the best way to business. As you write, the number of parties in the process, the more agreements need to be made, and lawyers will be involved in each agreement where money is riding on the wire. 3. I am very skeptical in general that the flavor of procedural workflow that is used for internal document-shuffling is suited to external business conversations. RosettaNet tried it and abandoned it - exceptions got too tangled. There is another style of workflow (conversational or action-workflow pioneered by Winograd et al) that is suitable for external conversations, but that's not the kind of software products that IBM et al want to repurpose. Procedural workflow assumes command-and-control. Wrong assumption. 4. I also like that you differentiate between internal implementation and external interface. BPEL says they handle both, and I haven't studied their stuff in enough detail yet, but they don't seem to differentiate clearly in their examples. Thanks again for the stimulating article, Bob Haugen
Mark, Interesting read. I have a comment about the section on "Flow": Is there really any need at all to declare that two services can be called in parallel, even in the way that you've outlined? It would seem to go against the very nature of the web to *not* allow two calls to be made in parallel, regardless of how it was declared. In the example you gave, if the schema of the document that is POST-ed to the "Bank" partner required elements that would be returned from calls to the "Seller" and "Shipper" partners, wouldn't that be sufficient to, in essense, declare what the required flow would be? Thanks.
On Wed, Dec 18, 2002 at 03:58:33PM -0000, bhaugen32 <bhaugen32@...> wrote: > 1. I really like this part: > "a critical point is that the choreography application model requires > that implementation details (the business process rules) be exposed > as part of the interface. This will make them very brittle should > they need to change, as well as drastically increasing the > coordination costs of implementing a multi-party process (since the > more parties that are in the process, the more agreement that will > need to be made). By keeping process implementation details hidden > behind the interface, none of those problems exist." > > Incidentally, in UN/CEFACT we have proposed as a hypothesis that all > multi-party business scenarios can be decomposed into sets of two- > party interactions with all coordination activities being the > *internal* responsibility of any party with dependent commitments > with multiple other parties. I'm confident that a large number of scenarios can be so reduced, but I'm not sure that all can. For example, scenarios with fan-out (pub/sub) or fan-in (multi-party rendezvous). But perhaps you mean that even fan-* can be abstracted as a two-party scenario, which is possible since some party (likely third party) has to take responsibility for providing the fan-in or fan-out point. Have to think on that one ... I agree with all your other observations too. BTW, I meant to mention this in the paper; http://www.ebpml.org/bpel4ws.htm which I don't agree with completely, but it has some good observations, including; 'However, "BeePEL" authors do not yet understand the concepts of "Business Transactions" and its necessity for business state alignment. They keep talking about callbacks and shy away from assembling messages into meaningful transactions which when successful guarantee state alignment: [...]' MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Hi Jeff, On Wed, Dec 18, 2002 at 11:02:54AM -0500, Jeffrey Winter wrote: > Mark, > > Interesting read. > > I have a comment about the section on "Flow": > > Is there really any need at all to declare that two services > can be called in parallel, even in the way that you've outlined? It > would seem to go against the very nature of the web to *not* allow > two calls to be made in parallel, regardless of how it was declared. > > In the example you gave, if the schema of the document that is > POST-ed to the "Bank" partner required elements that would be returned > from calls to the "Seller" and "Shipper" partners, wouldn't that be > sufficient to, in essense, declare what the required flow would be? I didn't really understand their scenario, so can't respond to the details of it. But I'd say that any time a URI is exposed, that it's automatically a valid state transition. If it's exposed alongside other URIs, then all of those URIs can be followed concurrently (analogous to opening up a new browser window for each). The point I was trying to make was that if there aren't paths through the application graph which can be followed concurrently, then the URIs to that path should not be exposed until the predecessor paths are completed. I think some diagrams would help, but I haven't gotten to that. Hmm, I guess the "dot" stuff I set up for the RESTwiki could help with that. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
S. Mike Dierken wrote: > ----- Original Message ----- > From: "Mark Baker" <distobj@...> > >>This is what KnowNow does, as I understand it, where each chunk is an >>event notification. I have no problem with it whatsoever, though from >>an XML POV, it's slightly flawed because the composite stream (what you >>get when you concatenate all the chunks) is not well-formed XML because >>there's no "root container", like <event-stream> .. </event-stream>. >>But I'm ok with that. > > > Just grin & say they are 'xml fragments' and don't claim they are > 'documents'. > (I think Jabber is exactly the same - a stream of fragments. I don't know if > they use a PI to separate the logical documents though) If you want the XML chunks to be valid XML documents, you can separate one from another with a control character that is illegal in XML. I've seen form feed (U+000C) suggested. Jim
Miles Sabin wrote: > Ramin Firoozye wrote, > > >I talked to Amazon folks about this when they first came out with the > >service. They support doing XSLT on the server (to my amazement -- it > >opens up a whole can of worms I don't think they considered). No > >support for installing extension functions on their servers, but with > >the document() function, you can call external services via http > >requests. > > > They allow arbitrary user-supplied stylesheets to make arbitrary > outgoing HTTP requests from their servers???!!!! > > Wow! That's an accident waiting to happen ... who needs a bunch of IRC > zombies when you can hijack Amazons boxes for a DDoS. > > Paul, I suggest that until they fix it you _don't_ flag it up as an > exemplar. Do you have a contact at Amazon? Hijacking Amazon's boxes is not a "DDoS". You can at best launch one attack per connection from your box to Amazon's. All you've done is insert Amazon as an intermediary. You could have done the same with Babelfish. I'm not going to bug Amazon about this issue until I understand the danger myself. Babelfish has been doing GETs-on-my-behalf for several years. I can see how the feature could be very useful for combinign multiple information sources. Paul Prescod
Paul Prescod wrote, > Hijacking Amazon's boxes is not a "DDoS". You can at best launch one > attack per connection from your box to Amazon's. All you've done is > insert Amazon as an intermediary. The stylesheet might contain multiple uses of, or a loop over, the document function. That means that a single malicious client -> Amazon request could result in multiple Amazon -> victim requests. IOW Amazon executing the stylesheet could act as an amplifier (cp. smurf/fraggle). Not to mention the fact that Amazon has a much fatter pipe than your average script kiddie. > You could have done the same with Babelfish. I'm not going to bug > Amazon about this issue until I understand the danger myself. > Babelfish has been doing GETs-on-my-behalf for several years. I don't think you can persuade Babelfish to do multiple GETs on your behalf with just one GET of your own. If there's no amplification there's much less danger. > I can see how the feature could be very useful for combinign multiple > information sources. Of course it's useful. But it's a sharp tool: use with care. Cheers, Miles
Hi Folks,
You are invited to participate in the collaborative development of a
distributed registry technology.
We have created a list (distributed-registry) for discussion of this
topic. To subscribe to the list send an empty email to:
distributed-registry-subscribe@yahoogroups.com
Here is a description of the purpose of a distributed registry:
A Web service registry provides information about what services do, and
how they are used. Today's Web service registries (e.g., UDDI and ebXML)
are implemented as centralized repositories. That is, all services store
their service descriptions within a single, or a small number of
registries. The purpose of this effort is to develop a concrete,
implementable architecture for a highly distributed registry. The notion
is that each Web service defines their own registry - comprised of the
collection of documents that describes the service.
We have created a Web page which
- lists the design goals for a distributed registry, and
- proposes an architecture
Here's the URL to the Web page:
http://www.xfront.com/dist-reg/distributed-registry.html
We invite you to participate in the development of this technology.
Thanks!
Roger L. Costello and David B. Jacobs
Mark Baker wrote: > bhaugen32 <bhaugen32@y...> wrote: > > in UN/CEFACT we have proposed as a hypothesis that all > > multi-party business scenarios can be decomposed into sets of two- > > party interactions with all coordination activities being the > > *internal* responsibility of any party with dependent commitments > > with multiple other parties. > > I'm confident that a large number of scenarios can be so reduced, but > I'm not sure that all can. Well, I said "hypothesis". But so far it's holding up pretty well, and as you wrote it gets a lot more expensive if and when it doesn't hold up. > For example, scenarios with fan-out > (pub/sub) or fan-in (multi-party rendezvous). But perhaps you mean that > even fan-* can be abstracted as a two-party scenario, which is possible > since some party (likely third party) has to take responsibility for > providing the fan-in or fan-out point. Have to think on that one ... Can you tell me a story about each of those scenarios so I can get in in my mind better? Preferably a business scenario, since that is all I would claim, and preferably identifying the participants even if hypothetically by class? And just to be clear, I'm not saying that multiple parties are not involved in some way, just that only two parties need to interact at a time, and all coordination between more than two parties is done as the internal responsibility of parties with multiple commitments with multiple other parties. Here's another version of the hypothesis: http://www.collaxa.com/news.blog.html#90008925 <quote> Tuesday, December 03, 2002 Multi-Party Business Transactions - UNCEFACT White Papers - multiple parties were involved in the whole scenario, but they interacted in pairs and all coordination between dependent commitments was the internal and private responsibility of only one party. Here are some of the reasons why: simplicity, accountability as [who] agreed to do exactly what for exactly whom, ...the more parties to a contract, the more parties have to agree on everything, ...economic commitments and events involve two and only two parties, security - need-to-know. Trading partners need to know about each other, but they rarely need to know what other partners each may have, and in many cases should not know even that others exist. Decoupling to avoid ripples of change - if parties A and B change their procedures, it may not affect parties C and D, unless all four parties are bound into the same contract. Collaxa's Take: +1. This design pattern also known as a star interaction pattern is very important for building "self healing" and adaptable distributed applications: managing exception is easier in a pair conversations. The same is true for version control. Posted 11:32 AM by Edwin Khodabakchian </quote>
On Wed, Dec 18, 2002 at 10:30:25PM -0000, bhaugen32 <bhaugen32@...> wrote: > Can you tell me a story about each of those scenarios so I can get in > in my mind better? Preferably a business scenario, since that is all > I would claim, and preferably identifying the participants even if > hypothetically by class? An example of both fan-out and fan-in would be me invoking GET on a URI identifying "my current net worth", which may not be stored in one place. So the GET gets fanned out to every party that I have any assets with, and then responses then fan-in back. The parties there would be me, the parties holding my assets, plus an intermediary party who can aggregate that information (optionally - it could just be software under my control, or software that one of the other parties uses). That's a bit of a weak fan-in example, since it's plain-vanilla responses to a GET request (at least after the intermediary). But you could imagine responses being disconnected (via explicit correlation rather than implicit correlation via the connection) from requests. > Collaxa's Take: +1. This design pattern also known as a star > interaction pattern is very important for building "self healing" and > adaptable distributed applications: managing exception is easier in a > pair conversations. The same is true for version control. > Posted 11:32 AM by Edwin Khodabakchian That makes some sense. I haven't given it much thought. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Mark Baker wrote: > An example of both fan-out and fan-in would be me invoking GET on a URI > identifying "my current net worth", which may not be stored in one > place. So the GET gets fanned out to every party that I have any assets > with, and then responses then fan-in back. The parties there would be > me, the parties holding my assets, plus an intermediary party who can > aggregate that information (optionally - it could just be software under > my control, or software that one of the other parties uses). Where in that scenario do multiple parties actually interact? I read: * you interact with intermediary * intermediary interacts with each asset-holder individually * none of the asset-holders needs to even know about the others * intermediary coordinates (sums) results What am I missing? > That's a bit of a weak fan-in example, since it's plain-vanilla > responses to a GET request (at least after the intermediary). But you > could imagine responses being disconnected (via explicit correlation > rather than implicit correlation via the connection) from requests. How would this change the situation so that more than two parties would need to interact at a time? -Bob Haugen
On Thu, Dec 19, 2002 at 11:56:10AM -0000, bhaugen32 <bhaugen32@...> wrote: > Where in that scenario do multiple parties actually interact? > I read: > * you interact with intermediary > * intermediary interacts with each asset-holder individually > * none of the asset-holders needs to even know about the others > * intermediary coordinates (sums) results > What am I missing? The intermediary could be an independant party. Did you have some specific form of multi-party interaction that you were looking for? > > That's a bit of a weak fan-in example, since it's plain-vanilla > > responses to a GET request (at least after the intermediary). But > you > > could imagine responses being disconnected (via explicit correlation > > rather than implicit correlation via the connection) from requests. > > How would this change the situation so that more than two parties > would need to interact at a time? It wouldn't, it would just better illustrate fan-in. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Mark Baker wrote: > The intermediary could be an independant party. But the interactions are still pairwise, no? * You<->intermediary * intermediary<->each asset-holder > Did you have some specific form of multi-party interaction that you > were looking for? Not really. Trying to cover the waterfront of business interactions. I'm ready to admit exceptions to the pairwise hypothesis, but do want to catalog them and figure out the costs as far as possible for survey-level depth-of-thinking.
On Thu, Dec 19, 2002 at 04:11:04PM -0000, bhaugen32 <bhaugen32@...> wrote: > Mark Baker wrote: > > The intermediary could be an independant party. > > But the interactions are still pairwise, no? > * You<->intermediary > * intermediary<->each asset-holder Yah, I was just giving an example of fan-out and fan-in, not suggesting that this particular example couldn't be reduced to a series of pairwise interactions. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
*whew* now I can get rid of a draft response that says the same thing (only
yours illustrated it better). I had an additional thought on this...
What if we were to let the server report back to the client what it thinks
constitutes the part that identifies it and the part that doesn't? For
instance, suppose you were to do a GET on:
http://sample.org/foo?bar
When getting the response, the server returned headers something like:
Location: http://sample.org/foo
Query: bar
Varies: Query
In this case, it is saying that the value of Location is the URI that
identifies the resource. The query string is stored in another header so
that the Varies header can indicate it for caching purposes, etc.
Of course, my understanding of HTTP headers has only recently into Varies,
Location, etc., so this may not be an appropriate way of handling this.
Just a thought...
---
Seairth Jacobs
seairth@...
----- Original Message -----
From: "Miles Sabin" <miles@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Wednesday, December 18, 2002 5:00 AM
Subject: Re: [rest-discuss] Representation format as part of URIs?
> Roy T. Fielding wrote,
> > > 2396 is not clear about that. It says:
> > >
> > > "3.4. Query Component
> > >
> > > The query component is a string of information to be interpreted
> > > by the resource."
> >
> > Yes, but it doesn't say that the resource is identified by what comes
> > before the query component.
>
> True, but puzzling.
>
> If the resource is identified by the whole URI then,
>
> 1. http://www.example.com/foo?bar
>
> and,
>
> 2. http://www.example.com/foo?baz
>
> identify two distinct resources R1 and R2, in which case there doesn't
> seem to be very much "interpretation" to be done: "?bar" is encoded
> into the identifier for R1 and "?baz" is encoded into the identifier
> for R2, so any further inspection of the query component by either
> resource would be redundant.
>
> Whatever the currently preferred understanding of the relationship
> between URIs, resources and representations, 3.4 only really makes any
> sense if we treat the prefix,
>
> http://www.example.com/foo
>
> as identifying a _process_ and the query component as specifying an
> argument to be provided to that process.
>
> But that pretty clearly isn't your currently preferred understanding,
> which, even if it's not strictly speaking inconsistent with 3.4,
> certainly seems to be in tension with it. So maybe 3.4 needs tweaking?
>
> Cheers,
>
>
> Miles
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
I have no problem whatsoever with people making toolkits that make it easier to program in the REST style. I've got my own little toolkit that I use for simple Python projects where Zope etc. are overkill. But here is where I get nervous: a toolkit that helps people use HTTP as it was designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP toolkit than the ones that exist, but it is still an HTTP toolkit. Phil's example code is a perfect example of using HTTP right. I won't argue if Phil calls it a REST toolkit but I don't see a clear boundary between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit strays from REST it is probably just a misunderstanding by the toolkit's author and we should probably work with them to correct it. Also, some people probably think that REST toolkit would embed a bunch of XML smarts. This stems from the confusion that REST is about using XML over HTTP. I don't think Phil has this confusion but I bet many people asking for REST toolkits do! Paul Prescod
Paul Prescod wrote: >I have no problem whatsoever with people making toolkits that make it >easier to program in the REST style. I've got my own little toolkit that >I use for simple Python projects where Zope etc. are overkill. But here >is where I get nervous: a toolkit that helps people use HTTP as it was >designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP >toolkit than the ones that exist, but it is still an HTTP toolkit. >Phil's example code is a perfect example of using HTTP right. I won't >argue if Phil calls it a REST toolkit but I don't see a clear boundary >between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit >strays from REST it is probably just a misunderstanding by the toolkit's >author and we should probably work with them to correct it. > I agree. But given existing bad habits and the lack of understanding of what REST really is (protocol vs style), I think "RESTful HTTP toolkit" or "REST-compliant HTTP toolkit" would be better terminology. --Chuck > >Also, some people probably think that REST toolkit would embed a bunch >of XML smarts. This stems from the confusion that REST is about using >XML over HTTP. I don't think Phil has this confusion but I bet many >people asking for REST toolkits do! > > Paul Prescod > > > >To unsubscribe from this group, send an email to: >rest-discuss-unsubscribe@yahoogroups.com > > > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
From: "Chuck Hinson" <cmhinson@...> > > I agree. But given existing bad habits and the lack of understanding of > what REST really is (protocol vs style), I think "RESTful HTTP toolkit" > or "REST-compliant HTTP toolkit" would be better terminology. I would suggest something like "REST-oriented" instead of "REST-compliant". I'm afraid that people would interpret "compliant" to mean "if the toolkit allows me to do it, then it is RESTful", which we certainly don't want people thinking. --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Mike Beedle" <beedlem@...> > > b) that these tools would give the developer > facilities to interact with other architectural > services like logging, persistence, messaging, > etc.; out of the box If you are a java programmer, I'd recommend Tomcat (Servlet engine) or JBoss (J2EE/EJB/JDBC/JMS/log4j/etc.). There are some toolkits in the J2EE arena that I suspect are not very REST aligned (like struts, but I don't want to say anything negative without real investigation) but if you have read the 'REST for Dummies' book and 'REST Zen in 27.3 days' (what? nobody has written those yet?) you should be fine with these powerful tools. The toolkit that I want is a client rather than a server - I'm alreay very familiar with the server environments available and they work for me just fine. The java based clients feel too 'protocol' level though. I suppose all I really want is a set of really good Java classes for MIME packaged content (including multi-part, with XML support, etc.) > > In other words, REST-specific tools in programming > languages that unlike the tools you list above, > would greatly expedite the development of > applications using the REST style. REST is more about good design than about specific programming. Just as with an RDBMS and SQL, regardless of the ease or completeness of the tools and servers, you can still create the query from hell, or have tables that are not normalized enough (or too normalized), or poor queries, and so on. A book showing good design and good queries will do more for SQL/RDBMS than a toolkit or API. Some things - like connection pooling and authentication - definitely make sense for language and API and language level toolkits.
> But that pretty clearly isn't your currently preferred understanding, > which, even if it's not strictly speaking inconsistent with 3.4, > certainly seems to be in tension with it. So maybe 3.4 needs tweaking? That's already on the issues list due to a couple other issues. ....Roy
I would just say "it's REST" and leave it at that. Afterall, you don't say that your house is "Victorian-compliant", "Victorian-oriented", although you might say it's "Craftsman-style". Me, I live in a Victorian. Walden ----- Original Message ----- From: "Seairth Jacobs" <seairth@...> To: "rest-discuss" <rest-discuss@yahoogroups.com> Sent: Thursday, December 19, 2002 3:45 PM Subject: Re: [rest-discuss] REST toolkit > From: "Chuck Hinson" <cmhinson@...> > > > > I agree. But given existing bad habits and the lack of understanding of > > what REST really is (protocol vs style), I think "RESTful HTTP toolkit" > > or "REST-compliant HTTP toolkit" would be better terminology. > > I would suggest something like "REST-oriented" instead of "REST-compliant". > I'm afraid that people would interpret "compliant" to mean "if the toolkit > allows me to do it, then it is RESTful", which we certainly don't want > people thinking. > > --- > Seairth Jacobs > seairth@... > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
On 12/19/2002 at 12:01 PM Paul Prescod wrote: >I have no problem whatsoever with people making toolkits that make it >easier to program in the REST style. I've got my own little toolkit that >I use for simple Python projects where Zope etc. are overkill. But here >is where I get nervous: a toolkit that helps people use HTTP as it was >designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP >toolkit than the ones that exist, but it is still an HTTP toolkit. >Phil's example code is a perfect example of using HTTP right. I won't >argue if Phil calls it a REST toolkit but I don't see a clear boundary >between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit >strays from REST it is probably just a misunderstanding by the toolkit's >author and we should probably work with them to correct it. I think a REST advocacy group is a great idea in theory, but I fear it wouldn't accomplish much in the real world without a lot of very patient and persuasive advocates. Most developers don't seem to care that much that their software doesn't work according to these abstract principles - they're trying to get work done in the real world. For example, the apache tomcat servlet engine breaks REST in at least one way. Just like in apache httpd, you can associate error pages with http error response codes to present the user with something more elegant and site-specific than the generic server-generated error content (the error-page element of the web.xml deployment descriptor). Unlike apache httpd, when tomcat returns that error content, it attaches a status code of 200 instead of the original error code! Thus, 404 responses aren't noted as such by search engines, proxy servers, et. al. because they're rewritten as 200 responses. I've been trying for days now to get the tomcat developers to acknowledge the bug, but so far they've ignored it. (If anyone wants to vote for this bug, it's http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406) It would seem that the developers either don't agree that it's a bug, or don't think it's a bug that's worth fixing. Either way, I'm not sure how to proceed. Another example might be apache struts. Struts heavily uses the RequestDispatcher servlet api to internally forward requests to different components. In and of itself that's not a bad thing, but struts uses it to such a degree that the "URL" of a given page and the contents of that page may have no relation to one another. It also seems to encourage developers to use the HttpSession object to store conversational state, which is problematic from a REST point of view. Fixing struts to be RESTful would require a serious amount of work, and I guess I doubt that the developers could be convinced that it would be a worthwhile investment. (which is very much too bad, since struts seems to be very popular as a webapp infrastructure.) Any suggestions for addressing either these specific instances or the general problem? - donald
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | Any suggestions for addressing either these specific instances or the | general problem? One of the first things we'll have to do is fix browsers to be more RESTful. For instance, they only GET and POST w/ ease right now. That is one of the reasons Struts works the way it does. It must work with its clients. A big gain for REST will come when XForms arrives. I hope the actions of PUT and DELETE will work with XForms. If so, browsers will become much more capable to work in RESTful environments. Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+A0b2Nx3GJTf/82URAt3/AJ0dVsm8ih/YSzFNKpF76aZYHhIE1ACfZTBp qcinWtEzidytEKJgCUIbLVw= =TexD -----END PGP SIGNATURE-----
From: "Donald Ball" <dball@...> > > Most developers don't seem to care that much that > their software doesn't work according to these abstract principles - > they're trying to get work done in the real world. If anything, I think that most developers are not aware of those principals. The "bug" in tomcat may be more of an indication that its developers are not fully aware of those principals rather than being aware of them and choosing to ignore them. To imply that working according to these abstract principles means one cannot "get work done in the real world" is just plain wrong. That would be equatable to saying you don't care much about design patterns in programming becuase you need to get work done in the real world. --- Seairth Jacobs seairth@...
----- Original Message ----- From: "Seairth Jacobs" <seairth@...> > The "bug" in tomcat may be more of an indication that its developers are not > fully aware of those principals rather than being aware of them and choosing > to ignore them. I vaguely remember looking into that & seeing a dependency on another component somewhere that broke things when a non-200 response code was present. But I might be mis-remembering it. Also, MS's Internet Explorer does a handy job of hiding error pages with 'friendly error' pages - so developers that want control over look & feel are pushed toward using 200 OK for everything.
On 12/20/2002 at 1:45 PM Seairth Jacobs wrote: >From: "Donald Ball" <dball@...> >> >> Most developers don't seem to care that much that >> their software doesn't work according to these abstract principles - >> they're trying to get work done in the real world. > >If anything, I think that most developers are not aware of those >principals. >The "bug" in tomcat may be more of an indication that its developers are >not >fully aware of those principals rather than being aware of them and >choosing >to ignore them. To imply that working according to these abstract >principles means one cannot "get work done in the real world" is just plain >wrong. That would be equatable to saying you don't care much about design >patterns in programming becuase you need to get work done in the real >world. I don't mean to imply that working according to those abstract design principles means you can't get work done in the real world - I'm just trying (poorly?) to put myself in the shoes of the developers of non RESTful web infrastructures. In the case of jakarta struts, I don't know that the position is entirely indefensible. Would the developers get more payoff from refactoring struts to adhere to REST design principles, or from, I dunno, adding some new whizbang feature? Probably the latter, at least from the point of view of their employers. - donald
----- Original Message ----- From: "Donald Ball" <dball@...> > I don't mean to imply that working according to those abstract design > principles means you can't get work done in the real world - I'm just > trying (poorly?) to put myself in the shoes of the developers of non > RESTful web infrastructures. In the case of jakarta struts, I don't know > that the position is entirely indefensible. Would the developers get more > payoff from refactoring struts to adhere to REST design principles, or > from, I dunno, adding some new whizbang feature? Probably the latter, at > least from the point of view of their employers. > Another thing to consider in the case of Struts is that it is meant more for web-based user interface purposes than pure information access purposes. The existing technology and needs of user interface apps make it hard to apply REST principles or gain the benefits that a pure information based app typically gets. So, I think there are some things Struts could do to make apps built with it more capable, but I wouldn't push it too far since I believe the needs and goals are different.
----- Original Message ----- From: "S. Mike Dierken" <mdierken@...> To: <rest-discuss@yahoogroups.com> Sent: Friday, December 20, 2002 3:13 PM Subject: Re: [rest-discuss] REST toolkit > The > existing technology and needs of user interface apps make it hard to apply > REST principles or gain the benefits that a pure information based app > typically gets. This confused me, S. Mike. If REST is a distillation of what makes the current Web work, and the current web is largely if not entirely driven by browser-to- website interactions (where the browser is the UI), then why should it be "hard" to apply REST principals to that? Walden
Craig Johnson (via Udell) on meaningful URI and URI (de)construction by humans... lending more credence to the notion that URI should be (de)constructable. http://weblog.infoworld.com/udell/2002/12/20.html#a552 jb
----- Original Message ----- From: "Walden Mathews" <waldenm@...> > > > The > > existing technology and needs of user interface apps make it hard to apply > > REST principles or gain the benefits that a pure information based app > > typically gets. > > This confused me, S. Mike. If REST is a distillation of what makes the current > Web work, and the current web is largely if not entirely driven by browser-to- > website interactions (where the browser is the UI), then why should it be "hard" > to apply REST principals to that? Because the principles are generally ignored for short term gain. When they are not ignored, great things happen - that was the insight that generated the summary of the principles. REST is not a distillation of what is /popular/ but what worked well. For example, using Flash satisfies many user interface needs, but often does not employ the simple aspects of REST that most people recognize (hyperlinking). Java servlet based session IDs are a convenience for programmers, but a pain for usability - this continues to be popular even though it isn't close to being REST aware due to the fact that it does indeed solve certain problems. The existing tools - browsers, cookies, javascript, sessions, etc. etc. - solve real issues with human interface based applications at the cost of sometimes not being RESTful. Trying to bend existing tools and practices won't work in my opinion. I favor working on automation based applications for the application of REST - essentially the same problem space as SOAP based Web Services.
S. Mike Dierken wrote: > Also, MS's Internet Explorer does a handy job of hiding error > pages with 'friendly error' pages - so developers that want > control over look & feel are pushed toward using 200 OK > for everything. no offence intended, but this is bogus. http://www.google.com/search?q=internet+explorer+200+friendly http://www.oreillynet.com/cs/user/view/wlg/1983 http://support.microsoft.com/default.aspx?scid=KB;en-us;q294807 you can sniff the user-agent header and pad your response to >n bytes where n is an entry in internet explorer's registry area indexed on the reponse code. generalising, you can pad to >512 bytes and internet explorer will display the entity response you returned unmolested. YMMV. no doubt about it though, the 'user-friendly error' 'feature' is totally brain damaged (IMNSHO). thankfully they left a (quick/dirty/cheap) way for you to escape it. ATB, -vincent
I have recently been working on a REST interface for a set of services, exchanging mainly service configuration documents. In reading recent blogging about the power of unintended, unexpected use and combination of web resources (as opposed to contractualized RPC), it has occurred to me that I might be "limiting creativity" by how I handle documents. On the PUT of a service configuration expressed as XML, I currently extract the data I know about (or return an error), and store only the valid, known configuration. I remember reading on this list (if I'm not mistaken), that PUT should store the document as is, and you should be able to retrieve the unchanged document through a GET. I suspect that along with a reasonable path design, this is one of the keys to making a REST interface future proof and usable beyond the initial expectations. If this assumption is correct I guess I should fix my interface, however there different problems for different solutions: - always return an error if the document isn't strictly what I want (i.e. if the XML contains unexpected tags) - return an error only when the subset of the document I currently support isn't what I want, extract relevant part for service configuration purposes, store the whole document for a later GET The rationale for the first solution is to preserve the expectation that you will GET what you PUT, however it also seems to swing the interface towards a rigidly defined RPC direction. Solution 2 would be better, I guess it would allow the user to store her own extra tidbits without ever needing to let me know about it, but it doesn't seem to be very future proof in that I might want to use portions of the document structure for myself in later versions. In the specific case of configuration documents in XML, there could be conflict of tags, and I'd rather take a monastic approach to the use of XML namespaces (limit their use, that is). Ideas appreciated. Thanks, Duncan -- http://duncan.focuseek.com
Duncan Wilcox wrote: > I have recently been working on a REST interface for a set of services, > exchanging mainly service configuration documents. > > In reading recent blogging about the power of unintended, unexpected > use and combination of web resources (as opposed to contractualized > RPC), it has occurred to me that I might be "limiting creativity" by > how I handle documents. > > On the PUT of a service configuration expressed as XML, I currently > extract the data I know about (or return an error), and store only the > valid, known configuration. > > I remember reading on this list (if I'm not mistaken), that PUT should > store the document as is, and you should be able to retrieve the > unchanged document through a GET. > > I suspect that along with a reasonable path design, this is one of the > keys to making a REST interface future proof and usable beyond the > initial expectations. > > If this assumption is correct I guess I should fix my interface, > however there different problems for different solutions: > > - always return an error if the document isn't strictly what I want > (i.e. if the XML contains unexpected tags) > > - return an error only when the subset of the document I currently > support isn't what I want, extract relevant part for service > configuration purposes, store the whole document for a later GET > I took the second approach in the implementation of RESTLog. How that extensibility works is explained here: http://wellformedweb.org/RESTLog.cgi/17 > The rationale for the first solution is to preserve the expectation > that you will GET what you PUT, however it also seems to swing the > interface towards a rigidly defined RPC direction. > > Solution 2 would be better, I guess it would allow the user to store > her own extra tidbits without ever needing to let me know about it, but > it doesn't seem to be very future proof in that I might want to use > portions of the document structure for myself in later versions. In the > specific case of configuration documents in XML, there could be > conflict of tags, and I'd rather take a monastic approach to the use of > XML namespaces (limit their use, that is). In this case I am just re-using the work already done in using namespaces in RSS 1.0 and 2.0 which is fairly stable. YMMV. -joe -- http://BitWorking.org http://WellFormedWeb.org
> > I remember reading on this list (if I'm not mistaken), that PUT should > > store the document as is, and you should be able to retrieve the > > unchanged document through a GET. Reading that on this list doesn't make it true. This is not clear in the language of 2616, and so I question its status as "standard". Generally, resources, according to REST, are functions that map time to values, and there are no constraints in REST saying that resource values may only be changed via the HTTP interface. If someone can find, somewhere in the body of standards, clear language to the effect that the resource implementation is expected to store a PUT value in bit-literal form, and that a subsequent GET on a resource that has suffered a PUT at some time in its life is required to serve out bit-literal representations... If someone finds that, would they please give me a pointer? Walden
Chuck, Thanks for the reference to the Roy message. I see two issues here, worth separating. There is the notion of a resource capable of delivering out a variety of different representations at a single point in time, that variety being the space in which content negotiation may take place. There is another issue, closer to "equivalence" (which causes trouble in other areas as well, it seems. I PUT this representation to this URI, and it replaces any existing representations. That means that upon the completion of PUT, that resource has but one representation. But when we say "one representation", we're not also spelling out the rules for what would distinguish one from two. If characters are present, does case matter? ASCII or other? If the representation consists of a "bag" of things, does literality force an unintended ordering on that? And so on. When Roy says that 2616 "PUT" method specifies that PUT obliterates variance of representation, I believe the language of 2616 reasonably supports his assertion. If he were asserting that 2616 PUT method specifies literality, I'd have to say that my careful readings so far can't find that. There's another problem here, in that the great majority of web application developers don't have access to Roy to to his email conversations, and so those resources don't quality as part of the standard, unfortunately. We need to approach that problem with care, I think. Walden ----- Original Message ----- From: "Chuck Hinson" <cmhinson@...> To: "Walden Mathews" <waldenm@...> Sent: Tuesday, December 24, 2002 11:35 AM Subject: Re: [rest-discuss] Future proof > > > Walden Mathews wrote: > > >>>I remember reading on this list (if I'm not mistaken), that PUT should > >>>store the document as is, and you should be able to retrieve the > >>>unchanged document through a GET. > >>> > > > >Reading that on this list doesn't make it true. This is not clear in the > >language of 2616, and so I question its status as "standard". Generally, > >resources, according to REST, are functions that map time to values, > >and there are no constraints in REST saying that resource values may > >only be changed via the HTTP interface. > > > >If someone can find, somewhere in the body of standards, clear > >language to the effect that the resource implementation is expected to > >store a PUT value in bit-literal form, and that a subsequent GET on > >a resource that has suffered a PUT at some time in its life is required > >to serve out bit-literal representations... > > > It's not quite that limiting strict. The interpretation presented > earlier on this list was that given no intervening operations between a > PUT and a GET (and assuming no other mechanism changes the resource's > state), a GET should return the exact representation submitted by the > immediately previous PUT. Note, however, that once a representation > has been PUT, there's nothing that says the state of the resource can't > be changed by some other means. > > > > >If someone finds that, would they please give me a pointer? > > > > We can certainly argue about what the spec actually says vs what one or > more of it's authors intended . However, Roy Fielding has made at least > one statement[1] that I (and I believe others) interpret to mean what I > stated above. > > [1] http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html > > --Chuck > > >
However, Roy never answered to my response ([1]), so I really think we are far from fully understanding how PUT relates to GET. So far, I haven't seen a convincing argument why PUT can't be symmetric to GET (setting specific representations). However I agree that it's probably better to assign distinct URIs to each variant (making authoring of them more straightforward), but I fail to see where RFC2616 (as published!) requires this. Julian [1] <http://lists.w3.org/Archives/Public/uri/2002Sep/0047.html> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Walden Mathews [mailto:waldenm@...] > Sent: Tuesday, December 24, 2002 9:40 PM > To: cmhinson@... > Cc: rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Future proof > > > Chuck, > > Thanks for the reference to the Roy message. > > I see two issues here, worth separating. There is the notion of > a resource > capable of delivering out a variety of different representations > at a single > point in time, that variety being the space in which content > negotiation may > take place. > > There is another issue, closer to "equivalence" (which causes trouble in > other areas as well, it seems. I PUT this representation to this URI, and > it > replaces any existing representations. That means that upon the > completion > of PUT, that resource has but one representation. > > But when we say "one representation", we're not also spelling out the > rules for what would distinguish one from two. If characters are present, > does case matter? ASCII or other? If the representation consists of a > "bag" of things, does literality force an unintended ordering on > that? And > so on. > > When Roy says that 2616 "PUT" method specifies that PUT obliterates > variance of representation, I believe the language of 2616 reasonably > supports his assertion. If he were asserting that 2616 PUT > method specifies > literality, I'd have to say that my careful readings so far can't > find that. > > There's another problem here, in that the great majority of web > application > developers don't have access to Roy to to his email conversations, and > so those resources don't quality as part of the standard, unfortunately. > We need to approach that problem with care, I think. > > Walden > > ----- Original Message ----- > From: "Chuck Hinson" <cmhinson@...> > To: "Walden Mathews" <waldenm@...> > Sent: Tuesday, December 24, 2002 11:35 AM > Subject: Re: [rest-discuss] Future proof > > > > > > > > Walden Mathews wrote: > > > > >>>I remember reading on this list (if I'm not mistaken), that > PUT should > > >>>store the document as is, and you should be able to retrieve the > > >>>unchanged document through a GET. > > >>> > > > > > >Reading that on this list doesn't make it true. This is not > clear in the > > >language of 2616, and so I question its status as "standard". > Generally, > > >resources, according to REST, are functions that map time to values, > > >and there are no constraints in REST saying that resource values may > > >only be changed via the HTTP interface. > > > > > >If someone can find, somewhere in the body of standards, clear > > >language to the effect that the resource implementation is expected to > > >store a PUT value in bit-literal form, and that a subsequent GET on > > >a resource that has suffered a PUT at some time in its life is required > > >to serve out bit-literal representations... > > > > > It's not quite that limiting strict. The interpretation presented > > earlier on this list was that given no intervening operations between a > > PUT and a GET (and assuming no other mechanism changes the resource's > > state), a GET should return the exact representation submitted by the > > immediately previous PUT. Note, however, that once a representation > > has been PUT, there's nothing that says the state of the resource can't > > be changed by some other means. > > > > > > > >If someone finds that, would they please give me a pointer? > > > > > > > We can certainly argue about what the spec actually says vs what one or > > more of it's authors intended . However, Roy Fielding has made at least > > one statement[1] that I (and I believe others) interpret to mean what I > > stated above. > > > > [1] http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html > > > > --Chuck > > > > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
----- Original Message ----- From: "Julian Reschke" <julian.reschke@...> > However I agree that it's probably better to assign > distinct URIs to each variant (making authoring of them more > straightforward), With different URIs you'll need to discover those URIs through a response against a different URI. And what is this 'primary' URI supposed to mean? Should all content negotiation continue to use Accept headers against this primary URI and have the response provide a Location header for the representation format identified by the Content-Type response header? Will intermediaries understand this?
Hi Folks,
Below I describe a simple technique for evolving the current HTML-based
Web service architecture to support the next generation Web services.
The approach is RESTful. That is, it capitalizes on the current Web
architecture. I would be very interested in your thoughts.
Consider what is involved in setting up a Web site today. I will take
my Web site as an example. Creating my Web site was really
straightforward - I created an HTML page that contained the content, and
in the header section of the HTML I added a <meta> tag to provide
subject and category metadata. In a short period of time many different
search engines had indexed and categorized my Web site. Further, over
time other Web sites have linked to my Web site.
My Web site is a Web service, in its simplest form. It is an HTML-based
Web service. It provides an information service to Web clients. My
service has metadata.
Today's Web service architectural model has three key ingredients -
content, metadata, and search engines (matchmakers). This architectural
model has many wonderful properties:
1. It is massively scalable.
2. It is a completely distributed architecture.
3. It is a lightweight architecture - just build a Web service and
you're done.
4. Standard Web components are used - URIs to identify a Web service,
the HTTP verbs (GET, PUT, POST, DELETE) to access and manipulate the
service.
5. Tremendous interconnectedness - others link to my Web service and I
can link to other Web services. Recall Metcalf's Law which states that
the value of a networked system is related exponentially to the amount
of interconnections.
6. A wonderful side-effect of the architecture is a whole search engine
cottage industry has been created. This is because the Web services are
decoupled from the search engines.
Since the current Web architecture has been so successful, it seems
reasonable to use that architecture at least as the starting point for
the next generation of Web services. Here's how the next generation Web
services would operate if we simply apply the current approach:
A client invoking a next generation Web service will receive
SOAP or XML or XML-RPC content, with metadata bundled into the
response (analogous to today where the client receives
HTML content with metadata bundled in).
However, there is a problem with simply applying the current approach to
the next generation of Web services:
The next generation Web services will be a lot more complicated,
so the metadata will need to be a lot more involved, i.e.,
bigger. You don't want clients to be forced to receive an
extensive description of everything the service does and all the
instructions on how to use the service every time they use a
Web service. The first time they use it they will want to
view the service description metadata but from then on they
will not.
So we probably want to keep the metadata and the service representation
separate. This has the additional benefit of flexibility with regards
to the format of the metadata - it could be expressed as RDF or DAML or
OWL or even XHTML.
However, keeping the metadata separate from the service representation
then introduces a problem:
- if a client has the URL to a service, how does the client
locate the metadata for the service?
- alternatively, if the client has the URL to the metadata,
how does the client locate the service?
This is solved very simply by introducing two new HTTP headers:
- The Meta-Location HTTP header provides the URL to the metadata
- The Meta-About HTTP header provides the URL to the service.
That's it! With these simple changes we can extend the current
(HTML-based) Web services architecture to meet the challenges of the
next generation Web services. Let's review what changes are made to the
current Web services architecture:
1. Separate the metadata from the service representation
2. A URL to a Web service results in returning a representation of the
service. The HTTP header contains Meta-Location, which provides the URL
to the service's metadata.
3. A URL to the metadata results in returning a representation of the
metadata. The HTTP header contains Meta-About, which provides the URL
to the service.
This approach retains all of the wonderful properties of the current
(HTML-based) Web services architecture:
1. It is massively scalable.
2. It is a completely distributed architecture.
3. It is a lightweight architecture - just build the Web service, create
your metadata, and you're done.
4. The standard Web components are used - URIs to identify the Web
service and the metadata, the HTTP verbs (GET, PUT, POST, DELETE) to
access and manipulate the service and metadata.
5. Tremendous interconnectedness - others link to my Web service and to
my metadata and I can link my Web service or my metadata to other Web
services or metadata.
6. The search engine cottage industry is enhanced further. The industry
will grow at an increasing rate as new types of search engines will be
required. For example, for RDF-based services there will be RDF-based
search engines that will enable inductive and deductive reasoning; for
DAML/OWL-based services there will be DAML and OWL tools that enable
associations using ontologies; and, of course, there will continue to be
the old HTML-based search tools for browser-based clients.
Lastly, I would like to highlight one very important point:
After creating my Web site I did not then "register" it (anywhere). The
search engines found my Web site. I did not have to go out and find the
search engines. This is a good thing. The responsibility is on the
search engines to keep track of the Web sites (Web services) that are
out there. The responsibility is not on individual Web site developers
to keep track of what search engines are out there.
Matchmaker (search engine) tool axiom:
The onus is on the matchmaker tools to find the Web
services, and provide information to clients based upon
the Web services description metadata.
Thus, the matchmakers cannot require, nor expect, Web services to
register with them. The burden is thus on the matchmakers, not on the
Web services.
Stated another way: the matchmakers must remain decoupled from the Web
service and its service description.
Comments? /Roger
Roger L. Costello wrote: > > However, keeping the metadata separate from the service representation > then introduces a problem: > > - if a client has the URL to a service, how does the client > locate the metadata for the service? > - alternatively, if the client has the URL to the metadata, > how does the client locate the service? > > This is solved very simply by introducing two new HTTP headers: > > - The Meta-Location HTTP header provides the URL to the metadata > - The Meta-About HTTP header provides the URL to the service. > Why not just introduce only one new header: Content-alternatives: which returns a comma seperated list of content-types that can serverd from the URL. GETting those alternate types can be the gateway to other services. For example, Content-alternatives could include 'application/rss+xml' to indicate the RSS feed. It could also return 'application/wsil+xml'[1] or 'application/rsd+xml'[2] to describe available web services (modulo some politically correct definition of 'web service'). This would allow multiple competing formats for web service and meta-data identification to be developed and deployed. [1] http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html [2] http://archipelago.phrasewise.com/rsd -joe -- http://BitWorking.org http://WellFormedWeb.org
Hi Joe, Joe Gregorio wrote: > > Why not just introduce only one new header: > > Content-alternatives: > > which returns a comma separated list of content-types that can be > served from the URL. Thanks for the suggestion! Your suggestion is actually very close to what we are doing, only one step removed. The problem is when both the service and its description have the same content-type. For example, the service returns an XHTML representation of the service, and the service description returns an XHTML representation of the metadata. We didn't want to overload the semantics of the service URL because of this confusion that occurs when the content type of the service and the content type of the meta data are the same. /Roger
Roger L. Costello wrote: > Joe Gregorio wrote: >>Why not just introduce only one new header: >> >> Content-alternatives: >> >>which returns a comma separated list of content-types that can be >>served from the URL. > > The problem is when both the service and its description have the same > content-type. For example, the service returns an XHTML representation > of the service, and the service description returns an XHTML > representation of the metadata. Another problem with Joe's approach is that metadata _about_ a resource is not a representation of the resource it describes. Instead it is a separate resource, which should have its own URI. Suppose I want to link to, or make assertions about, the metadata describing a service. Using your approach, I can use the URL in the Meta-Location header. Joe's approach in effect creates a private address space where content-type is used to address different resources, rather than just different representations. That seems non-REST-like to me. Jim
> From: S. Mike Dierken [mailto:mdierken@...] > ... > > However I agree that it's probably better to assign > > distinct URIs to each variant (making authoring of them more > > straightforward), > With different URIs you'll need to discover those URIs through a response > against a different URI. And what is this 'primary' URI supposed to mean? Why through "a different" URI? I imagine the 'primary' resource to be just an arbiter. BTW: there's a very early WebDAV draft for authoring variants ([1]), and this draft calls these primary resources "variant controllers". As far as I understand, namespace operations on variant controllers (MOVE/COPY) will affect the variants (and their URIs as well). One probably could also use PROPPATCH on the variant controller to add/remove variants... > Should all content negotiation continue to use Accept headers against this > primary URI and have the response provide a Location header for the > representation format identified by the Content-Type response header? Will Yes! > intermediaries understand this? Good question. [1] <http://www.webdav.org/deltav/protocol/draft-ietf-deltav-variants-xx.1.htm> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Donald Ball wrote: > Another example might be apache struts. Struts heavily uses the > RequestDispatcher servlet api to internally forward requests to different > components. In and of itself that's not a bad thing, but struts uses it to > such a degree that the "URL" of a given page and the contents of that page > may have no relation to one another. It also seems to encourage developers > to use the HttpSession object to store conversational state, which is > problematic from a REST point of view. And in some cases, from the point of view of a browser's back button. > Fixing struts to be RESTful would require a serious amount of work, and I > guess I doubt that the developers could be convinced that it would be a > worthwhile investment. (which is very much too bad, since struts seems to > be very popular as a webapp infrastructure.) The core problem with these frameworks (and their reason for being) is session management. In REST/OO terms the session is the resource/object the business and thus the webapp developers really care about. However smearing that resource across a web site and a browser (cookies, session ids in urls) makes for highly messy software. Rather than remove this problem, webapp frameworks paint abstractions on top of it. There must be a dozen other frameworks in Java-land doing the same job in much the same way. And even if you did refactor struts to do a better job of sessions, they're managing sessions the way they do in large part because web browsers are they way they are. Realistically, you'd have to fix the browsers too. Any useful REST toolkit is going to look like a webapp framework that lets developers manage session state over HTTP in a sane way. Bill de h�ra
I have implemented a web service interface to the RSS validator [1].
The essence of the interface is that one can simply POST your RSS feed,
and you will get back either a set of messages or a fault, complete with
the server's python stack traceback at the time of the error.
At the bottom on this e-mail is a working example of a Python client for
this web service.
Other information that may or may not be relevant: the server
implementation will ignore any SOAPAction HTTP header or SOAP Envelope
or Body elements. The responses are well formed XML and valid SOAP.
Both the request and response are described by XML Schema, and the
interaction is declared by a WSDL document [2].
Now let me get to the point of this e-mail. In response to criticism
[3], I am looking for constructive suggestions as to how to make this
interface more compatible with REST.
[1] http://feeds.archive.org/validator/
[2] http://feeds.archive.org/validator/RSSValidator.wsdl
[3] http://www.intertwingly.net/blog/1049.html#c1041017434
- - - -
import urllib, httplib
from xml.dom import minidom
feed='http://www.aaronsw.com/weblog/index.xml'
request=urllib.urlopen(feed).read()
connection=httplib.HTTPConnection("feeds.archive.org", 80)
connection.request('POST',"/validator/", request)
response=connection.getresponse()
document=minidom.parseString(response.read())
if response.status >= 500:
errors = document.getElementsByTagName("faultstring")
else:
errors = document.getElementsByTagName("text")
if not errors:
print "The feed is valid!"
else:
for node in errors:
print "".join([child.data for child in node.childNodes])
--- In rest-discuss@yahoogroups.com, Joe Gregorio <joe@b...> wrote: > Why not just introduce only one new header: > > Content-alternatives: > > which returns a comma seperated list of content-types that can serverd from the URL. > > GETting those alternate types can be the gateway to > other services. For example, Content-alternatives could include 'application/rss+xml' to indicate > the RSS feed. It could also return 'application/wsil+xml'[1] or 'application/rsd+xml'[2] > to describe available web services (modulo some politically correct definition of 'web service'). > This would allow multiple competing formats for web service and meta-data identification > to be developed and deployed. > > [1] http://www-106.ibm.com/developerworks/webservices/library/ws- wsilspec.html > [2] http://archipelago.phrasewise.com/rsd What you propose is actually very close to what we are doing only removed one step. We didn't want to overload the semantics of the service URL because of the confusion that could happen when the content type of the service and the content type of the meta data are the same. David
From: "Walden Mathews" <waldenm@...> > > If someone can find, somewhere in the body of standards, clear > language to the effect that the resource implementation is expected to > store a PUT value in bit-literal form, and that a subsequent GET on > a resource that has suffered a PUT at some time in its life is required > to serve out bit-literal representations... I have had problems with this as well. So far, I just cannot see how this could be enforced. Between the moment that the PUT was completed and a subsequent GET was requested, the resource could have been updated (via PUTs, if you want) several times. There is no mechanism in HTTP to perform a PUT-followed-by-GET as an atomic operation. As a result, it seems that one should *ever* expect the representation sent with a PUT to be the same as the representation retrieved with a GET, at least as a general rule. --- Seairth Jacobs seairth@...
From: "Seairth Jacobs" <seairth@...> > > one should *ever* expect the representation sent with a PUT to be the same that should be "never", not "ever"... sorry. --- Seairth Jacobs seairth@...
I'm certainly no expert on HTTP caching, but the definition of PUT
does include the line:
If the request passes through a cache and the Request-URI
identifies one or more currently cached entities, those
entries SHOULD be treated as stale.
Notice that this doesn't say "MUST." This would seem to imply
the a cache *could* simply update it's entry without marking
it stale, and hence respond to another request without revalidating
against the origin server (depending on the cache control headers
of the request and the original response).
If the origin server had changed "<number>1</number>" to
"<number>one</number>" things could get ugly.
If PUT did require the entity to be stored as-is (which we keep
hearing it does) then this wouldn't be an issue.
I could be completely wrong about this and would appreciate
hearing about where I went awry.
- Winter
----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Saturday, December 28, 2002 10:59 PM
Subject: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
> From: "Walden Mathews" <waldenm@...>
> >
> > If someone can find, somewhere in the body of standards, clear
> > language to the effect that the resource implementation is expected to
> > store a PUT value in bit-literal form, and that a subsequent GET on
> > a resource that has suffered a PUT at some time in its life is required
> > to serve out bit-literal representations...
>
> I have had problems with this as well. So far, I just cannot see how this
> could be enforced. Between the moment that the PUT was completed and a
> subsequent GET was requested, the resource could have been updated (via
> PUTs, if you want) several times. There is no mechanism in HTTP to
perform
> a PUT-followed-by-GET as an atomic operation. As a result, it seems that
> one should *ever* expect the representation sent with a PUT to be the same
> as the representation retrieved with a GET, at least as a general rule.
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
On Sun, Dec 29, 2002 at 08:39:15PM -0500, Jeffrey Winter wrote: > I'm certainly no expert on HTTP caching, but the definition of PUT > does include the line: > > If the request passes through a cache and the Request-URI > identifies one or more currently cached entities, those > entries SHOULD be treated as stale. > > Notice that this doesn't say "MUST." This would seem to imply > the a cache *could* simply update it's entry without marking > it stale, and hence respond to another request without revalidating > against the origin server (depending on the cache control headers > of the request and the original response). I read that line a little differently -- It refers to a PUT request from a user agent passing through a proxy cache on its way to an origin server. I'm fairly certain that the cache is not allowed to update its contents based on that PUT request, since it has no idea whether the PUT will even be accepted by the origin server. What it *is* allowed to do, though, is mark its cached copies as 'stale', so that the next GET request for that resource will cause the cache to query the origin server for the most recent version. This behaviour is only given the strength of 'SHOULD', since not doing it doesn't weaken the caching semantics in any way. The old version of the resource can still be served until it expires -- just as all of the other caches, which didn't see the PUT, will be doing. > If the origin server had changed "<number>1</number>" to > "<number>one</number>" things could get ugly. > > If PUT did require the entity to be stored as-is (which we keep > hearing it does) then this wouldn't be an issue. I don't think this section of RFC 2616 has anything to say about whether the server must store the entity as-is. If the server modifies the entity when it receives it, then the cache should retrieve the modified version when it revalidates. The existence of caching, though, does mean that you can't assume that a GET issued immediately after a PUT will return the recently-PUT entity. It could legitimately return with any non-expired version of the entity previously served by the origin server. Ian Clelland <ian@...>
On Sun, Dec 29, 2002 at 06:21:36PM -0800, Ian Clelland wrote: > I read that line a little differently -- It refers to a PUT request > from a user agent passing through a proxy cache on its way to an origin > server. I'm fairly certain that the cache is not allowed to update its > contents based on that PUT request, since it has no idea whether the PUT > will even be accepted by the origin server. > > What it *is* allowed to do, though, is mark its cached copies as > 'stale', so that the next GET request for that resource will cause the > cache to query the origin server for the most recent version. > > This behaviour is only given the strength of 'SHOULD', since not doing > it doesn't weaken the caching semantics in any way. The old version of > the resource can still be served until it expires -- just as all of the > other caches, which didn't see the PUT, will be doing. That's exactly my interpretation. > > If the origin server had changed "<number>1</number>" to > > "<number>one</number>" things could get ugly. > > > > If PUT did require the entity to be stored as-is (which we keep > > hearing it does) then this wouldn't be an issue. > > I don't think this section of RFC 2616 has anything to say about whether > the server must store the entity as-is. Well, the first sentence of section 9.6 says; "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." I know some people have a more liberal interpretation of "store" than I do, which is fine. But I think that a significant number think - and more importantly, have written software that assumes - that "store" means, well, "store". 8-) I don't know how much software out there makes this assumption, but I'd be willing to bet money that anybody developing software that doesn't make this assumption, will eventually have problems when it discovers the other software. Doesn't WebDAV + supporting specs assume that PUT = store? Julian? MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Seairth Jacobs wrote: >From: "Walden Mathews" <waldenm@...> > >>If someone can find, somewhere in the body of standards, clear >>language to the effect that the resource implementation is expected to >>store a PUT value in bit-literal form, and that a subsequent GET on >>a resource that has suffered a PUT at some time in its life is required >>to serve out bit-literal representations... >> > >I have had problems with this as well. So far, I just cannot see how this >could be enforced. Between the moment that the PUT was completed and a >subsequent GET was requested, the resource could have been updated (via >PUTs, if you want) several times. There is no mechanism in HTTP to perform >a PUT-followed-by-GET as an atomic operation. As a result, it seems that >one should *ever* expect the representation sent with a PUT to be the same >as the representation retrieved with a GET, at least as a general rule. > I'm not sure I understand the previous sentence. Is that *ever* or *never*. I'll assume you meant *never*. I believe you're leaving out important parts of the statement. I'll try to restate it here as I understand it: A GET operation that immediately follows a PUT operation must return exactly the representation presented by the PUT, _provided that the resource's state does not change between those two operations_. Note that this statement is about the behavior of the server; it is not about behavior that an arbitraty client might be able to observe. I'm pretty sure we've had this discussion here before (or maybe it was rest-expolore), but I can't suffer through Yahoo's UI to provide a reference. (Try searching the August/September 2002 archives) If I remember correctly, this whole thing is not really about what you GET after a PUT. It is more about whether or not you can do content negotiation/have variants on a PUT. As I understand it, Fielding says you can't because there's no mechanism (in HTTP) to indicate whether the contents of the PUT is a variant of the current representation or a replacement for the current representation. I seem to remember that the conversation wrapped up with an understanding that, in general, resources that support PUT cannot support content negotiation. --Chuck
From: "Mark Baker" <distobj@...> > > On Sun, Dec 29, 2002 at 06:21:36PM -0800, Ian Clelland wrote: > > > > I don't think this section of RFC 2616 has anything to say about whether > > the server must store the entity as-is. > > Well, the first sentence of section 9.6 says; > > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI." > > I know some people have a more liberal interpretation of "store" than > I do, which is fine. But I think that a significant number think - > and more importantly, have written software that assumes - that "store" > means, well, "store". 8-) I am guessing that many (maybe even most) implementations implicitly assume that PUT is being used by a limited/controlled number of clients (usually one) on a given URI. For example, if I were to update my website using PUT, I am the sole user of PUT on any given URI. This allows me to "safely" state that my html file was stored "as is" at that request-URI. However, suppose you have a URI that is being updated by several clients independently. For example, suppose that you have a client that scans all documents and auto-corrects misspelled words. In this case, a PUT-followed-by-GET would not guarantee that the returned entity would be the same as the one sent in the first place because PUTs from other client(s) could happen in between the PUT and GET operations. Now, if you were to take this a bit further, the server itself could update the resource between the PUT and GET. If you want, think of it as an implicit GET-followed-by-PUT where the server is acting like a "client". The end result would be no different from another client performing the same operation. > I don't know how much software out there makes this assumption, but > I'd be willing to bet money that anybody developing software that > doesn't make this assumption, will eventually have problems when it > discovers the other software. It seems to me that adding a constraint where "store" means "as is" will be the more likely cause of the problems. Taking a looser interpretation can still allow "as is" when it's needed without forcing thos blinders all implementations. --- Seairth Jacobs seairth@...
From: "Chuck Hinson" <cmhinson@...> > > Seairth Jacobs wrote: > > >From: "Walden Mathews" <waldenm@...> > > > >>If someone can find, somewhere in the body of standards, clear > >>language to the effect that the resource implementation is expected to > >>store a PUT value in bit-literal form, and that a subsequent GET on > >>a resource that has suffered a PUT at some time in its life is required > >>to serve out bit-literal representations... > >> > > > >I have had problems with this as well. So far, I just cannot see how this > >could be enforced. Between the moment that the PUT was completed and a > >subsequent GET was requested, the resource could have been updated (via > >PUTs, if you want) several times. There is no mechanism in HTTP to perform > >a PUT-followed-by-GET as an atomic operation. As a result, it seems that > >one should *ever* expect the representation sent with a PUT to be the same > >as the representation retrieved with a GET, at least as a general rule. > > > I'm not sure I understand the previous sentence. Is that *ever* or > *never*. I'll assume you meant *never*. Yeah, that's what I meant. <s> > I believe you're leaving out important parts of the statement. I'll try > to restate it here as I understand it: > > A GET operation that immediately follows a PUT operation must return > exactly the representation presented by the PUT, _provided that the > resource's state does not change between those two operations_. Note > that this statement is about the behavior of the server; it is not about > behavior that an arbitraty client might be able to observe. But if PUT means that the server maps the request-entity "as is" to the request-URI, then the only way that a resource state can change between those two operations is via a client. From what some are saying, the "behaviour" of the server for PUT will never cause a state change before the subsequent GET (assuming no other external operations are performed in between). Am I wrong about this? > I'm pretty sure we've had this discussion here before (or maybe it was > rest-expolore), but I can't suffer through Yahoo's UI to provide a > reference. (Try searching the August/September 2002 archives) perma-thread... > If I remember correctly, this whole thing is not really about what you > GET after a PUT. It is more about whether or not you can do content > negotiation/have variants on a PUT. As I understand it, Fielding says > you can't because there's no mechanism (in HTTP) to indicate whether the > contents of the PUT is a variant of the current representation or a > replacement for the current representation. I seem to remember that the > conversation wrapped up with an understanding that, in general, > resources that support PUT cannot support content negotiation. I think you are talking about a different thread than I am. I think there are very real examples of this problem without bringing content negotiation or variants into it. I admit that's an issue, but a different one. --- Seairth Jacobs seairth@...
I'll nitpick with your use of "imply". I don't think the quoted language implies the consequence at all. It' just doesn't explicitly prohibit it. I'm no expert on HTTP caching either, but given that a PUT is still just a _request_ on the server to accept the representation, and the server doesn't have to honor the request, updating the cache from a PUT representation seems highly questionable. Walden. ----- Original Message ----- From: "Jeffrey Winter" <j.winter@...> To: "rest-discuss" <rest-discuss@yahoogroups.com>; "Seairth Jacobs" <seairth@...> Sent: Sunday, December 29, 2002 8:39 PM Subject: Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof) > I'm certainly no expert on HTTP caching, but the definition of PUT > does include the line: > > If the request passes through a cache and the Request-URI > identifies one or more currently cached entities, those > entries SHOULD be treated as stale. > > Notice that this doesn't say "MUST." This would seem to imply > the a cache *could* simply update it's entry without marking > it stale, and hence respond to another request without revalidating > against the origin server (depending on the cache control headers > of the request and the original response). > > If the origin server had changed "<number>1</number>" to > "<number>one</number>" things could get ugly. > > If PUT did require the entity to be stored as-is (which we keep > hearing it does) then this wouldn't be an issue. > > I could be completely wrong about this and would appreciate > hearing about where I went awry. > > - Winter > > > ----- Original Message ----- > From: "Seairth Jacobs" <seairth@...> > To: "rest-discuss" <rest-discuss@yahoogroups.com> > Sent: Saturday, December 28, 2002 10:59 PM > Subject: PUT-followed-by-GET (was Re: [rest-discuss] Future proof) > > > > From: "Walden Mathews" <waldenm@...> > > > > > > If someone can find, somewhere in the body of standards, clear > > > language to the effect that the resource implementation is expected to > > > store a PUT value in bit-literal form, and that a subsequent GET on > > > a resource that has suffered a PUT at some time in its life is required > > > to serve out bit-literal representations... > > > > I have had problems with this as well. So far, I just cannot see how this > > could be enforced. Between the moment that the PUT was completed and a > > subsequent GET was requested, the resource could have been updated (via > > PUTs, if you want) several times. There is no mechanism in HTTP to > perform > > a PUT-followed-by-GET as an atomic operation. As a result, it seems that > > one should *ever* expect the representation sent with a PUT to be the same > > as the representation retrieved with a GET, at least as a general rule. > > > > --- > > Seairth Jacobs > > seairth@... > > > > > > > > To unsubscribe from this group, send an email to: > > rest-discuss-unsubscribe@yahoogroups.com > > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > > > > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > >
> Well, the first sentence of section 9.6 says; > > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI." > > I know some people have a more liberal interpretation of "store" than > I do, which is fine. But I think that a significant number think - > and more importantly, have written software that assumes - that "store" > means, well, "store". 8-) In my opinion, that's overloading the term "store" just a teeny bit. The thrust of the quote above is *which URI* the representation should be stored under, not whether it should be _stored_ or *stored* or "stored". Anyway, storage is implementation detail. If a server can receive a PUT request and later dish up the right representation on GET, then it is behaving correctly, and if it can do that without _storing_ the rep, well that's none of our business. /walden
> I believe you're leaving out important parts of the statement. I'll try > to restate it here as I understand it: > > A GET operation that immediately follows a PUT operation must return > exactly the representation presented by the PUT, Is some kind of equivalence implied? If so, what is its specification? There are folks hotly debating, as we speak, how to do equiavalence on URI strings. > _provided that the > resource's state does not change between those two operations_. Note > that this statement is about the behavior of the server; it is not about > behavior that an arbitraty client might be able to observe. Are you talking about nontransparent cache effects here? If not, then I don't understand why you say that GET's behavior is not observable by clients. > > If I remember correctly, this whole thing is not really about what you > GET after a PUT. It is more about whether or not you can do content > negotiation/have variants on a PUT. As I understand it, Fielding says > you can't because there's no mechanism (in HTTP) to indicate whether the > contents of the PUT is a variant of the current representation or a > replacement for the current representation. I seem to remember that the > conversation wrapped up with an understanding that, in general, > resources that support PUT cannot support content negotiation. Let's look at a SQL analogy in which UPDATE is in the same role as HTTP PUT. > UPDATE ORDER SET ORDER_DATE = '1/12/2003 09:00:00' where KEY='1' 1 row(s) updated Here I've supplied a string representation of a date field, whose internal storage for whatever SQL engine I'm using is irrelevant. Now I'll retrieve the same info: > SELECT ORDER_DATE from ORDER where KEY='1' Jan 12, 2003 9:00 AM 1 row(s) Semantically equivalent, but the format's been changed. Happens all the time. The UPDATE didn't store yet another variant, nor did it take my string and try to treat its bits as a long integer or something else. /walden
On Mon, Dec 30, 2002 at 12:14:39AM -0500, Walden Mathews wrote: > In my opinion, that's overloading the term "store" just a teeny bit. The > thrust of the quote above is *which URI* the representation should be > stored under, not whether it should be _stored_ or *stored* or "stored". > > Anyway, storage is implementation detail. If a server can receive a PUT > request and later dish up the right representation on GET, then it is > behaving correctly, and if it can do that without _storing_ the rep, well > that's none of our business. RFC 2616 is describing a network interface. The meaning of PUT - store - prescribes only storage interface semantics; bits in, same bits out. I understand your angle here, but it's a tad academic, since all that really matters is what most other people believe and implement - and that's bit-wise equivalence in everything I've seen PUT used for. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Walden Mathews wrote: >>I believe you're leaving out important parts of the statement. I'll try >>to restate it here as I understand it: >> >>A GET operation that immediately follows a PUT operation must return >>exactly the representation presented by the PUT, >> > >Is some kind of equivalence implied? If so, what is its specification? >There >are folks hotly debating, as we speak, how to do equiavalence on URI >strings. > I'm not sure I see the connection. One is talking about comparing URI strings, while the other is about the equivalence of representations (and then only indirectly).. >>_provided that the >>resource's state does not change between those two operations_. Note >>that this statement is about the behavior of the server; it is not about >>behavior that an arbitraty client might be able to observe. >> > >Are you talking about nontransparent cache effects here? If not, then >I don't understand why you say that GET's behavior is not observable >by clients. > I probably overconstrained things by including the statment about what is observable by the client. In retrospect, it seems kind of obvious that if the resource's state doesnt change between requests, then the observed behavior is the same at the server as well as at the client making the requests. >>If I remember correctly, this whole thing is not really about what you >>GET after a PUT. It is more about whether or not you can do content >>negotiation/have variants on a PUT. As I understand it, Fielding says >>you can't because there's no mechanism (in HTTP) to indicate whether the >>contents of the PUT is a variant of the current representation or a >>replacement for the current representation. I seem to remember that the >>conversation wrapped up with an understanding that, in general, >>resources that support PUT cannot support content negotiation. >> > >Let's look at a SQL analogy in which UPDATE is in the same role as >HTTP PUT. > >> UPDATE ORDER SET ORDER_DATE = '1/12/2003 09:00:00' where KEY='1' >> > >1 row(s) updated > >Here I've supplied a string representation of a date field, whose internal >storage for whatever SQL engine I'm using is irrelevant. Now I'll retrieve >the same info: > >> SELECT ORDER_DATE from ORDER where KEY='1' >> > >Jan 12, 2003 9:00 AM > >1 row(s) > >Semantically equivalent, but the format's been changed. Happens all >the time. The UPDATE didn't store yet another variant, nor did it take >my string and try to treat its bits as a long integer or something else. > >/walden > I'm too tired to get a fully formed thought right now, but it seems to me that the difference here is that the various date formats are part of the sql specification whereas they are not in HTTP. And because they are not, you cant have a uniform interface when some resources understand the semantic equivalence and others do not (or interpret it differently). --Chuck
Seairth Jacobs wrote: >From: "Chuck Hinson" <cmhinson@...> > [. . .] >>A GET operation that immediately follows a PUT operation must return >>exactly the representation presented by the PUT, _provided that the >>resource's state does not change between those two operations_. Note >>that this statement is about the behavior of the server; it is not about >>behavior that an arbitraty client might be able to observe. >> > >But if PUT means that the server maps the request-entity "as is" to the >request-URI, then the only way that a resource state can change between >those two operations is via a client. From what some are saying, the >"behaviour" of the server for PUT will never cause a state change before the >subsequent GET (assuming no other external operations are performed in >between). Am I wrong about this? > Yes. I didnt say that the server won't cause a state change. I just said that if a state change does occur, then the rule no longer holds. In other words, if a state change does occur, then there can be no garantees about the content of a GET following a PUT. --Chuck
FYI: according to Amazon they do in fact have precautions to prevent the inappropriate use of the document() function. Paul Prescod
> From: Mark Baker [mailto:distobj@...] > Sent: Monday, December 30, 2002 4:14 AM > To: Ian Clelland > Cc: Jeffrey Winter; rest-discuss@yahoogroups.com > Subject: Re: [rest-discuss] Re: PUT-followed-by-GET > > > ... > > > I don't think this section of RFC 2616 has anything to say about whether > > the server must store the entity as-is. > > Well, the first sentence of section 9.6 says; > > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI." > > I know some people have a more liberal interpretation of "store" than > I do, which is fine. But I think that a significant number think - > and more importantly, have written software that assumes - that "store" > means, well, "store". 8-) > > I don't know how much software out there makes this assumption, but > I'd be willing to bet money that anybody developing software that > doesn't make this assumption, will eventually have problems when it > discovers the other software. > > Doesn't WebDAV + supporting specs assume that PUT = store? Julian? RFC2518 is very silent about PUT - it completely relies on the HTTP definition. Almost all real-world WebDAV implementations although use WebDAV as some sort of filesystem replacement. So they assume that the entity sent with PUT indeed is stored octet-per-octet, and that you can retrieve it exactly as written with GET. Which doesn't mean that I can think that you can or should rely on it. One server (I think either Slide/Tamino or Oracle) allows WebDAV access to an underlying XML store, and at least for XML-wellformed entities it is *not* going to store the XML serialization, but the XML infoset in some internal format. This means, that you aren't going to round-trip things like attribute quoting (quote vs apostrophe and so on...). Another use case would be a server that filters content that is PUT to extract metadata (for storage as WebDAV properties). For instance, servers may extract author information from Word or HTML files. So the submitted entity is indeed stored (as octet stream), but the server automatically adds metadata that wasn't explicit in the request. WebDAV's interaction with conneg/variant handling currently is completely underspecified. Indeed I just tried Apache 2.0.43 with moddav enabled on the root and got very strange results when trying to create a new resource named "index.html" (Apache crashing when using index.html as Destination for a MOVE command). :-) So obviously this needs work. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Paul Prescod wrote, > FYI: according to Amazon they do in fact have precautions to prevent > the inappropriate use of the document() function. Interesting ... thanks. Any chance of persuading Amazon to say what those restrictions are? They're surprisingly tricky to specify without leaving subtle loopholes (cp. the history of "originating host" flaws in browser based script and applet implementations), so if they've done it right it would be a helpful service to the community at large to publish the details. OTOH, if they haven't got it right ... well, you know what they say about "security through obscurity". Cheers, Miles
On Sat, Dec 28, 2002 at 08:09:58PM -0500, Sam Ruby wrote: > Now let me get to the point of this e-mail. In response to criticism > [3], I am looking for constructive suggestions as to how to make this > interface more compatible with REST. While I don't really have any suggestions, I would like to throw in a thought from here - I *think* I would like to be able to tell whether the data that I threw at the validator was valid RSS or not by looking at the status code. This requires a slight rethink of the model Sam has, whereby the URI represents a container that you're *supposed* to throw valid RSS at, and receive either: a 200 status with no message body if the RSS is valid or a non-200 status back (with the details in the message body) if it's not. Thing is, I can't figure out what the status code should be. I first looked at status code 415 (Unsupported Media Type) but I suspect that would mean that 'application/rss+xml' was *generally* not supported at that URI, rather than just *invalid* 'application/rss+xml'. So - is trying to get away from the 'homogenisation' of all results into a 200 status code an appropriate thing to do here (or anywhere)? Thanks for any comments dj p.s. If I didn't know Sam better I would suspect this conundrum is deliberate ;) Either that, or my brane is too addled from festive food.
Personally, I don't see why this isn't a RESTful interface. You're doing
a "GET" on a resource, e.g.:
http://feeds.archive.org/validator/check?url=http%3A%2F%2Fdiveintomark.org%2Fx
ml%2Frss.xml
and getting a response.
I'm curious about what you say about the SOAP <envelope> and <body> elements
though: under what circumstances would they occur in the returned document?
- Jeff
----- Original Message -----
From: "Sam Ruby" <rubys@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, December 28, 2002 8:09 PM
Subject: [rest-discuss] Towards a RESTful validation interface
I have implemented a web service interface to the RSS validator [1].
The essence of the interface is that one can simply POST your RSS feed,
and you will get back either a set of messages or a fault, complete with
the server's python stack traceback at the time of the error.
At the bottom on this e-mail is a working example of a Python client for
this web service.
Other information that may or may not be relevant: the server
implementation will ignore any SOAPAction HTTP header or SOAP Envelope
or Body elements. The responses are well formed XML and valid SOAP.
Both the request and response are described by XML Schema, and the
interaction is declared by a WSDL document [2].
Now let me get to the point of this e-mail. In response to criticism
[3], I am looking for constructive suggestions as to how to make this
interface more compatible with REST.
[1] http://feeds.archive.org/validator/
[2] http://feeds.archive.org/validator/RSSValidator.wsdl
[3] http://www.intertwingly.net/blog/1049.html#c1041017434
- - - -
import urllib, httplib
from xml.dom import minidom
feed='http://www.aaronsw.com/weblog/index.xml'
request=urllib.urlopen(feed).read()
connection=httplib.HTTPConnection("feeds.archive.org", 80)
connection.request('POST',"/validator/", request)
response=connection.getresponse()
document=minidom.parseString(response.read())
if response.status >= 500:
errors = document.getElementsByTagName("faultstring")
else:
errors = document.getElementsByTagName("text")
if not errors:
print "The feed is valid!"
else:
for node in errors:
print "".join([child.data for child in node.childNodes])
To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
DJ Adams wrote: > > So - is trying to get away from the 'homogenisation' of all results > into a 200 status code an appropriate thing to do here (or > anywhere)? I think you answered your own question. The value of HTTP is a uniform interface. This is a two edged sword. - Sam Ruby
Jeffrey Winter wrote: > Personally, I don't see why this isn't a RESTful interface. > You're doing a "GET" on a resource, and getting a response. I'm sorry if I wasn't clear. I was not asking about the HTML page, but instead about the Python code, which is clearly doing a POST. > I'm curious about what you say about the SOAP <envelope> and <body> > elements though: under what circumstances would they occur in the > returned document? In response to a POST. - Sam Ruby
Hello: I recently got tripped up trying to use an EXSLT extension function in my XSLT transformer. I used http://www.exslt.org/dyn/ as my namespace declaration. This *does* point to the web page describing the facility (the human-readable spec) but *is not* the correct namespace string. The ns should be declared as follows: http://exslt.org/dynamic My question: why can't they be the same thing? Is there some reason I haven't thought of? In fact, couldn't the very same URL be used for: A) the namespace declaration B) the human readable spec C) mobile or manually downloadable code implementing the spec where B/C is controlled through content negotiation or some other ReSTful facility... Opinions? Regards, --Craeg
On Mon, Dec 30, 2002 at 03:57:32PM -0000, sa3ruby <rubys@...> wrote: > > So - is trying to get away from the 'homogenisation' of all results > > into a 200 status code an appropriate thing to do here (or > > anywhere)? > > I think you answered your own question. The value of HTTP is a > uniform interface. ... Not wanting to appear obtuse, but I think the statement is a little misleading, or at least ambiguous. Then again, perhaps I've misunderstood. Are you saying that an HTTP status code of 201 following a successful PUT is uniform (with 200?) or not? dj
----- Original Message ----- From: "Sam Ruby" <rubys@...> > > Now let me get to the point of this e-mail. In response to criticism > [3], I am looking for constructive suggestions as to how to make this > interface more compatible with REST. I agree with you that this interface is REST compatible, but because the nature of the information is very transient I believe you won't see a lot of the benefits of REST. This is just my opinion though. I think there is a spectrum of capabilities that designers can add to systems to get the most bang for the buck. At the low end of the spectrum you might be 'compatible', but not really full featured - the tree isn't big enough to hang a lot of fruit on. If you add more features to your validator service you might begin seeing more possibilities - but just to do this one thing, its fine as it is. Things to add: 1. persistence If the service remembered the POSTed data, then the service could provide a URI that can be used to announce to the world the shameful RSS that was sent to it. 2. links If the client wanted to expose the prospective data as a Resource (requiring an 'origin server' in REST speak), then the validation service only needs to be given a URI - and perhaps it could be implemented via GET. This is analagous to a file system utility that validates an XML file - like command piping in Unix, except with URIs and the Web. It would be interesting to create an extreme example of technology abuse by having a client take the transient data, open a port to receive HTTP requests on, send the URI to the service, respond to the GET with the transient data, and then close the port. Kind of like creating a temp file to pipe to a file-only aware command line utility. 3. response status The client detects HTTP response status of 500 and above - is this for detecting service failure or for detecting invalid RSS? I think that the service should successfully report validation completion via a 2xx status and use response content to describe the validity of the POSTed content.
DJ Adams wrote: > On Mon, Dec 30, 2002 at 03:57:32PM -0000, sa3ruby <rubys@...> wrote: > >>>So - is trying to get away from the 'homogenisation' of all results >>>into a 200 status code an appropriate thing to do here (or >>>anywhere)? >> >>I think you answered your own question. The value of HTTP is a >>uniform interface. ... > > Not wanting to appear obtuse, but I think the statement is a little > misleading, or at least ambiguous. Then again, perhaps I've misunderstood. > Are you saying that an HTTP status code of 201 following a successful PUT > is uniform (with 200?) or not? 201 is defined by the protocol, and therefore uniform across all compliant HTTP implementations. I personally would prefer not to see HTTP follow down a similar path as COM's HRESULT - where portions of application specific responses are comingled with transport level status. - Sam Ruby
On Mon, Dec 30, 2002 at 01:33:18PM -0500, Sam Ruby wrote: >> [201 vs 200, etc] > I personally would prefer not to see HTTP follow down a similar path as > COM's HRESULT - where portions of application specific responses are > comingled with transport level status. <smile/> This being such an old chestnut I'll at least do you the honour of responding. <<Of course, HTTP is an application protocol, not (just) a transport protocol>>. But I'm sure you know that already :) Nevertheless, I can see the view from a SOAP-over-HTTP perspective. People less woolly than I might respond to your statement thus: <<But Sam, HTTP isn't following that path, it's _defined_ it and has always been there>>. dj
On Mon, Dec 30, 2002 at 04:27:41PM +0000, DJ Adams wrote: > While I don't really have any suggestions, I would like to throw in a > thought from here - I *think* I would like to be able to tell whether > the data that I threw at the validator was valid RSS or not by looking > at the status code. This requires a slight rethink of the model Sam has, > whereby the URI represents a container that you're *supposed* to throw > valid RSS at, and receive either: > > a 200 status with no message body if the RSS is valid > > or > > a non-200 status back (with the details in the message body) if it's not. > > Thing is, I can't figure out what the status code should be. I first > looked at status code 415 (Unsupported Media Type) but I suspect that > would mean that 'application/rss+xml' was *generally* not supported at > that URI, rather than just *invalid* 'application/rss+xml'. > > So - is trying to get away from the 'homogenisation' of all results into > a 200 status code an appropriate thing to do here (or anywhere)? Sure, if that's what you want. If you want the state of resulting validation to be a valid state of your application, you need to return a 2xx. IMO, when in doubt, lean towards 2xx. But that doesn't mean sending SOAP faults over 2xx, it means sending SOAP envelopes with state information useful to your application over 2xx. FWIW, I would fully expect a validation service to send back validation errors over 2xx, since validation errors are the result of *successful* processing (i.e. it was able to determine that there were validation errors). MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
On Mon, Dec 30, 2002 at 02:20:16PM -0500, Mark Baker wrote: > FWIW, I would fully expect a validation service to send back validation > errors over 2xx, since validation errors are the result of *successful* > processing (i.e. it was able to determine that there were validation > errors). Yes, I don't disagree; as you say, the actual processing was successful. This is the reason I was saying the model in my question was different to the original one. Cheers dj
One thing that is interesting about your interface is that you assume <envelope> and <body> elements even if they are not supplied. Would it be much work to not return them in the response if the request wasn't encoded as SOAP? Granted these are easily ignored, but why deal with them at all? Which leads to another question: Has there ever been any serious consideration to defining SOAP 1.2 in such a way that it would assume the <envelope> and <body> tags if none are given, and only supply them when necessary? This would seem to allow SOAP toolkits to work more seemlessly with straight XML/HTTP service interface. I'm sure there are a host of issues that I haven't even considered. - Winter
On Mon, Dec 30, 2002 at 02:56:48PM -0500, Sam Ruby wrote: > The status code describe things common to all HTTP transfers. What I > personally would like to avoid is applications like Amazon using it to > convey the difference between INSTOCK and BACKORDERED. Agreed. Mmm, adopting the 'classic' (in my eyes, anyway) "URI in a spreadsheet cell" example: GET /order/12345/status HTTP/1.0 200 OK Content-Type: text/plain INSTOCK The actual meaning of 'INSTOCK' of course opens up a can of worms that's not that noticeable when dealing with numeric values (like stock price). dj
In this case, invalid RSS results in an HTTP 500 error and an embedded <soap:Fault> element. Mark, do you see that as improper then given your comments? The SOAP spec requires that any soap:Fault's use the 500 error, so the question is, does invalid RSS demand that a Fault be generated? Is this the proper use of Fault? - Winter ----- Original Message ----- From: "Mark Baker" <distobj@...> To: "DJ Adams" <dj.adams@...> Cc: "Sam Ruby" <rubys@...>; <rest-discuss@yahoogroups.com> Sent: Monday, December 30, 2002 2:20 PM Subject: Re: [rest-discuss] Towards a RESTful validation interface > On Mon, Dec 30, 2002 at 04:27:41PM +0000, DJ Adams wrote: > > While I don't really have any suggestions, I would like to throw in a > > thought from here - I *think* I would like to be able to tell whether > > the data that I threw at the validator was valid RSS or not by looking > > at the status code. This requires a slight rethink of the model Sam has, > > whereby the URI represents a container that you're *supposed* to throw > > valid RSS at, and receive either: > > > > a 200 status with no message body if the RSS is valid > > > > or > > > > a non-200 status back (with the details in the message body) if it's not. > > > > Thing is, I can't figure out what the status code should be. I first > > looked at status code 415 (Unsupported Media Type) but I suspect that > > would mean that 'application/rss+xml' was *generally* not supported at > > that URI, rather than just *invalid* 'application/rss+xml'. > > > > So - is trying to get away from the 'homogenisation' of all results into > > a 200 status code an appropriate thing to do here (or anywhere)? > > Sure, if that's what you want. If you want the state of resulting > validation to be a valid state of your application, you need to return > a 2xx. > > IMO, when in doubt, lean towards 2xx. But that doesn't mean sending > SOAP faults over 2xx, it means sending SOAP envelopes with state > information useful to your application over 2xx. > > FWIW, I would fully expect a validation service to send back validation > errors over 2xx, since validation errors are the result of *successful* > processing (i.e. it was able to determine that there were validation > errors). > > MB > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Web architecture consulting, technical reports, evaluation & analysis > > > To unsubscribe from this group, send an email to: > rest-discuss-unsubscribe@yahoogroups.com > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
On Mon, Dec 30, 2002 at 11:20:34AM +0000, Craeg Strong wrote: > My question: why can't they be the same thing? Is there > some reason I haven't thought of? In fact, couldn't the > very same URL be used for: > > A) the namespace declaration > B) the human readable spec > C) mobile or manually downloadable code implementing the spec > > where B/C is controlled through content negotiation > or some other ReSTful facility... Opinions? Yep, I'd say they should probably be the same thing. I can't think of a reason for doing what they're doing. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
On Mon, Dec 30, 2002 at 08:40:58PM -0500, Jeffrey Winter wrote: > In this case, invalid RSS results in an HTTP 500 error and > an embedded <soap:Fault> element. > > Mark, do you see that as improper then given your comments? "improper" is too strong. It's perfectly REST-friendly to do this, I think. I'd just classify it as poor design within the constraints of REST. > The SOAP spec requires that any soap:Fault's use the 500 error, so the > question is, does invalid RSS demand that a Fault be generated? > Is this the proper use of Fault? With the same "[im]proper" qualification above, no. I'd only expect a Fault when POSTing RSS, if I was POSTing it to a processor that required that the RSS be valid before it did its processing. And I assume we're talking SOAP 1.1 here, which only supports HTTP 500 responses. For SOAP 1.2, I'd use a Sender fault which would map to 400, since the sender is sending the invalid RSS. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
On Mon, Dec 30, 2002 at 08:55:12PM -0500, Mark Baker wrote: > And I assume we're talking SOAP 1.1 here, which only supports HTTP > 500 responses. For SOAP 1.2, I'd use a Sender fault which would map > to 400, since the sender is sending the invalid RSS. Ah, I think this clears something up for me indirectly too - thanks. I had been wondering whether the wording in 2616 [1] ... << 10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. >> ... referred to the HTTP method & URI & headers only, or referred to the whole message. I'd been thinking the former, which had made me look at (and subsequently abandon for reasons I stated in a previous post) 415. dj [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1